php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #42374 --as-needed causes configure failures
Submitted: 2007-08-22 09:57 UTC Modified: 2008-10-27 14:25 UTC
From: galtgendo at o2 dot pl Assigned:
Status: Not a bug Package: Feature/Change Request
PHP Version: 5.2CVS-2007-08-23 OS: Gentoo
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: galtgendo at o2 dot pl
New email:
PHP Version: OS:

 

 [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.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-08-22 10:30 UTC] galtgendo at o2 dot pl
As I don't see a way to attach anything here, I'll give you a link to an old gentoo bug with my patch. It's http://bugs.gentoo.org/show_bug.cgi?id=151444
It's an old bug so it still covers the part from the closed bug.
BTW your bugzilla is REALLY annoying.
 [2007-08-22 14:45 UTC] jani@php.net
FYI: this is not bugzilla and it's not annoying. It's just old. :)

And about your patch..are you really sure you need to change all those places?
 [2007-08-22 14:46 UTC] jani@php.net
And have you even tested what was committed in our CVS?
 [2007-08-22 15:40 UTC] galtgendo at o2 dot pl
Well, I'm not 100%, if I was, I would mentioned it, not asked for futher testing.
And AFAIK that commit from bug #41973 was only
http://cvs.php.net/viewvc.cgi/php-src/ext/ldap/config.m4?r1=1.44&r2=1.45&diff_format=u
so only about ext/ldap/config.m4 (as in my patch).
What's more, although I can't recall if it made any difference you should consider changes in acinclude.m4, cause in PHP_CHECK_LIBRARY macro you were adding libraries to LDFLAGS instead of LIBS and that's most common source of --as-needed bugs. That's why I'm talking about false negatives - standard configure check would put those libraries in wrong place and check would fail even if the library was OK.
 [2007-08-23 10:38 UTC] jani@php.net
PHP_CHECK_LIBRARY restores the LDFLAGS after doing the test so it shouldn't be any problem?

And bug #41973 was about ext/ldap and that was fixed.
I'd fix these case by case rather than blindly changing places unlikely to even cause any problems.

 [2007-08-23 15:21 UTC] galtgendo at o2 dot pl
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.
 [2007-08-23 15:30 UTC] galtgendo at o2 dot pl
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
 [2007-08-23 23:01 UTC] jani@php.net
After some investigation to this flag I'm leaning towards simply filtering it out totally if someone tries to use it. Reasons being:

a) it seems to be experimental
b) might cause problems in dynamic loading such as our shared extensions, f.e. php -> pdo -> pdo driver (haven't tested yet :)
c) requires that pretty much everything in the system has to be compiled using it
d) PHP build system does not link with anything else than what is actually needed anyway (AFAIK)

 [2007-08-24 03:11 UTC] crrodriguez at suse dot de
>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)
 [2007-08-24 07:44 UTC] jani@php.net
And we're not trying to fix the faulty 3rd party libraries here, are we? :)
 [2007-11-05 21:39 UTC] galtgendo at o2 dot pl
This may seem like nagging, but I wonder how are things comming along.
And to add my 2c:
ldd -u /usr/lib/php5/lib/php/extensions/no-debug-zts-20060613/tidy.so
Unused direct dependencies:
	
	/usr/lib/libtidy-0.99.so.0
	/lib/libcrypt.so.1
	/usr/lib/libsqlite.so.0
	/lib/libhistory.so.5
	/lib/libreadline.so.5
	/lib/libncurses.so.5
	/lib/libresolv.so.2
	/lib/libm.so.6
	/lib/libdl.so.2
	/lib/libnsl.so.1
	/lib/libz.so.1
	libgssapi.so.1
	/usr/lib/libkrb5.so.22
	/lib/libcom_err.so.2
	/usr/lib/libssl.so.0.9.8
	/usr/lib/libcrypto.so.0.9.8
	/usr/lib/libxml2.so.2
	/lib/libpthread.so.0
ldd -u /usr/lib/php5/lib/php/extensions/no-debug-zts-20060613/zlib.so
Unused direct dependencies:
	
	/lib/libz.so.1
	/lib/libcrypt.so.1
	/usr/lib/libsqlite.so.0
	/lib/libhistory.so.5
	/lib/libreadline.so.5
	/lib/libncurses.so.5
	/lib/libresolv.so.2
	/lib/libm.so.6
	/lib/libdl.so.2
	/lib/libnsl.so.1
	libgssapi.so.1
	/usr/lib/libkrb5.so.22
	/lib/libcom_err.so.2
	/usr/lib/libssl.so.0.9.8
	/usr/lib/libcrypto.so.0.9.8
	/usr/lib/libxml2.so.2
	/lib/libpthread.so.0
And for comparison:
ldd -u /usr/lib/php5/lib/php/extensions/no-debug-zts-20060613/gd.so
Unused direct dependencies:
	
	/usr/lib/libfreetype.so.6
	/lib/libcrypt.so.1
	/usr/lib/libsqlite.so.0
	/lib/libhistory.so.5
	/lib/libreadline.so.5
	/lib/libncurses.so.5
	/lib/libresolv.so.2
	/lib/libm.so.6
	/lib/libdl.so.2
	/lib/libnsl.so.1
	/lib/libz.so.1
	libgssapi.so.1
	/usr/lib/libkrb5.so.22
	/lib/libcom_err.so.2
	/usr/lib/libssl.so.0.9.8
	/usr/lib/libcrypto.so.0.9.8
	/usr/lib/libxml2.so.2
	/lib/libpthread.so.0
ldd -u /usr/bin/php
Unused direct dependencies:
	
	/lib/libcrypt.so.1
	/usr/lib/libsqlite.so.0
	/lib/libhistory.so.5
	/lib/libm.so.6
	/lib/libdl.so.2
	/usr/lib/libroken.so.18
	/lib/libresolv.so.2
	/lib/libpthread.so.0
	/usr/lib/libssl.so.0.9.8
 [2007-11-05 22:49 UTC] galtgendo at o2 dot pl
There's a funny thing, though.
Command that built in example tidy.so was :
/bin/sh /var/tmp/portage/dev-lang/php-5.2.4_p20070914-r2/work/php-5.2.4_p2007091
4/libtool --silent --preserve-dup-deps --mode=link /var/tmp/portage/dev-lang/php
-5.2.4_p20070914-r2/work/php-5.2.4_p20070914/meta_ccld -DPHP_ATOM_INC -I/var/tmp
/portage/dev-lang/php-5.2.4_p20070914-r2/work/php-5.2.4_p20070914/include -I/var
/tmp/portage/dev-lang/php-5.2.4_p20070914-r2/work/php-5.2.4_p20070914/main -I/va
r/tmp/portage/dev-lang/php-5.2.4_p20070914-r2/work/php-5.2.4_p20070914 -I/usr/in
clude/libxml2 -I/var/tmp/portage/dev-lang/php-5.2.4_p20070914-r2/work/php-5.2.4_
p20070914/ext/date/lib -I/usr/include/freetype2 -I/usr/include/imap -I/var/tmp/p
ortage/dev-lang/php-5.2.4_p20070914-r2/work/php-5.2.4_p20070914/ext/mbstring/oni
guruma -I/var/tmp/portage/dev-lang/php-5.2.4_p20070914-r2/work/php-5.2.4_p200709
14/ext/mbstring/libmbfl -I/var/tmp/portage/dev-lang/php-5.2.4_p20070914-r2/work/
php-5.2.4_p20070914/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/includ
e/postgresql/libpq-4 -I/usr/include/pspell -I/var/tmp/portage/dev-lang/php-5.2.4
_p20070914-r2/work/php-5.2.4_p20070914/TSRM -I/var/tmp/portage/dev-lang/php-5.2.4_p20070914-r2/work/php-5.2.4_p20070914/Zend  -D_REENTRANT  -I/usr/include -O2 -march=athlon -mtune=athlon -pipe -pthread -DZTS  -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,relro -o ext/tidy/tidy.la -export-dynamic -avoid-version -prefer-pic -module -rpath /var/tmp/portage/dev-lang/php-5.2.4_p20070914-r2/work/php-5.2.4_p20070914/modules -avoid-version -module ext/tidy/tidy.lo -ltidy -lcrypt -lcrypt -lsqlite -lhistory -lreadline -lncurses -lresolv -lm -ldl -lnsl -lxml2 -lz -lm -lgssapi -lkrb5 -lcom_err -lssl -lcrypto -ldl -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt

so theoretically it should not have those dependencies, unless   --preserve-dup-deps messes that up. I think I'll test this theory.

Of course, this is a completely separate issue to the one this bug is about.
 [2007-11-06 12:26 UTC] galtgendo at o2 dot pl
Please disregard most of my last comment, I misunderstood something.
I thought that --as-needed prevents linking with unused libraries, but it only marks them as unused, so above listings of ldd -u mean that it actually works, not the opposite. Anyway, what was exactly the problem that --preserve-dup-defs works around, cause the note in configure.in says only that there was a problem with older libtool, not what was it ?
 [2007-12-10 18:42 UTC] galtgendo at o2 dot pl
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.
 [2008-10-27 14:25 UTC] jani@php.net
If somewhere in configure are places where LDFLAGS is populated with -l entries, point them out in separate bug reports. Closing this as bogus.
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Fri May 20 16:03:34 2022 UTC