Help! Linking against shared libraries produces non-sharing exe - Questions

This is a discussion on Help! Linking against shared libraries produces non-sharing exe - Questions ; I'm trying to link my product's exes against shared libraries that I have also created. The product/platform details are: Red Hat Linux Advanced Server release 2.1AS/i686 gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-118.7.2) GNU ld version 2.11.90.0.8 (with ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Help! Linking against shared libraries produces non-sharing exe

  1. Help! Linking against shared libraries produces non-sharing exe

    I'm trying to link my product's exes against shared libraries that I have
    also created. The product/platform details are:

    Red Hat Linux Advanced Server release 2.1AS/i686
    gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-118.7.2)
    GNU ld version 2.11.90.0.8 (with BFD 2.11.90.0.8)

    I'm new to Linux but not to Unix. Our product is successfully deployed under
    AIX and Digital Unix. I compile each source file with the following command:

    g++ -W -pthread -fpermissive -w -c -fno-strict-prototype -O3

    each source file is then inserted into 1 of approx. 20 libraries.


    I then link the archive files to produce shared libraries with the following
    commands.

    g++ -shared -L/usr/lib -Wl,-soname,${curr_lib}.so \
    -o ${curr_lib}.so.1.2 \
    -Wl,--whole-archive,${curr_lib}.a \
    -Wl,--no-whole-archive \
    -Wl,-rpath, ./

    ln -s ${curr_lib}.so.1.2 ${curr_lib}.so.1
    ln -s ${curr_lib}.so.1 ${curr_lib}.so

    I don't get any errors.


    I then link one of our many exes against the shared libraries created above
    as well as other libraries required by our product with the commands below:

    g++ ${curr_exe}.o -o ${curr_exe} -Wl,--start-group libraries> -Wl,--end-group \
    -lstdc++-3-libc6.2-2-2.10.0 -lpthread -L directory>

    Again, there are no errors. When I run one of the exes it comes up and runs
    as usual but a ps -vsz shows that the process has approximately 95 megs of
    virtual space. If I run another instance of the exe the virtual size is the
    same. The 95 megs is the approximate size of all of our products shared
    libries. On the other Unix platforms the virtual size is much lower. It
    seems that all our shared libries are being loaded for each instance of an
    exe. Over the last several days I have tried a variety of additional
    qualifiers in different combinations and orders. If I run ldd on one of our
    exes it contains references to each of our shared libries. If I run ldd on
    one of the shared libries it references only system shared libries and not o
    ther of our shared libries even though there are certainly references
    between several of our libries. I've consulted various documents but nothing
    seems to help. If I run a normal set of our applications we are quickly out
    of page space and the system grinds to a halt.

    Any help, thoughts, etc. appreciated.



  2. Re: Help! Linking against shared libraries produces non-sharing exe

    I left out the -fPIC qualifier which is used in the compilation step.
    "Alvin Belden" wrote in message
    news:19eaabf2d3b77fe3bebe1fe091b539f1@news.teranew s.com...
    > I'm trying to link my product's exes against shared libraries that I have
    > also created. The product/platform details are:
    >
    > Red Hat Linux Advanced Server release 2.1AS/i686
    > gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-118.7.2)
    > GNU ld version 2.11.90.0.8 (with BFD 2.11.90.0.8)
    >
    > I'm new to Linux but not to Unix. Our product is successfully deployed

    under
    > AIX and Digital Unix. I compile each source file with the following

    command:
    >
    > g++ -W -pthread -fpermissive -w -c -fno-strict-prototype -O3
    >
    > each source file is then inserted into 1 of approx. 20 libraries.
    >
    >
    > I then link the archive files to produce shared libraries with the

    following
    > commands.
    >
    > g++ -shared -L/usr/lib -Wl,-soname,${curr_lib}.so \
    > -o ${curr_lib}.so.1.2 \
    > -Wl,--whole-archive,${curr_lib}.a \
    > -Wl,--no-whole-archive \
    > -Wl,-rpath, ./
    >
    > ln -s ${curr_lib}.so.1.2 ${curr_lib}.so.1
    > ln -s ${curr_lib}.so.1 ${curr_lib}.so
    >
    > I don't get any errors.
    >
    >
    > I then link one of our many exes against the shared libraries created

    above
    > as well as other libraries required by our product with the commands

    below:
    >
    > g++ ${curr_exe}.o -o ${curr_exe} -Wl,--start-group > libraries> -Wl,--end-group \
    > -lstdc++-3-libc6.2-2-2.10.0 -lpthread -L > directory>
    >
    > Again, there are no errors. When I run one of the exes it comes up and

    runs
    > as usual but a ps -vsz shows that the process has approximately 95 megs of
    > virtual space. If I run another instance of the exe the virtual size is

    the
    > same. The 95 megs is the approximate size of all of our products shared
    > libries. On the other Unix platforms the virtual size is much lower. It
    > seems that all our shared libries are being loaded for each instance of an
    > exe. Over the last several days I have tried a variety of additional
    > qualifiers in different combinations and orders. If I run ldd on one of

    our
    > exes it contains references to each of our shared libries. If I run ldd on
    > one of the shared libries it references only system shared libries and not

    o
    > ther of our shared libries even though there are certainly references
    > between several of our libries. I've consulted various documents but

    nothing
    > seems to help. If I run a normal set of our applications we are quickly

    out
    > of page space and the system grinds to a halt.
    >
    > Any help, thoughts, etc. appreciated.
    >
    >




  3. Re: Help! Linking against shared libraries produces non-sharing exe

    "Alvin Belden" writes:
    >I'm trying to link my product's exes against shared libraries that I have
    >also created. The product/platform details are:
    >



    >
    >I then link one of our many exes against the shared libraries created above
    >as well as other libraries required by our product with the commands below:
    >
    >g++ ${curr_exe}.o -o ${curr_exe} -Wl,--start-group >libraries> -Wl,--end-group \
    > -lstdc++-3-libc6.2-2-2.10.0 -lpthread -L >directory>


    What does

    $ ldd ${curr_exe}

    show?

    scott

  4. Re: Help! Linking against shared libraries produces non-sharing exe

    ldd output contains references to each of our 21 shared libraries and the
    following:

    /usr/mq50/lib/libdmq.so => /usr/mq50/lib/libdmq.so (0x44d40000)
    libdl.so.2 => /lib/libdl.so.2 (0x44db6000)
    libcrypt.so.1 => /lib/libcrypt.so.1 (0x44dbb000)
    libct.so => /usr/sybase125/lib/libct.so (0x44de8000)
    libintl.so => /usr/sybase125/lib/libintl.so (0x44e57000)
    libcomn.so => /usr/sybase125/lib/libcomn.so (0x44e61000)
    libcs.so => /usr/sybase125/lib/libcs.so (0x44ec0000)
    libsybtcl.so => /usr/sybase125/lib/libsybtcl.so (0x44ecd000)
    libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
    (0x44f1400
    0)
    libpthread.so.0 => /lib/i686/libpthread.so.0 (0x44f57000)
    libm.so.6 => /lib/i686/libm.so.6 (0x44f88000)
    libc.so.6 => /lib/i686/libc.so.6 (0x44fab000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

    Al
    "Scott Lurndal" wrote in message
    news:FCVrb.284$dI6.15336640@newssvr21.news.prodigy .com...
    > "Alvin Belden" writes:
    > >I'm trying to link my product's exes against shared libraries that I have
    > >also created. The product/platform details are:
    > >

    >
    >
    > >
    > >I then link one of our many exes against the shared libraries created

    above
    > >as well as other libraries required by our product with the commands

    below:
    > >
    > >g++ ${curr_exe}.o -o ${curr_exe} -Wl,--start-group > >libraries> -Wl,--end-group \
    > >

    libraries> -lstdc++-3-libc6.2-2-2.10.0 -lpthread -L
    > >directory>

    >
    > What does
    >
    > $ ldd ${curr_exe}
    >
    > show?
    >
    > scott




+ Reply to Thread