make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6? - Aix

This is a discussion on make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6? - Aix ; Hi, Our development machine is AIX 5.3 with XLC/C++ 9.0. Its xlC.rte is 9.0. Our customer's machine is also AIX 5.3 with xlC.rte 6.0. It is NOT possible to update customer's xlC.rte. We have to deliver (1) self-contained daemon and ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6?

  1. make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6?

    Hi,

    Our development machine is AIX 5.3 with XLC/C++ 9.0. Its xlC.rte is
    9.0. Our customer's machine is also AIX 5.3 with xlC.rte 6.0. It is
    NOT possible to update customer's xlC.rte.

    We have to deliver (1) self-contained daemon and (2) a dynamically-
    linked library (apache module for IBM HTTP server 6.0). Both are C++
    programs built on the dev machine and they needs xlC.rte 9.0.

    On the customer's machine, we resolved the xlC.rte mismatch issue for
    the self-contained daemon by pointing LIBPATH to a directory
    containing xlC.rte 9.0. Unfortunately we encounter problems with the
    dynamically-linked lib (apache module).

    If there is no other C++ apache modules then we can load our apache
    module by pointing LIBPATH to a directory containing xlC.rte 9.0.
    Once we add back those existing C++ apache modules that require
    xlC.rte 6.0, we encounter many symbol-not-found issues. We know that
    the issue is due to only one copy of libC.a, either version 6 or
    version 9, will be loaded by apache server, and this causes the symbol-
    not-found issue with either our C++ module (when v6 libC.a is loaded)
    or existing C++ modules (when v9 libC.a is loaded).

    Things we have tried:
    1. static link our the dynamic linked lib (apache module) to version 9
    of libC.a. But somehow the module still needs to dynamically link
    with version 9 of libC.a.
    2. We thought we could avoid name conflict with libC.a by copy v9
    libC.a to libCv9.a, have our apache module link with libCv9.a (instead
    of v9 libC.a). But somehow the dynamic link lib still needs v9 libC.a
    in addition to libCv9.a.
    3. we also tried to specify the compiler option "-bnamemangling=v6",
    hoping it forces our dynamic link lib to link with v6 libC.a without
    luck. We guess "-bnamemangling=v6" is meant for libraries other rhan
    libC.a.
    4. we played with linker option "-qnolib" (do not link with system
    libraries) and added several -L and -l options plus libCv9.a, hoping
    the module will not link with v9 of libC.a. But we encountered many
    unresolved symbols.
    5. We tried to statically link the apache module with all .o files
    extracted from v9 of libC.a. But somehow the apache module still
    references v9 of libC.a.

    We suspect that some "bootstrap" code is put into our apache module by
    XLC 9 compiler (anyway to avoid this?), therefore even a dynamically
    linked lib still need v9 of libC.a, regardless of our effort to avoid
    the reference to xlC.rte v9.

    Other than re-build our development machine with IBM (VisualAge ?) C++
    6.0 on AIX 5.3, any suggestions or pointers are welcome.

    Thanks.

    Kong
    BTW, are there any known issues with installing IBM C++ 6.0 to AIX 5.3?


  2. Re: make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6?

    likong@email.com schrieb:
    > Hi,
    >
    > Our development machine is AIX 5.3 with XLC/C++ 9.0. Its xlC.rte is
    > 9.0. Our customer's machine is also AIX 5.3 with xlC.rte 6.0. It is
    > NOT possible to update customer's xlC.rte.


    If this is true, you should downgrade your dev machine. But I don't know
    a good reason, why it should not be possible to upgrade the C++ runtime
    libs on the production machine.

    --
    Uli

  3. Re: make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6?

    likong@email.com writes:

    > Our development machine is AIX 5.3 with XLC/C++ 9.0. Its xlC.rte is
    > 9.0. Our customer's machine is also AIX 5.3 with xlC.rte 6.0. It is
    > NOT possible to update customer's xlC.rte.


    As Uri Link noted, your simplest choice is to build using xlC v6.0
    in that case.

    > Things we have tried:


    You are trying "random" permutations of reasonable approaches
    (reasonable in that they all could have worked), and abandoning them
    half-way because they "don't work". But you are not analyzing
    *why* they don't work (i.e. you are not understanding the
    problem, and are thus "programming by coincidence" -- see
    http://www.pragprog.com/the-pragmati...ts/coincidence).

    Now, to really understand why your methods don't work would require
    an expert on AIX dynamic linking. You can try to find a consultant
    that would solve your problem, or you can try asking "smart"
    questions here (Gary Hook is the resident linking expert).

    This link will tell you how to ask questions that are likely to
    produce useful answers: http://catb.org/esr/faqs/smart-questions.html

    > 1. static link our the dynamic linked lib (apache module) to version 9
    > of libC.a. But somehow the module still needs to dynamically link
    > with version 9 of libC.a.


    What was the link line? What is the output with '-bnoquiet' ?
    What is the output from 'dump -Tv your_module.o' ?

    > 5. We tried to statically link the apache module with all .o files
    > extracted from v9 of libC.a. But somehow the apache module still
    > references v9 of libC.a.


    Did v9 libC.a contain 'shr.o' (probably did).
    Do you understand that 'shr.o' is a shared library, and not a
    'regular' object? If you didn't, you have a *long* way to go before
    you understand AIX shared library model.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  4. Re: make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6?

    Paul Pluzhnikov wrote:
    > likong@email.com writes:
    >
    >> Our development machine is AIX 5.3 with XLC/C++ 9.0. Its xlC.rte is
    >> 9.0. Our customer's machine is also AIX 5.3 with xlC.rte 6.0. It is
    >> NOT possible to update customer's xlC.rte.

    >
    > Now, to really understand why your methods don't work would require
    > an expert on AIX dynamic linking. You can try to find a consultant
    > that would solve your problem, or you can try asking "smart"
    > questions here (Gary Hook is the resident linking expert).


    Yes, please ask smart questions.

    Short answer: what you are doing is unsupported. If you need to support
    the 6.0 runtime, then you need to build with the 6.0 compiler and runtime.

    Please push on the customer to update their runtime level. There is no
    reason not to do so, as all later versions support apps built on earlier
    versions.


    > This link will tell you how to ask questions that are likely to
    > produce useful answers: http://catb.org/esr/faqs/smart-questions.html
    >
    >> 1. static link our the dynamic linked lib (apache module) to version 9
    >> of libC.a. But somehow the module still needs to dynamically link
    >> with version 9 of libC.a.


    Don't even try to statically link your copy of libC.a into your module.
    A single process can _not_ have more than one instance of the C++
    runtime and be expected to work, but this scenario would require exactly
    that. Completely unsupported.

    Longer answer: don't do that. Set your requisites for your customers
    and require them to meet those requisites. Or develop on an older level
    so you can satisfy and support older levels.

    --
    -------------------------------------
    http://www.photo.net/photos/garyrhook
    Vocatus atque non vocatus deus aderit

  5. Re: make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6?

    "Gary R. Hook" writes:

    > Don't even try to statically link your copy of libC.a into your module.
    > A single process can _not_ have more than one instance of the C++


    Can't it?

    If the library has only 'extern "C"' interface, is statically linked
    with C++ runtime, *and* that runtime is completely hidden (not
    exported), technically one can't tell that there is C++ runtime
    inside; it's just a "black box" with C-callable interfaces.

    Now, obviously you can't throw out of the library, but most everything
    else would still work, wouldn't it?

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  6. Re: make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6?

    Paul Pluzhnikov wrote:
    > "Gary R. Hook" writes:
    >
    >> Don't even try to statically link your copy of libC.a into your module.
    >> A single process can _not_ have more than one instance of the C++

    >
    > Can't it?
    >
    > If the library has only 'extern "C"' interface, is statically linked
    > with C++ runtime, *and* that runtime is completely hidden (not
    > exported), technically one can't tell that there is C++ runtime
    > inside; it's just a "black box" with C-callable interfaces.
    >
    > Now, obviously you can't throw out of the library, but most everything
    > else would still work, wouldn't it?


    I understand your point, but I believe the answer is no. Black box
    or not, the runtime does hook into other parts of the process (libc,
    libpthreads, etc) and there _might_ be issues because of that.
    Therefore, just like libc.a(shr.o) I believe that two instances
    of libC.a(*) is an unsupported configuration. Someone from Toronto
    would have to chime in with an official position; I'm simply
    relaying my understanding.

    --
    -------------------------------------
    http://www.photo.net/photos/garyrhook
    Vocatus atque non vocatus deus aderit

  7. Re: make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6?


    It seems to me that we found a solution, without upgrading the
    client's xlC.rte from v6 to v9.

    What we did was
    1. compile the apache module as dynamic link lib as before.
    2. run the command rtl_enable (that comes with AIX 5.3) against libC.a
    in v9 xlC.rte to generate a new libC.a. Do the same for libC_r.a
    (actually these two lib point to the same file.)
    3. copy both libC.a and libC_r generated from rtl_enable to a target
    directory on the client's machine (with older xlC.rte). Include this
    directory in front of LIBPATH before starting apache server.

    I ran "genld -l" and indeed apache server references the two new lib
    without referencing the older /usr/lib/libC.a nor /usr/lib/libC_r.a.

    Thanks.

    Kong







+ Reply to Thread