This is mostly because of other packages depending on glib. To get them to work with --as-needed, glib has to be patched, though it happily compiles with the flag enabled. It just doesn't bother to link it's libraries to each other. You need to apply the patch, glib-1.2.10-r5-as-needed.patch, then run: libtoolize --copy --force --automake (or really, just --force) Modified ebuild to handle patch and the "libtoolization", but I imagine this could fail on systems with older libtools, or libtools on different architectures. Thus, there is an alternate patch with explicit links to the shared libraries that tries to get around brain-damaged libtools. Unfortunately, I can't get it to work. The libtool compile works fine, but the archive_cmds='$CC -shared $linkopts $libobjs $deplibs ${wl}-soname $wl$soname -o $lib' setup in ltconfig is blind to the libs needed for linking. I've tried to add conditionals to test for what is being compiled, but it doesn't work. I don't know why and, frankly, I'm tired of it. I'm not sure how to best handle this, as I have no idea which libtools will have problems. Also, it's not enough to use the elibtoolize or _elibtoolize functions. They just don't do the right thing, although maybe there's some trick to them I'm not aware of.
Created attachment 87074 [details, diff] glib-1.2.10-as-needed.patch
Created attachment 87075 [details, diff] ebuild patch glib-1.2.10-r5 for --as-needed
The ebuild patch is wrong. There's already an elibtoolize call, that shouldn't be there, and libtoolize by itself is going to break more things that it tries to fix. You need to inherit autotools, run eautoreconf (as it needs a full rebuild if libtoolize is going to be called), and then elibtoolize (although it's a no-op as eautoreconf runs it by itself, but for safety better put it there).
(In reply to comment #3) > The ebuild patch is wrong. > There's already an elibtoolize call, that shouldn't be there, and libtoolize by > itself is going to break more things that it tries to fix. > You need to inherit autotools, run eautoreconf (as it needs a full rebuild if > libtoolize is going to be called), and then elibtoolize (although it's a no-op > as eautoreconf runs it by itself, but for safety better put it there). > I did that. It failed. Probably should have mentioned it.
This is what it does: >>> Unpacking source... >>> Unpacking glib-1.2.10.tar.gz to /var/tmp/portage/glib-1.2.10-r5/work * Applying glib-1.2.10-m4.patch ... [ ok ] * Applying glib-1.2.10-gcc34-fix.patch ... [ ok ] * Applying glib-1.2.10-as-needed.patch ... [ ok ] * Running elibtoolize in: glib-1.2.10 * Applying portage-1.3.4.patch ... * Applying sed-1.5.6.patch ... * Applying tmp-1.3.5.patch ... * Applying uclibc-ltconf-1.3.0.patch ... * Running eautoreconf in '/var/tmp/portage/glib-1.2.10-r5/work/glib-1.2.10' ... * Running aclocal ... [ ok ] * Running autoconf ... [ !! ] * Failed Running autoconf ! * * Include in your bugreport the contents of: * * /var/tmp/portage/glib-1.2.10-r5/temp/autoconf-24063.out !!! ERROR: dev-libs/glib-1.2.10-r5 failed. Call stack: ebuild.sh, line 1527: Called dyn_unpack ebuild.sh, line 703: Called src_unpack glib-1.2.10-r5.ebuild, line 33: Called eautoreconf autotools.eclass, line 66: Called eautoconf autotools.eclass, line 142: Called autotools_run_tool 'autoconf' autotools.eclass, line 198: Called die Now, if I keep the libtoolize --force --copy --automake, then run eautoreconf, it still dies. The only thing that works is the bare libtoolize call. Also, as to the elibtoolize call, it was in because it was already there, and I forgot to remove it.
The elibtoolize call is actually needed anyway. The problem you're having should _not_ be worked around by the bare libtoolize, I can ensure you that running it that way is going to give people many headaches. Look at http://www.gentoo.org/proj/en/qa/autofailure.xml to find the cause of the failure and fix it. Yes it's unfortunately long, and annoying, that's the main problem with --as-needed fixes (I had way worse times fixing gimp-print tho :P)
There's the autoconf log. That's it. ***** autoconf ***** configure.in:20: /usr/bin/m4: Non-numeric argument to built-in `divert' autom4te-2.59: /usr/bin/m4 failed with exit status: 1
Gah, good luck with that :| You might want to look at gimp-print 4.x patch, I had to fix a similar problem there. They actually probably copied the stuff between them.
Created attachment 87153 [details, diff] (barely) revised glib-1.2.10-r5.ebuild.patch for --as-needed
Damn, forgot to check the "obsolete" box. Ah well. Ok, here's where I've gotten to: eautoreconf just plain breaks configure. There's an obsolete macro issue, but I fixed that. Next, it suddenly becomes incapable of feeding the host to libtool, even though there is a proper call to AC_CANONICAL_HOST. As an experiment, I removed the "--no-verify", and libtool was perfectly happy. Unfortunately, the only way to get rid of this is to edit aclocal,acinclude, and/or configure. In any case, it wouldn't matter, because if that issue is fixed/avoided, configure dies on the very last line of the file then declares that it hit a premature end of file. Given that it's at the end of the file, I wonder what it expects. I'm still trying to fix these, but there is a paucity of useful info out there. Most of the advice I've seen involves removing "--no-verify" for the first issue, and no one seems to have a clue about the second other than "upgrade your <x>" where x is some autotools program. In general, whatever version of x supposedly fixes this is what's actually being used. Now, there is a solution, which I'm fairly sure will be unacceptable, but it's what I have: Instead of libtoolize --copy --force, I used _elibtoolize --copy --force. I didn't realize before that you had to pass those flags to _elibtoolize, which is why it didn't work before. Of course, I don't see much distinction between the "old" and "new" fixes, but for the characters '_e'. Also, to avoid altering the Makefile.in's, I used eautomake. This just put me back to square one, because version mismatch triggered an eautoreconf call. The version mismatch in question is 1.4-p6 versus 1.4-p5. I can't believe that makes much difference, given that called on the command line, it will happily generate the files, and glib compiles. I can understand if we were talking 1.5 versus 1.4, but this seems overly strict. The Changelog for 1.4-p6 doesn't even mention bugfixes; mostly, it's new versions of config.guess and the like, which are being altered by libtoolize anyway. Basically, it's annoying and long, like you said.
(In reply to comment #3) > and libtoolize by itself is going to break more things that it tries to fix. I'm still working on how to make this eautoreconf compatible, but I thought you might be interested that approx 370 ebuilds call libtoolize by itself.
Uh a lot of ebuilds were written before eautoreconf was ever used so they use libtoolize and then calls aclocal. Whatever else calls libtoolize without aclocal should be fixed possibly using eautoreconf. But I'm not going to hunt all of them down, I just fix them when I stumble across them and I try not to add more of them :)
Created attachment 87368 [details, diff] glib-1.2.10-as-needed.patch Now works with eautoreconf. Turned out to be a weird interaction between macro expansion and quoting. I'm still not sure just what the hell was going on, but it definitely involved a comma preceding an empty argument. The weird part was that the macro immediately following was the same macro, with the same comma, and it was handled fine. I changed it anyway. Sorry about the patch size, but I totally re-formatted configure.in because it was driving me nuts.
Created attachment 87371 [details, diff] ebuild patch glib-1.2.10-r5 for --as-needed, using eautoreconf This one's smaller than the last one.
I am no member of gnome herd, but nevertheless I tested this patch and now glib-1.2.10-r5 does build with --as-needed and the created libs contain correct linking information. The patch works. It is a bit huge but that is be concept - it makes glib aware of up-to-date autoconf/automake, and cleans up the configure.in. I vote for commiting it.
I've been using this patched version since mid-June on both my desktop and laptop, with zero problems.
Well it works for the package itself but ~gnome-base/orbit-0.5.17 doesn't compile when glib is compiled with the --as-needed patch: http://bugs.gentoo.org/130735#c7
(In reply to comment #17) > Well it works for the package itself but ~gnome-base/orbit-0.5.17 doesn't > compile when glib is compiled with the --as-needed patch: > > http://bugs.gentoo.org/130735#c7 > Have you patched orbit for --as-needed. All these gnome derived packages are interdependent: glib, gnome-libs, orbit, gtk+, gdk-pixbuf. There a lot of unstated link dependencies that resolve fine until --as-needed is introduced. Then all of a sudden a package breaks even though you patched a completely different package, but then it turns out that 2nd package linked against some other library unnecessarily which had the side effect of providing symbols needed by the first library. Or, --as-needed will remove a link because it isn't explicitly stated -- this happened with glib, as it didn't link it's sub-libraries together once --as-needed was turned on.
(In reply to comment #18) > Have you patched orbit for --as-needed. All these gnome derived packages are > interdependent: glib, gnome-libs, orbit, gtk+, gdk-pixbuf. There a lot of > unstated link dependencies that resolve fine until --as-needed is introduced. > Then all of a sudden a package breaks even though you patched a completely > different package, but then it turns out that 2nd package linked against some > other library unnecessarily which had the side effect of providing symbols > needed by the first library. Or, --as-needed will remove a link because it > isn't explicitly stated -- this happened with glib, as it didn't link it's > sub-libraries together once --as-needed was turned on. Hi, of course I have patched orbit as well. I took the patch from bug #130735 where I also wrote (comment nr. 7) that orbit doesn't compile (even WITH the --as-needed patch) when I have applied --as-needed patch to glib. This error is 100% reproduceable on my two ~x86 machines where I have enabled --as-needed and disappears as soon as I compile glib without --as-needed and its patch. Cheers Poly-C
Added in portage.
