This builds fine, but there are undefined symbols all over the place, and this causes ebuilds depending on this to choke, a lot. Basically, the gtk/gdk libs need to be aware of each other. Currently, they seem to expect apps to handle this, and the apps apparently expect the opposite. Unsurprisingly, a lot of stuff dies a horrible linking death.
This too has the libtools problem as detailed in bug #133818. Basically, elibtoolize and _elibtoolize don't fix this ebuilds libtool, so you need to run
libtoolize --force --copy --automake. Explicitly linking to the *.so's doesn't work, because they get skipped after the libtool compile.
Also, whoever wrote these was sticking libraries into LDFLAG variables, so no more of that.
Created attachment 87076 [details, diff]
gtk+-1.2.10 --as-needed patch
Created attachment 87077 [details, diff]
gtk+-1.2.10-r11.ebuild --as-needed patch
Sorry, typo on the dependency.
Usual stuff with Makefile.in and configure, for the rest this looks fine.
The libtoolize call by itself is once again not the way to go tho, that will screw things up.
(In reply to comment #4)
> Usual stuff with Makefile.in and configure, for the rest this looks fine.
> The libtoolize call by itself is once again not the way to go tho, that will
> screw things up.
I *knew* that was going to cause trouble, but since I had no solution, I was hoping someone did. On the upside, I think I found what I needed to get it out of those ebuilds.
Created attachment 87489 [details, diff]
gtk+-1.2.10 --as-needed patch, revised for eautoreconf
Again, patch size a result of refomatting configure.in, so I could be absolutely certain about the quoting. The failures caused by this are strange. configure will die way down in the script, when really the problem was a screwy macro expansion way up at the beginning.
Created attachment 87490 [details, diff]
gtk+-1.2.10-r11.ebuild --as-needed patch, using eautoreconf
Shaved a few chars off this one.
Created attachment 88573 [details]
I put together an overlay with these patches and have run into some problems. I'm not sure where the issue is, but the emerge is dying at a rather odd spot, as seen in the attachment.
Here's emerge --info:
Gentoo Base System version 1.12.1
*** Deprecated use of action 'info', use '--info' instead
Portage 2.1_rc4-r3 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.16-gentoo-r7 i686)
System uname: 2.6.16-gentoo-r7 i686 AMD Athlon(tm) XP 3000+
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.4 [enabled]
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
CFLAGS="-march=athlon-xp -O2 -pipe -fno-ident -fomit-frame-pointer -ftracer -freorder-blocks-and-partition"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-xp -O2 -pipe -fno-ident -fomit-frame-pointer -ftracer -freorder-blocks-and-partition -fvisibility-inlines-hidden -fno-enforce-eh-specs"
FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://gentoo.chem.wisc.edu/gentoo/ http://gentoo.mirrors.tds.net/gentoo ftp://gentoo.mirrors.pair.com/"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,--enable-new-dtags -Wl,-Bdirect -Wl,-hashvals -Wl,-zdynsort"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
It looks like bug 114797 could be the cause of the problem I'm having now.
I can confirm that applying those patches fixes the compilation of at least XMMS with --as-needed for me.
*** Bug 138258 has been marked as a duplicate of this bug. ***
Comment on attachment 88573 [details]
this attachment has nothing to do with --as-needed
As you already know I am no member of gnome herd, but I tested this patch and gtk+-1.2.10-r11 now has correct dependencies - this is linking against libgdk and more.
This patch is mainly so large as it cleans configure-script to work with eautoreconf.
A much shorter possibility would be to just patch Makefile.in files but this basically contradicts with automake-concept.
And just changing Makefile.am and doing nothing else breaks when calling automake and thus requires building up the large patch being attached here.
I vote for adding this patch, too.
It makes all apps happy linking against gtk+-1.2 with --as-needed.
The attachment on Bug #129112 shows the ugly but short variant.
*** Bug 129112 has been marked as a duplicate of this bug. ***
*** Bug 136028 has been marked as a duplicate of this bug. ***
Please fix this in a gtk+-1.2.10-r12 version.
The new version should have the same keywords as -r11.
I've been using this patched version since mid-June on both my desktop and laptop, with zero problems.
Fixed in revision -r12. I've requested revision stabilisation in bug 150355.
The beauty part is you don't have to call eautoreconf in the dependent packages because gtk and gdk libraries no longer contains UNDEF symbols.
Thanks Thomas for your contribution! Please excuse the lag.
(In reply to comment #19)
> Fixed in revision -r12. I've requested revision stabilisation in bug 150355.
> The beauty part is you don't have to call eautoreconf in the dependent packages
> because gtk and gdk libraries no longer contains UNDEF symbols.
> Thanks Thomas for your contribution! Please excuse the lag.
No problem. I've a tendency to lag a bit myself, as this reply should demonstrate.