Multiple build failures

[liketechnik]

So at the start of the past weekend I started using this project. I added the overlays, installed the package and upgraded my gcc/binutils/glibc to the latest version. During the @world upgrade multiple packages failed to build (around 20 of 1300), for some packages I already found out it's an incompatibility between the latest glibc version and the gnulib version used in these packages. I'm not sure if I should open seperate issues for the packages or if I can just dump them here, but these are the packages that failed for me:

• sys-apps/coreutils
• app-admin/metalog
• dev-libs/boost
• gzip (latest (unstable) version works, failed due to gnulib vs. glibc version)
• m4 (same as for gzip)
• dev-libs/libunistring (probably the same issue as with the two packages above)
• media-libs/x264
• dev-libs/libsigsegv
• dev-libs/libindicator
• media-libs/portmidi
• dev-qt/qtcore
• net-misc/mosh
• dev-java/icedtea
• app-emulation/virtualbox
• dev-lang/ghc
• cross gcc for aarch64 (not that important, may also be misconfiguration)
• Spotify segfaults, because it can't determine the version of the curl library? (working after reinstall, though error messages are still there)
• glibc has to be compiled with working flagomatic tools

So far my systems working great and seems a lot faster. Because I have a lot to do for school and my computer isn't that fast, it's a bit difficult for me to test all these packages, but for sure this isn't meant as a "this isn't working for me, it's your repo, go ahead and fix this for me asap", but rather as "I have these problems, not necessarily the time to care about all of this, so help is appreciated". I'll look into what I have time for and update the issue acordingly.

[liketechnik]

Sorry, just thought when I started describing this issue: "DON'T forget your emerge info" to myself. Well, now here it is: https://gitlab.com/snippets/1777836

[wolfwood]

there is a bugs.gentoo.org ticket for the spotify thing, iirc its about curl being linked with gold?

…

On Tue, Nov 13, 2018, 11:47 Florian Warzecha ***@***.*** wrote: Sorry, just thought when I started describing this issue: "DON'T forget your emerge info" to myself. Well, now here it is: https://gitlab.com/snippets/1777836 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#184 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB74qlGQOAE6QiECd2l7mLTrlXbIStAks5uuyG6gaJpZM4YcX7t> .

[ionenwks]

Not an issue with LTO either but latest metalog doesn't even use gnulib anymore making the glibc 2.28 incompatibility irrelevant. But for some reason the ebuild is still using a pretty ancient version (metalog-3 is 6 years old). I ended up just upgrading it myself to the one released last month and it works fine.

glibc 2.28 gentoo build issues are tracked there for the record: https://bugs.gentoo.org/663916

Edit: Also personally was able to build glibc with blocked flag-o-matic just fine albeit I removed the global block on append-flags(), strip/filter/replace are the ones I hate most (looking at this again, I think I'm going to add a wrapper to append-flags and only stop it from adding -O2). You do need to disable LTO but this overlay should have an exception for glibc already. I also linked my glibc with gold by overriding tc-ld-disable-gold() that was forcing -fuse-ld=bfd (It's an experiment but I use gold for my whole system now with no exceptions, since it's smarter than bfd when using -fno-plt -- can't comment on the above-mentioned spotify issue though since I don't use it). Also efivar package since it doesn't properly link with -ldl despite using it through another library (just need to add it).

Edit2: Oh, this may be an issue (just remembered), I did remove ipa-pta on glibc.. I don't know what was up with that (didn't search in-depth) but I built glibc with ipa-pta just fine but then gcc failed to build complaining about ioLib.h, turns out rebuilding glibc without ipa-pta fixed that. I retried the process a few times and it always came down to failing when glibc had ipa-pta (of course need blocked flag-o-matic for this to happen)

[InBetweenNames]

From my understanding, these issues are related to glibc 2.28 and not LTO or optimizations, is that correct?

[InBetweenNames]

@ionenwks thanks for the heads up about -fno-plt

[ionenwks]

Yeah I think most of those are due to glibc, many are fixed by just using the unstable version of packages.

@InBetweenNames And from my own quick tests extern library calls are about 30% faster with -fno-plt (the call itself, tested using a function that does nothing.. so would be relevant for something that calls those a lot very quickly). Only problems I had was with berkdb since gentoo adds -Wl,--default-symver with append-ldflags() which gold doesn't support (normally the ebuild blocks gold). You can remove that if you have only 1 version of berkdb though. And with the 32bit version of PCSX2 and ffmpeg (ffmpeg 64bit is fine) which I used CFLAGS_x86/amd64 to build only the 32bit version without -fno-plt.

Also the gold thing is because of: https://sourceware.org/ml/binutils/2016-05/msg00322.html -- gentoo already have a wiki page to make gold default too. Just need to deal with that override.

no-plt also makes lazy binding less effective, but a lot of people use relro and -z now and don't even use lazy bindings anymore.

[ionenwks]

^ Well, I could be wrong about needing gold (maybe bfd is updated too). I didn't look into it that much. I mostly just wanted to use gold at this point (everything seems to be smaller with it).

[ionenwks]

Going a bit off-topic with this plt stuff but I should probably mention just-in-case, if you build glibc with -fno-plt (aka no flag-o-matic to stop it), and build it with bfd instead of gold.. it'll be fine but if you use prelink you're going straight in segmentation fault land (I've given up on prelink for now, even the latest staging version barely understand anything built with a recent toolchain and features).

[InBetweenNames]

@ionenwks Trying out prelink now with -fno-plt -- it does seem to be working, with a few exceptions. The glibc -fno-plt problem is still definitely the case, and there are a few things that can't be prelinked for these reasons:

• Dependency cycles
• section file offsets not monotonically increasing (not sure what causes this one)

But it's not many. I'm on staging prelink, the -99999999 ebuild. Going to give it a whirl for a few weeks.

[InBetweenNames]

Initial impression: things load real fast!

[wolfwood]

a few years back i thought portage was automatically running prelink?

…

On Tue, May 14, 2019, 11:30 Shane Peelar ***@***.***> wrote: Initial impression: things load real fast! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#184?email_source=notifications&email_token=AAAHXYVC23TW5MQSJZHQHXTPVMAODA5CNFSM4GDRP3W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVMMBXA#issuecomment-492355804>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAHXYUDALJVXWDLTIDPAMLPVMAODANCNFSM4GDRP3WQ> .

[ionenwks]

Good to hear prelink is working a bit better now, I really like the idea of it but had so many issues a while back even with -staging (if not segmentation fault, it was that prelink refused to prelink anything at all). I'll give it another go sometime on a test system.

@wolfwood Not sure for native automation, but personally I used to have prelink run as part of the clean-logs script that runs every time portage finishes (rather than the cronjob gentoo is currently suggesting which I don't like the idea of), but stopped after my configuration slowly started to break prelink.

[wolfwood]

You do not need to set FEATURES="prelink" in your make.conf file; Portage will automatically support prelink if it can find the prelink binary

https://wiki.gentoo.org/wiki/Prelink

[ionenwks]

@wolfwood I believe this is to support prelink and not actually use it, I could be wrong since I didn't dig much but a quick look at the portage sources seem to tell me the only way it ever calls prelink is with --version, --undo, and --verify, which doesn't actually prelink anything. The support is also for setting paths through env-update.