I'm reporting this bug because the package in summary fails to build when forcing --as-needed on through spec files (check out http://blog.flameeyes.eu/2008/11/14/problems-and-mitigation-strategies-for-as-needed for details). Check the attached build log. Thanks, Diego
Created attachment 173235 [details] Build log
Could you double check this one? It builds fine with --as-needed on my machine...
Closing.
Please, have you _read_ the blog post I linked? Can you _please_ read it now? I'm quite ready to bet you *didn't* read the blog post because otherwise you'd know _why_ it doesn't fail for you but _does_ fail for me and _is_ broken.
(In reply to comment #4) [rant mode on] Yes, I did read your blog post, altough I missed the 'rebuild your system' part (my fault), which I'm doing now. If I didn't your blog, I would have a hard time testing stuff without a --as-needed enabled gcc profile. Btw, I could have done than sooner if you had bothered to reply to comment #2. And finally, being gentle to people (instead of sarcastic), expecially when you are pointing out at their errors, would make it a pleasure to learn something new. Keep in mind that everyone here is devoting what precious little free time they can spare on Gentoo, not just you. [rant mode off]
Rebuild system? no that's not the part at all, please re-read again and feel free to ask. By the way I read comment #2 as "it does not fail with just LDFLAGS=--as-needed so it might be a problem with forced --as-needed only" (which is somewhat lower priority). If a package fails forced --as-needed but not LDFLAGS=--as-needed it's because it's either ignoring LDFLAGS (bad) or fails because of an indirect link. But there is a difference between NEEDINFO and WORKSFORME. WORKSFORME I read as "works for me and I don't care for others".
(In reply to comment #6) Thanks for your polite reply. I feel better now, really :-) > Rebuild system? no that's not the part at all, please re-read again and feel > free to ask. I read it again (:-P) and stopped my complete rebuild :-) By the way I read comment #2 as "it does not fail with just > LDFLAGS=--as-needed so it might be a problem with forced --as-needed only" > (which is somewhat lower priority). Oh, I see. But actually, it builds fine here with forced --as-needed. And I'm sure my gcc profile is correct, since I already reproduced and fixed a number of similar bugs. > But there is a difference between NEEDINFO and WORKSFORME. WORKSFORME I read as > "works for me and I don't care for others". I didn't mean it to sound that way, I'm sorry for that. Actually I wanted to say "it does work for me, can you help me with this?" I analyzed the linking line that is failing for you and works for me: our setups must be a little different; the link lines are similar, but mine differs from yours by linking some different libraries, and in different order. So I'm sorry, but I cannot reproduce your issue here, let alone fix it.
Created attachment 178694 [details] working build log Attaching my own build log for reference.
Okay it might be the different libtool version to be the problem, I'm using 2.2 on the tinderbox. Can you tell me which version are you using? Because this is really interesting to know since I didn't know libtool ever expanded shell commands. At any rate I checked out the Makefile.am in the source code and... it sincerely stinks. AM_LDFLAGS = -lX11 -lXext -lXpm -L/usr/X11R6/lib -L/usr/lib -L/usr/local/lib `glib-config --libs` `gtk-config --libs` `imlib2-config --libs` it's passing this thing though LDFLAGS, and the reason for it is that if you actually pass this through LDADD it will fail telling you that --libs is an ldflag. Funky crappy libtool checks, foobillard has something similar. Since the package si actually patched to use GTK2, it should be changed so that instead of using pkg-config --libs gtk+-2.0 in Makefile.am it uses $(GTK_LIBS) (which is already calculated during configure). It could also use pkg-config to discover imlib2 and thus replace the imlib2-config call with IMLIB2_LIBS, at which point AM_LDFLAGS should be replaced with LDADD and work out fine.
Btw, I just noticed that the problem in bug #248639 is the same as in here (cannot link to imlib2). I don't know if this has some meaning for you.
I'm using libtool-1.5.26
Following your comment, I just committed to cvs a change where I clean up package Makefile.am via the patch we apply. The package still compiles fine here with forces --as-needed.
Well, it seems this needs some testing from the bug reporter...
