| View previous topic :: View next topic |
| Author |
Message |
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
 Posted: Sat Oct 14, 2017 10:25 pm Post subject: Cannot build libtool? |
 |
|
I upgraded GCC recently and am trying to rebuild libtool and it isn't working. In fact it fails instantly. The log is located here. Any idea what's wrong?
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
 |
ian.au
Guru
Joined: 07 Apr 2011
Posts: 591
Location: Australia
|
| Posted: Sat Oct 14, 2017 11:55 pm Post subject: |
|
|
| What does return? |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30894
Location: here
|
| Posted: Sun Oct 15, 2017 6:50 am Post subject: |
|
|
You can post output of /var/tmp/portage/sys-devel/libtool-2.4.6-r3/temp/libtool-2.4.6-link-specs.patch.out?
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Tue Oct 17, 2017 9:01 pm Post subject: |
|
|
Sorry, been away from that system. I can post the output tomorrow or the next day when I return to that site. I do know that the output of 'gcc-config -l' only shows the current GCC, 5.4.0-r3 or something along those lines. No others are listed.
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Mon Nov 20, 2017 2:13 am Post subject: |
|
|
Just hit this again. I accidentally wiped the first 16MiB on my internal disk instead of a USB disk we were testing on, so I need to reinstall Gentoo. No biggy, I have backups of my data. I zero the disk for good measure, partition, install the tarball, enter the chroot, do the basic configuration, and then do the first world update. It wants to pull down GCC 6.4, rebuild SSH (I use -bindist) and SSL, and one other package. It finishes, I set GCC to use the new version, do env-update && source /etc/profile && export PS1="(chroot) $PS1", and then attempt to rebuild sys-devel/libtool. Same exact issue. Tells me the patch worked in a dry run, but failed in the real one. I don't have a kernel or anything yet. I am using System Rescue CD to do my Gentoo installs. I believe this is version 4.9.1 of SRCD. What is causing this? I never did figure it out before I screwed it up, but it appears that upgrading to GCC 6.4 breaks things. What can I do to troubleshoot this?
*EDIT*
The build log is located below.
https://paste.pound-python.org/show/3skReq8beZKeKirN78gC/
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30894
Location: here
|
| Posted: Mon Nov 20, 2017 7:11 am Post subject: |
|
|
Strange, in my system patch is applied. You can post also /var/tmp/portage/sys-devel/libtool-2.4.6-r3/temp/libtool-2.4.6-link-specs.patch.out?
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Tue Nov 21, 2017 3:37 am Post subject: |
|
|
Done. It can be found here.
*EDIT*
It says it cannot find a file on line 20 of that paste. No clue why. This is failing on both complete installs which work just fine (desktop and all) and ones being installed from scratch like this laptop.
*UPDATE*
Something is very off here. The output mentioned not being able to find a file on line 21, but line 21 of the specified file is a patch location.
| Code: |
Signed-off-by: Pavel Raiskup <praiskup@redhat.com>
---
build-aux/ltmain.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index d5cf07a..0c40da0 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5360,10 +5360,12 @@ func_mode_link ()
# -tp=* Portland pgcc target processor selection
# --sysroot=* for sysroot support
# -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimiza$
+ # -specs=* GCC specs files
# -stdlib=* select c++ std lib with clang
-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*$
- -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*)
[ line 21/58 (36%), col 1/42 (2%), char 652/2438 (26%) ]
|
Line 21 is the "@@ -5360" line.
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Wed Nov 22, 2017 2:30 am Post subject: |
|
|
So how do I fix this? I have now been stopped for 24hrs. I cannot figure out how to build libtool after selecting the new GCC.
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54216
Location: 56N 3W
|
| Posted: Wed Nov 22, 2017 4:47 pm Post subject: |
|
|
The_Great_Sephiroth,
| Code: | * Applying libtool-2.4.6-link-specs.patch ...
* A dry-run of patch command succeeded, but actually
* applying the patch failed! |
That means that the patch fits in the code but for some other reason it was rejected.
What happens when you apply it by hand?
I suspect to odd filesystem permissions but I can't imagine what.
Portage has write access - untaring the sources worked.
Filesystem full ?
Don't forget that under filesystem full conditions things that work for root can fail for a normal user.
There is normally 5% reserved for root so a user can't bring a system to its knees by filling the filesystem.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30894
Location: here
|
| Posted: Wed Nov 22, 2017 4:58 pm Post subject: |
|
|
| NeddySeagoon wrote: | I suspect to odd filesystem permissions but I can't imagine what.
Portage has write access - untaring the sources worked. |
I think you right, indeed the error is
| Code: | patching file build-aux/ltmain.in
File build-aux/ltmain.sh is read-only; trying to patch anyway
patching file build-aux/ltmain.sh
Hunk #1 succeeded at 7272 (offset 1912 lines).
patch: setting attribute btrfs.compression for btrfs.compression: Permission denied |
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Wed Nov 22, 2017 8:42 pm Post subject: |
|
|
Alright, then it is a Gentoo issue. Let em explain. I had a freshly zeroed system on my desk this morning. I booted System Rescue CD from USB and proceeded to partition and format the disk. I then extracted the stage 3 tarball to the mounted partitions. I followed the AMD64 guide, entered the chroot, synced up the repos, and then did the world update. It pulls GCC 6.4 (the tarball gave me 5.4) and I TRY following the upgrade guide. After the world set is updated (7 items including GCC) I select 6.4 and then attempt to rebuild libtool. I have changed nothing. I edited make.conf, the timezone, locale.gen, and that's about it. I have not even used the tools to set file permissions. Below is my partition layout.
| Code: |
SDA1 -> GRUB/BIOS
SDA2 -> Subvolumes @boot and @root, btrfs
SDA3 -> Ext4 for VirtualBox systems
SDA4 -> Subvolume @home, btrfs
SDA5 -> Swap
|
Two subvolumes are using compression. The @root subvolume uses LZO compression and SDA2 is setup with duplicate metadata and single data. The @home subvolume uses zlib compression and the partition is duplicate metadata AND data. Nothing special about the Ext4 partition.
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54216
Location: 56N 3W
|
| Posted: Wed Nov 22, 2017 9:08 pm Post subject: |
|
|
The_Great_Sephiroth,
Humor me please, it will only be a wee while.
Put your portage build location into tmpfs and test the libtool build as far as the patch.
If you RAM is too small, a USB key formatted ext2 will do.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Thu Nov 23, 2017 12:10 am Post subject: |
|
|
Too bad it isn't my gaming rig. It has 128GB in it. Still, I have plenty in the laptop. I will try this in a few minutes and report back.
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Thu Nov 23, 2017 12:31 am Post subject: |
|
|
That did it. From the error it appears as though the patch was trying to set compression flags on the file but couldn't since it was an inherited flag and quit. Compression should not matter. Open the file, the file-system decompresses and opens it. Patch it. Save it and the file-system will compress it and write it back to disk. Seems like a bug in the patch not being compatible with BTRFS and/or file-system compression. Can somebody compress an ext4 system and see if this bugs out?
Also, I normally symlink /var/tmp to /tmp, which is a 512M tmpfs by default. I had not done it yet since I haven't even pulled down a kernel yet. I believe I will make that a step earlier in my install phase to avoid these bugs.
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21606
|
| Posted: Thu Nov 23, 2017 2:58 am Post subject: |
|
|
| As a minor point, this is not a Gentoo problem, unless Gentoo is patching GNU patch to add the broken compression handling. Looking at the ebuild, I see no sign of such a patch, so this appears to be a conflict between GNU patch as developed by its upstream and BTRFS compression, wholly independent of Gentoo. |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Thu Nov 23, 2017 4:59 am Post subject: |
|
|
Does it work on compressed ext4 volumes? I ask because it may be compression in general. Also, if it works on ext4 compression and not BTRFS, why? I did not mean that this was specifically a Gentoo issue, as I imagine it happens on other distros as well. However, I did mean to imply that as stuff like this is discovered, it would wind up being reported to whomever works on the project.
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
ian.au
Guru
Joined: 07 Apr 2011
Posts: 591
Location: Australia
|
| Posted: Thu Nov 23, 2017 5:49 am Post subject: |
|
|
| The_Great_Sephiroth wrote: | | Does it work on compressed ext4 volumes? |
When was transparent compression functionality added to ext4? |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Thu Nov 23, 2017 8:01 am Post subject: |
|
|
| And anyone will ask me "why you say btrfs is a shitty fs" then... |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Fri Nov 24, 2017 5:51 pm Post subject: |
|
|
I know that there are people using compression on ext4. I did not know whether or not it was transparent.
As to the comment about BTRFS, the world is beginning to live on it. Google anybody? I have had no issues with BTRFS before this, and this is NOT BTRFS in my mind. The patch script is attempting to set the compression attribute on a file without first seeing whether or not that attribute is inherited or anything, leading to failure. I compress the original mount-point when creating the subvolume.
| Code: |
mkfs.btrfs -m dup -d single -L Linux /dev/sda2
mount /dev/sda2 /mnt/gentoo
btrfs subvolume create /mnt/gentoo/@root
chattr +c /mnt/gentoo/@root
btrfs property set /mnt/gentoo/@root compression lzo
umount /dev/sda2
mount -o subvol=@root /mnt/gentoo
|
Now any files put on there inherit the LZO compression, saving space. I can put a complete system on about 12GiB of space this way. I mean development tools, Chromium, LibreOffice, Firefox, Plasma, the whole nine yards! It's worked fine this way all year since I switched. Just because GNU Patch doesn't know how to use the features correctly doesn't mean the file-system is to blame.
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21606
|
| Posted: Sat Nov 25, 2017 4:44 am Post subject: |
|
|
| How did you determine that this is GNU patch using the feature incorrectly? So far, we only know that it attempts to set an attribute, the attempt fails with Permission denied, and then GNU patch exits with an error code. As far as I can see, we do not know whether it is correct for this attempt to fail. |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Sat Nov 25, 2017 6:15 am Post subject: |
|
|
OK, I assume it is the patch utility because that is failing and setting attributes on BTRFS works fine if done by hand. So either it is setting attributes wrong or not reading the result correctly. At least that is my thought. I have no idea how to debug it and I'm not fancy on doing so. Not many hours free these days, and now I have a daughter, so life is BUSY.
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
|
Portage & Programming
