static class members, shared libs and other vegetables - Linux

This is a discussion on static class members, shared libs and other vegetables - Linux ; Hi All, I'm trying to create a quick-and-dirty solution to a problem one of our customer requires: one of the libs in our product needs to be instantiated two times. The problem is that it contains many static members. Of ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: static class members, shared libs and other vegetables

  1. static class members, shared libs and other vegetables

    Hi All,

    I'm trying to create a quick-and-dirty solution to a problem one of
    our customer requires: one of the libs in our product needs to be
    instantiated two times. The problem is that it contains many static
    members.

    Of course changing the static members to be non-static is the best
    solution, unfortunately the code base is pretty big, and this would
    require a lot of resources, which, unsurprisingly, we don't have.

    Our first solution was to compile all libraries to a second set of
    libraries, and load the two sets separately. This solution worked on
    Windows, and we successful created two instances of every static
    member in the system.

    The solution doesn't work on Linux, as static members for some reason
    are shared across the libraries, although the libraries are loaded
    dynamically at the start of the program. Checking the library instance
    I can see that we have different handles, and global variables are not
    shared between the instances. Alas, static members in the classes are
    shared which eliminates the suggested solution.

    One way to solve this issue is, naturally, putting the code behind one
    namespace, compiling it, changing the namespace and compiling the code
    again. Unfortunately, this solution is too costly to implement since
    the project contains a large number of files that should be changed.
    In addition, this solution will be disposed of in the near future as
    the static variables are removed.

    Is there a quicker and dirtier way to solve this issue? Maybe some
    script or switch to compile all code under a single namespace.

    I'm desperate.

    Maor


  2. Re: static class members, shared libs and other vegetables

    "Maor Avni" writes:

    > I'm trying to create a quick-and-dirty solution to a problem one of
    > our customer requires: one of the libs in our product needs to be
    > instantiated two times. The problem is that it contains many static
    > members.

    ....
    > Our first solution was to compile all libraries to a second set of
    > libraries, and load the two sets separately. This solution worked on
    > Windows, and we successful created two instances of every static
    > member in the system.
    >
    > The solution doesn't work on Linux, as static members for some reason
    > are shared across the libraries, although the libraries are loaded
    > dynamically at the start of the program.


    This is *expected*.

    Win32 uses a "DLL is a self-contained entity; nothing should change
    its behaviour once it has been built" model.

    Most UNIXes use a "linking against DSO is just like linking against
    archive; you should be able to override any symbols in it with your
    own" model. The "first instance" of your DSO overrides symbols in
    the "second instance".

    > One way to solve this issue is, naturally, putting the code behind one
    > namespace, compiling it, changing the namespace and compiling the code
    > again. Unfortunately, this solution is too costly to implement since
    > the project contains a large number of files that should be changed.
    > In addition, this solution will be disposed of in the near future as
    > the static variables are removed.
    >
    > Is there a quicker and dirtier way to solve this issue? Maybe some
    > script or switch to compile all code under a single namespace.


    Probably. You didn't specify whether client code depends on any of
    the static data being "exported" from the DSO, but given that
    "two DLL solution" worked on Win32, the answer is probably no.

    In that case, you can hide (make local) all the static data inside
    the DSO with a linker script, and achieve behaviour that is exactly
    equivalent to what you have on Win32.

    Try "info ld" -> Scripts -> VERSION

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

  3. Re: static class members, shared libs and other vegetables

    On 2007-03-27, Paul Pluzhnikov wrote:

    > Win32 uses a "DLL is a self-contained entity; nothing should change
    > its behaviour once it has been built" model.
    >
    > Most UNIXes use a "linking against DSO is just like linking against
    > archive; you should be able to override any symbols in it with your
    > own" model. The "first instance" of your DSO overrides symbols in
    > the "second instance".


    can you point me to a good reference that covers these differences.
    I've been put in-charge of porting some software
    (http://www.treshna.com/software/paymaster) to windows (using i586mingw32)
    and it's proving challenging, the code compiles ok, but some of the 'plugin'
    DLLs won't link.

    --

    Bye.
    Jasen

+ Reply to Thread