Re: config.m4 Macros and static libs

I investigated this further, and as expected the outcome is: It's a wreckage in the php build system, in PHP's acinclude.m4 to be more exact. The PHP_CHECK_LIB macro seems severly broken. Question is, whom should be adressed to get this fixed for future versions of php? I assume this will need some detailed technical discussion why it is failing now to be fixed properly without breaking anythign else. Should this be moved to some other specific mailinglist? Any other channel of direct contact? Please advise. Regards -Sven On Fri, September 18, 2009 06:40, Sven Eschenberg wrote: > Okay, let me clarify this: > > I have two files for now. A .c source, with a .h header making up the > extension, well, not really yet, but supposedly. Now, the extension > needs to use a lib (libdhcpctl), which in turn needs libomapi and libdst > (which are all static libs) Those libs' header files are in the system > header path (/usr/include) and the libs are under /usr/lib, which again, > is in the system path. > > Now, I want to make a check, if those libs+headers are present, well > actually, I'd be happy if I couldd check for the presence of the dhcpctl > lib. > > As you can see, the configure run fails, since a conftest doesn't > compile as expected. libdhcpctl needs libomapi, both are static libs, as > said earlier. Now, afaik, since libdhcptl references function form > libomapi, the call to gcc should read: > > cc -o conftest -g -O2 conftest.c -ldhcpctl -lomapi > > instead of: > > cc -o conftest -g -O2 -lomapi conftest.c -ldhcpctl > > if I am not mistaken. (The latter version is generated by the configure > script, via the macro) > > esp. if you take a look at the gcc error output you can see, while > processing the dhcpctl.o from within dhcpctl.a, the error is triggered, > because omapi_message_new is 'undefined' and cannot be resolved. But > libomapi.a is in the system path - further investigation shows: > objdump -t message.o|grep omapi_message_new > 00000000000011b0 g F .text 0000000000000130 omapi_message_new > where message.o is within libomapi.a - so, this should be all fine. > The needed header is dhcpctl.h is in /usr/include, which in turn > includes the <omapip/omapi.h> header file, in which the following > prototype can be found: > isc_result_t omapi_message_new (omapi_object_t **, const char *, int); > > Which again looks pretty reasonable. > > When I do a: > gcc -o test -g -O2 test.c -ldhcpctl -lomapi > where test.c hold the same source as the failing conftest.c, I am getting: > gcc -o test -g -O2 test.c -ldhcpctl -lomapi > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../lib64/libomapi.a(connection.o): > In function `omapi_connection_output_auth_length': > (.text+0x154): undefined reference to `dst_sig_size' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../lib64/libomapi.a(connection.o): > In function `make_dst_key': > (.text+0x2fe): undefined reference to `dst_buffer_to_key' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../lib64/libomapi.a(connection.o): > In function `omapi_connection_sign_data': > (.text+0x37d): undefined reference to `dst_sign_data' > ... > > Which is as expected, since I am still missing a -ldst, thus: > gcc -o test -g -O2 test.c -ldhcpctl -lomapi -ldst > > works perfectly well, and the test could suceeed. Now, how do I > accomplish the correct ordering of the -l<libname> statements during the > test? > It's really just all about that M4 Macro I cannot convince to do, what I > want it to do, or rather, what it should be doing, to pass the test. > (The documentation suggests, that the 5th parameter holds additional > needed libs, but as we can see from the config.log, the call to gcc is > contructed in a wrong manner) > > Regards > > -Sven > > > Israel Ekpo schrieb: >> Hi Sven, >> >> Sometimes this type of error could occur if omapi_message_new is defined >> somewhere but the prototype or declaration is not available where it is >> being referenced. >> >> If omapi_message_new is a function, make sure it is declared in a header >> file that is available everywhere. Also make sure that the source file >> where it is defined is listed in the config.m4 file properly using >> PHP_NEW_EXTENSION. >> >> If omapi_message_new is a variable, make sure it is declared as an >> external global variable using extern omapi_message_new in a header file >> that is available where it is needed. >> >> I hope that helps. >> >> >> >> On Thu, Sep 17, 2009 at 7:57 PM, Sven Eschenberg >> <sven@whgl.uni-frankfurt.de >> <mailto:sven@whgl.uni-frankfurt.de>> wrote: >> >> So, since I am still stuck with this, does anybody have a useful >> pointer to some Documentation, how to resolve the issue, or should >> the M4 Macro be considered broken. >> Or could someone advise some other place to turn to, where I can >> find someone, who might be able, to help me work out this issue? >> >> >> Regards >> >> -Sven >> >> -------- Original-Nachricht -------- >> Betreff: Re: [PECL-DEV] config.m4 Macros and static libs >> Datum: Mon, 7 Sep 2009 21:45:39 +0200 (CEST) >> Von: Sven Eschenberg <sven@whgl.uni-frankfurt.de >> <mailto:sven@whgl.uni-frankfurt.de>> >> Antwort an: sven@whgl.uni-frankfurt.de >> <mailto:sven@whgl.uni-frankfurt.de> >> An: pecl-dev@lists.php.net >> <mailto:pecl-dev@lists.php.net> >> Referenzen: <4AA41333.1030803@whgl.uni-frankfurt.de >> >> <mailto:4AA41333.1030803@whgl.uni-frankfurt.de>> >> <4AA4C605.5090406@iki.fi >> <mailto:4AA4C605.5090406@iki.fi>> >> >> Did you really think I didn't try it in the first place? Why would I >> start >> digging into the m4 file with the PHP_* Macros, though I am not >> really >> familiar with M4. >> Anyway, it seems the check might work, if there wasn't the second >> lib as >> dependency. >> >> Here is what I am doing right now: >> >> PHP_CHECK_LIBRARY($LIBNAME,$LIBSYMBOL,[ >> PHP_ADD_LIBRARY_WITH_PATH($LIBNAME, $OMAPI_DIR/lib, >> OMAPI_STATIC_LIBADD) >> AC_DEFINE(HAVE_OMAPILIB,1,we have the DHCPCTL lib.[]) >> ],[ >> AC_MSG_ERROR([dhcpctl lib not found.]) >> ],[ >> -L$OMAPI_DIR/lib -lomapi >> ]) >> >> PHP_SUBST(OMAPI_STATIC_LIBADD) >> >> Unfortunately dhcpctl needs the omapi lib. >> >> Now, config log says: >> configure:4706: cc -o conftest -g -O2 -lomapi conftest.c -ldhcpctl >> >&5 >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../lib64/libdhcpctl.a(dhcpctl.o): >> In function `dhcpctl_object_remove': >> (.text+0x76): undefined reference to `omapi_message_new' >> >> Obviously -lomapi is passed, but yet I get unresolved symbols. >> >> Both libs reside in the same system lib path, which means both >> should be >> found accordingly. Could this be related to the ordering of >> parameters >> passed to gcc? >> >> Regards >> >> -Sven >> >> >> On Mon, September 7, 2009 10:36, Jani Taskinen wrote: >> >> On 09/06/2009 10:53 PM, Sven Eschenberg wrote: >> >> Dear List, >> >> My request is a little arkward, since I am not too familiar >> with the gnu >> build tools. I want to write a PECL extension for PHP that >> exploits the >> features of a specific lib. Unfortunately the lib is only >> available as >> static lib (actually it's two libs - anyhow, this shouldn't >> change too >> much). >> As far as I could gather from the m4 file that defines the >> PHP_* Macros, >> the PHP_CHECK_LIBRARY Macro only works for shared libs. What >> would be >> >> >> Fail. It doesn't care what your library is as long as it's >> found. :) >> >> Try before you ask? It's not that hard. And if you have actual >> problem >> with some errors or something, THEN ask.. >> >> --Jani >> >> >> >> -- >> PECL development discussion Mailing List (http://pecl.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >> >> -- >> PECL development discussion Mailing List (http://pecl.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >> -- >> "Good Enough" is not good enough. >> To give anything less than your best is to sacrifice the gift. >> Quality First. Measure Twice. Cut Once. > > > -- > PECL development discussion Mailing List (http://pecl.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >