This one is the bastard S.O.B of the lot. It first dies on configure, because it isn't satisfied to just call glib-config to find out if gmodule is available. Instead it compiles a little test for gmodule, which, logically, doesn't actually link to gmodule. It dies, and gnome-libs concludes that your system is incapable of dynamic linking. As if this is a realistic possibility, given that before it does this little test, it does this: LDFLAGS="$LDFLAGS `glib-config --libs gmodule`" Stupid. Don't put libs in LDFLAGS. Since LDFLAGS includes --as-needed, it chucks -lgmodule out since it comes before the object. After that, it's not so bad. It's just that there are so many interdependencies among the various libs, plus it relies on a lot of other packages, which all had to be fixed. I realized after I did this that the later version of libzvt has basically the same fix as the one included in gnome-libs.
Created attachment 87087 [details, diff] gnome-libs-1.4.2 --as-needed fix
Created attachment 87088 [details, diff] gnome-libs-1.4.2.ebuild.patch for --as-needed
See again notes on bug #133820 about patches to configure and Makefile.in, also don't add LDFLAGS when they are not present originally (the -version-info stuff). Regard +libgnome_la_LIBADD = $(GLIB_LIBS) -lm -lesd /usr/lib64/libaudiofile.la -lpopt -ldb1 you should not hardcode .la paths, in particular /usr/lib64 is amd64-multilib specific, you should just use -laudiofile.
(In reply to comment #3) > See again notes on bug #133820 about patches to configure and Makefile.in, also > don't add LDFLAGS when they are not present originally (the -version-info > stuff). > > Regard > > +libgnome_la_LIBADD = $(GLIB_LIBS) -lm -lesd /usr/lib64/libaudiofile.la -lpopt > -ldb1 Oops, I forgot to take that out. I was doing a copy and paste real quick while testing and never replaced it. > > you should not hardcode .la paths, in particular /usr/lib64 is amd64-multilib > specific, you should just use -laudiofile. >
Created attachment 87612 [details, diff] gnome-libs-1.4.2.ebuild.patch for --as-needed,uses eautoreconf I would have just done eautomake, but again, it triggers on a version mismatch btwn. 1.4-p5 and 1.4-p6, so I had to revise some macros and configure.in to make it work with eautoreconf. The size is only partly from reformatting, as telling diff to look for a smaller set of changes and to ignore whitespace didn't actually reduce it much, so I just kept the formatting in.
Created attachment 87613 [details, diff] gnome-libs-1.4.2 --as-needed fix, works with eautoreconf Move the previous comment to here.
I aplied those patchs, but still have this error: checking for gtk-config... /usr/bin/gtk-config checking for GTK - version >= 1.2.0... no and it disappears only with: LDFLAGS="" emerge gnome-libs
(In reply to comment #7) > I aplied those patchs, but still have this error: > > checking for gtk-config... /usr/bin/gtk-config > checking for GTK - version >= 1.2.0... no > > and it disappears only with: > > LDFLAGS="" emerge gnome-libs > Are you using a gtk patched for --as-needed? That's the only thing I can think of. Could you post the output of /usr/bin/gtk-config?
I'm not using a gtk patched for --as-needed.. /usr/bin/gtk-config gtk doesn'y report anything, an empty output and # eix -I gtk+ Installed: 1.2.10-r11 2.8.19
(In reply to comment #9) > I'm not using a gtk patched for --as-needed.. > /usr/bin/gtk-config gtk doesn'y report anything, an empty output > and > # eix -I gtk+ > Installed: 1.2.10-r11 2.8.19 > OK, try gtk+-1.2.10-r12. That has the --as-needed patch. gnome-libs only cares about gtk+-1.2, but the configure script uses gtk-config to check for the lib's presence as well as to get the correct compiler flags. I don't know why it's empty, but that's the source of the problem. I'll play around with gtk+ and see if I can reproduce that.
(In reply to comment #10) > (In reply to comment #9) > > I'm not using a gtk patched for --as-needed.. > > /usr/bin/gtk-config gtk doesn'y report anything, an empty output > > and > > # eix -I gtk+ > > Installed: 1.2.10-r11 2.8.19 > > > > OK, try gtk+-1.2.10-r12. That has the --as-needed patch. gnome-libs only cares > about gtk+-1.2, but the configure script uses gtk-config to check for the lib's > presence as well as to get the correct compiler flags. I don't know why it's > empty, but that's the source of the problem. I'll play around with gtk+ and > see if I can reproduce that. > Well, I still don't know how gtk-config ended up empty: what were the command-line options you gave it? Also, when gnome-libs dies on the gtk test, it should print out: "*** Could not run GTK test program, checking why..." and then a bunch of other stuff. So, what was the other stuff? Still, gnome-libs should build with the patched gtk. But, unless you have also built glib-1.2.10-r5 with the --as-needed patch, it will still fail, only later in the configure process.
Created attachment 101903 [details, diff] updated ebuild patch as the one in portage has changed The ebuild changed in portage, so the old patch was actually reverting some stuff, like IUSE, etc.
Marked for removal. Please migrate to gnome-2.x
