I need some advice with this one.. This is a prefix only bug, I have confirmed with the gnome herd that glib works with libtool-2.2* on a !prefix system. configure fails with "error: Cannot determine shared library suffix from libtool" and only with libtool-2.2, previous versions work fine. I have pinpointed the error and patched it to make it work for me. Should I apply it? Why does it only happen for prefix? Any insights? Thanks.
Created attachment 154475 [details, diff] fixes configure
the former uses the provided libtool, the latter system libtool. (by the way this breaks on darwin, where libtool is glibtool) Aparently our libtool is different. Maybe an elibtoolize fixes the problem?
(In reply to comment #2) > the former uses the provided libtool, the latter system libtool. (by the way > this breaks on darwin, where libtool is glibtool) Good point. We need to figure out what is removing(?) the "provided" libtool because it doesn't exist when emerging.
Update: I reverted all prefix specific changes in the ebuild and found that eautreconf is causing the problem with libtool-2.2.4. This will probably causes problems on interix I bet since it looks like that is why the change went in. http://overlays.gentoo.org/proj/alt/changeset/19134 - if I revert the eautoreconf bit (lines 54-58) glib builds again on x86-linux and with libtool-2.2.4. Ideas on how to fix this so both interix and linux platforms are happy?
Well, I have a rather silly idea. In dev-python/pygoobject, they provide AS_AC_EXPAND macro. They've created this macro for the sake of expanding $(prefix) dirs. But it works great for changing lines like: export_dynamic=`(./libtool --config; echo eval echo \\$export_dynamic_flag_spec) | sh` to AS_AC_EXPAND(export_dynamic, $export_dynamic_flag_spec) The variable is correctly and fully expanded and some posts on libtool mailing list suggest this should work with libtool 1.5, too.
Of course, temporarily you could simply add LT_OUTPUT after AC_PROG_LIBTOOL, but this would be a better long-term solution (as that would work only for libtool 2, before there was no such macro, as libtool was generated during AC_PROG_LIBTOOL, not in AC_CONFIG_FILES). Even upstream should consider it.
And comment 5 was referring to changes in configure.in, of course.
(In reply to comment #6) Rafał, Wow, you understand the problem quite well. Would you have time to supply a patch to me? I'm not quite up to par on this libtool stuff. Thanks.
Well, it's not like I really understand it. It came simply through much trial and error. But I'll see if I can drop something useful.
It looks like the simplest fix would be something similar, to what has been done in bug 213789, adding: m4_ifdef([LT_OUTPUT], [LT_OUTPUT]) right after AM_PROG_LIBTOOL in configure.in, that works for both 1.5 and =>2. This way, libtool will be created in the same place it was before, and those checks won't fail. Of course upstream should do something saner.
When I tried to came up with something more complex, I learned that glib does at least one check, that is currently beyond my understanding, namely: *** check for OSF1/5.0 RTLD_GLOBAL brokenness While G_MODULE_LDFLAGS should work with AS_AC_EXPAND flawlessly and shrext_cmds looks like it should too, that one is more than a bit beyond me. And, as I can't tell what it actually does in the first place, I decided to not touch it.
(In reply to comment #10) > It looks like the simplest fix would be something similar, to what has been > done in bug 213789, adding: > m4_ifdef([LT_OUTPUT], [LT_OUTPUT]) > right after AM_PROG_LIBTOOL in configure.in, > that works for both 1.5 and =>2. Great. Works. Thanks! > This way, libtool will be created in the same place it was before, > and those checks won't fail. > Of course upstream should do something saner. I'll ping the glib maintainers.
Tested with libtool-1.5* & 2.2* - works. Committed in prefix tree. Thanks again! Committed revision 22927.
