libstdc++ compatibility frustrations under linux x86 - Unix

This is a discussion on libstdc++ compatibility frustrations under linux x86 - Unix ; Assume you have a static library LIB written in C++ that exports a C interface like LIB_init(), LIB_action() and LIB_free(). Internally this LIB is in C++ but from outsiders it must from C. LIB is depending on STL and therefore ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: libstdc++ compatibility frustrations under linux x86

  1. libstdc++ compatibility frustrations under linux x86

    Assume you have a static library LIB written in C++ that exports a C
    interface like LIB_init(), LIB_action() and LIB_free(). Internally this LIB
    is in C++ but from outsiders it must from C.
    LIB is depending on STL and therefore depends on libstdc++. We cannot have
    dynamic linking with libstdc++ since it causes compatibility problems if LIB
    is used with a different compiler version for linking. libstdc++ only
    guarranties binary compatibility between minor versions. To overcome this we
    do static re-linking of the symbols into our library.

    This relinking is done like:
    ld -r $TMP/to_be_fixed.$O `$CXX --print-file-name=libstdc++.a`
    `$CXX --print-file-name=libgcc_eh.a` -o $filename;

    This will merge the libstdc++ symbols into our library... which is good.
    Afterwards we need to hide them and we wrote a simple tool that works
    together with objcopy. objcopy does the job of hiding the symbols... but we
    furthermore change the section names to avoid same names between our library
    and other code.

    So now we have a another user who is using LIB into his application APP
    (also c++ application).
    This APP is compiled with an older g++ compiler more specifically g++ 3.3.6.
    However for now he wants that his users should be able to use his
    application on older linux.

    He is therefore sending his libstdc++.so.* and libgcc.so* to the
    end-users...

    Now hell breaks loose though... since the library LIB starts to act weird
    and not as documented. This has caused a number of days of work only to
    realise what the problem is.

    So LIB is suppose to use it's own private copy of libstdc++ instead of the
    public one... however I'm not sure about the legality of sending out
    libstdc++ libraries to other machines.
    I said for now that the user should try to link the application statically
    so they won't have a shared copy.

    I'm unsure about this whole scenario. There is very little and sparse
    documentation on this on the internet... this doesn't help in actually
    finding out which of these steps are legal and which should be avoided.

    Can anyone shed some light on this complex issue?

    Thanks.

    -- Henrik



  2. Re: libstdc++ compatibility frustrations under linux x86

    Henrik Goldman wrote:

    > Assume you have a static library LIB written in C++ that exports a C
    > interface like LIB_init(), LIB_action() and LIB_free(). Internally this LIB
    > is in C++ but from outsiders it must from C.


    I think you might need to rephrase the last sentence.

    > LIB is depending on STL and therefore depends on libstdc++. We cannot have
    > dynamic linking with libstdc++ since it causes compatibility problems if LIB
    > is used with a different compiler version for linking. libstdc++ only
    > guarranties binary compatibility between minor versions. To overcome this we
    > do static re-linking of the symbols into our library.
    >
    > This relinking is done like:
    > ld -r $TMP/to_be_fixed.$O `$CXX --print-file-name=libstdc++.a`
    > `$CXX --print-file-name=libgcc_eh.a` -o $filename;
    >
    > This will merge the libstdc++ symbols into our library... which is good.
    > Afterwards we need to hide them and we wrote a simple tool that works
    > together with objcopy. objcopy does the job of hiding the symbols... but we
    > furthermore change the section names to avoid same names between our library
    > and other code.
    >
    > So now we have a another user who is using LIB into his application APP
    > (also c++ application).
    > This APP is compiled with an older g++ compiler more specifically g++ 3.3.6.
    > However for now he wants that his users should be able to use his
    > application on older linux.
    >
    > He is therefore sending his libstdc++.so.* and libgcc.so* to the
    > end-users...
    >
    > Now hell breaks loose though... since the library LIB starts to act weird
    > and not as documented. This has caused a number of days of work only to
    > realise what the problem is.
    >
    > So LIB is suppose to use it's own private copy of libstdc++ instead of the
    > public one... however I'm not sure about the legality of sending out
    > libstdc++ libraries to other machines.
    > I said for now that the user should try to link the application statically
    > so they won't have a shared copy.
    >
    > I'm unsure about this whole scenario. There is very little and sparse
    > documentation on this on the internet... this doesn't help in actually
    > finding out which of these steps are legal and which should be avoided.
    >
    > Can anyone shed some light on this complex issue?


    Paul Pluzhnikov is one of the linker guruz :-)
    You might find him in the gnu.gcc.help newsgroup.

    Regards.

  3. Re: libstdc++ compatibility frustrations under linux x86

    "Henrik Goldman" writes:
    ....
    > This will merge the libstdc++ symbols into our library... which is good.
    > Afterwards we need to hide them and we wrote a simple tool that works
    > together with objcopy. objcopy does the job of hiding the symbols... but we
    > furthermore change the section names to avoid same names between our library
    > and other code.


    Good so far ...

    > So now we have a another user who is using LIB into his application APP
    > (also c++ application).
    > This APP is compiled with an older g++ compiler more specifically g++ 3.3.6.
    > However for now he wants that his users should be able to use his
    > application on older linux.
    >
    > He is therefore sending his libstdc++.so.* and libgcc.so* to the
    > end-users...


    Ok, everything should work.

    > Now hell breaks loose though... since the library LIB starts to act weird
    > and not as documented. This has caused a number of days of work only to
    > realise what the problem is.


    You didn't describe what the problem is; not even its symptoms.
    All we have is "acts weird"; not much help could be provided with
    that problem description :-(

    > So LIB is suppose to use it's own private copy of libstdc++ instead of the
    > public one...


    And do you have any indication that's *not* what is happening?

    > however I'm not sure about the legality of sending out
    > libstdc++ libraries to other machines.


    libstdc++ is GPL'd, with a special "runtime exception".
    It is certainly legal to send libstdc++.so to other machines,
    provided you satisfy GPL redistribution requirements.

    Distribution of binaries that are statically linked with libstdc++
    is more questionable in my mind, but I believe "runtime exception"
    covers it (but IANAL).

    > I said for now that the user should try to link the application statically
    > so they won't have a shared copy.
    >
    > I'm unsure about this whole scenario. There is very little and sparse
    > documentation on this on the internet... this doesn't help in actually
    > finding out which of these steps are legal and which should be avoided.
    >
    > Can anyone shed some light on this complex issue?


    Which issue? Is your question legal or technical?
    Usenet is the wrong place to ask for legal advice.
    And you didn't ask any techincal questions that I can see.

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

  4. Re: libstdc++ compatibility frustrations under linux x86

    >> Assume you have a static library LIB written in C++ that exports a C
    >> interface like LIB_init(), LIB_action() and LIB_free(). Internally this
    >> LIB is in C++ but from outsiders it must from C.

    >
    > I think you might need to rephrase the last sentence.
    >


    Essentially what I'm saying is that the library is writen in C++ but must be
    free from any C++ dependencies.
    It must work the same way as if you wrote the library in C.
    This means that any dependency on libstdc++ must be gone.

    In my other post I clarify the problem further.

    -- Henrik



  5. Re: libstdc++ compatibility frustrations under linux x86


    > You didn't describe what the problem is; not even its symptoms.
    > All we have is "acts weird"; not much help could be provided with
    > that problem description :-(
    >


    I didn't even realise myself at the time of writing what the problem
    actually was.
    Sorry for not being precise.

    However now I'm a little smarter.

    It turns out so far to be a problem with libgcc.
    Currently libgcc is not being relinked with the library. This means that it
    depends on the libgcc version running with the compiler used to link the
    library.
    In the current case the library it self is compiled with gcc 3.4.6 and being
    linked with 3.3.6.

    When end-users are using the final application with libgcc.so of version
    3.3.6 then the library fails deep inside.
    When they use a newer version of libgcc then it works.
    So you ask what does "not work" mean? Essentially the library is doing wrong
    computations which results in a wrong result.
    It is running a sequence with known input giving a known output. When a
    newer version of libgcc is used then it works. If version 3.3.6 is used then
    it fails.

    My suspecion is that the different versions of libgcc doesn't have binary
    compatibility even though the symbols are the same. After all the
    application is linked without problems.

    The next step is to work with the users to re-link libgcc and see if it does
    a difference. However that has not yet happend.

    I didn't consider that it was necessary to relink libgcc though.
    This seems to be the only logical explanation though (as far as the reports
    I've received from users so far).

    Thanks.

    -- Henrik



+ Reply to Thread