Re: config.m4 Macros and static libs

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.