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] Strange error 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] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r1 dev-util/confcache: 0.4.2-r1 sys-apps/sandbox: 1.2.18.1 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 sys-devel/binutils: 2.16.93 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe -fno-ident -fomit-frame-pointer -ftracer -freorder-blocks-and-partition" CHOST="i686-pc-linux-gnu" 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" DISTDIR="/usr/portage/distfiles" 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" PKGDIR="/usr/portage/packages" 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'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 3dnow X Xaw3d a52 aac aalib alsa aotuv arts asf audiofile avi bash-completion berkdb bitmap-fonts bzip2 cairo caps cddb cdr crypt cups curl dbus dga djbfft dri dts dvd emacs encode exif fam fbcon ffmpeg firefox flac fltk foomaticdb fortran fpx gcj gd gdbm gif glibc-omitfp glitz glut gmp gnutls gphoto2 gpm graphviz gs gstreamer gtk gtk2 hal idn ieee1394 imagemagick imlib insecure-savers ithreads java javascript jbig jikes joystick jpeg jpeg2k kde kdehiddenvisibility lcms libcaca libg++ libwww lm_sensors logitech-mouse logrotate mad maildir mikmod mmap mmx mmxext mng modplug motif mozsvg mp3 mpeg ncurses network nls nptl nptlonly nsplugin offensive ogg openexr opengl oss pam pcre pdflib perl physfs pic png python qt quicktime readline real reflection rle samba sdl session slang sndfile speex spell spl sse sse-filters ssl svg sysfs syslog tcltk tcpd theora threads tiff toolbar truetype truetype-fonts type1-fonts udev usb userlocales vcd vidix vim-with-x vorbis win32codecs wmf xine xml xmms xorg xpm xscreensaver xv xvid xvmc zlib elibc_glibc input_devices_joystick input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_nv video_cards_vesa" 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] Strange error 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.
