|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2007-08-22 09:57 UTC] galtgendo at o2 dot pl
Description: ------------ Recently closed bug #41973 may not cover all the issues. I have a patch that doesn't seem to break anything for me and AFAIK solves all potential issues. The --as-needed bugs happen mostly when you use libtool and add -L and -l to LDFLAGS instead of LIBS. So by the use of grep I tried to change all the macros that seem to do that. I hope I didn't break anything, however somebody should check that, cause 'works for me'!='it works'. At least look at acinclude.m4, cause that one may lead to false negatives with library detection. PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Mon Nov 03 20:00:02 2025 UTC |
Well, that's incorrect. PHP_CHECK_LIBRARY calls AC_CHECK_LIB. without -Wl,--as-needed it does not matter whether libs are in LDFLAGS or in LIBS, with that flag however all dependent libraries must appear after the objects. AC_CHECK_LIB does something like i686-pc-linux-gnu-gcc -o conftest ${CFLAGS} ${LDFLAGS} conftest.c ${LIBS} (more or less) that check fails with --as-needed flag if lib is added to LDFLAGS so it does not matter if it gets restored, cause the check already failed - those are the false negatives I'm talking about. All the other macros from the patch seem to do this, so that's why I changed them. I'm not sure if something got broken, however it was correct for the ext/ldap/config.m4 so there's at least a chance it will work for the rest.For a simple test case: #include <glib.h> int main() { g_print("test done\n"); return 0; } gcc -o minitest -Wl,--as-needed `pkg-config glib-2.0 --cflags` minitest.c `pkg-config glib-2.0 --libs` - compiles fine gcc -o minitest -Wl,--as-needed `pkg-config glib-2.0 --cflags` `pkg-config glib-2.0 --libs` minitest.c - gives /tmp/ccKZrHDW.o: In function `main': minitest.c:(.text+0x19): undefined reference to `g_print' collect2: ld returned 1 exit status>a) it seems to be experimental yes, but it usually work. >b) might cause problems in dynamic loading such as our shared >extensions, f.e. php -> pdo -> pdo driver (haven't tested yet :) I have tested it with some extensions and seem to work fine, except that the IMAP extension does not compile because configure checks fail for the same reason the reporter is showing here. >d) PHP build system does not link with anything else than what is >actually needed anyway (AFAIK) ldd -u -r /usr/bin/php Unused direct dependencies: /lib/libnsl.so.1 /lib/libz.so.1 ldd -u -r xmlreader.so /lib/libz.so.1 /lib/libm.so.6 dom.so Unused direct dependencies: /lib/libz.so.1 /lib/libm.so.6 gd.so Unused direct dependencies: /usr/lib/libX11.so.6 although in most cases the guilty stuff is "foobar_config" scripts or pkgconfig scripts that inject "uneeded" dependencies (uneeded at least on linux)OK, I did some more reading on autotools. A quote from autoconf info page: -- Variable: LDFLAGS ... This variable's contents should contain options like `-s' and `-L' that affect only the behavior of the linker. ... Don't use this variable to pass library names (`-l') to the linker; use `LIBS' instead. So title of this bug should be something along the lines of: 'rewrite your macros to conform to specs instead of simply work' While doing that it may be a good idea to split all those libraries into groups, so every extension (and php itself) doesn't get linked with every libs needed for other extentions.