Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Help! Linking against shared libraries produces non-sharing exe

19 views
Skip to first unread message

Alvin Belden

unread,
Nov 10, 2003, 1:34:36 PM11/10/03
to
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 <list of shared
libraries> -Wl,--end-group \
<additional libraries> -lstdc++-3-libc6.2-2-2.10.0 -lpthread -L<search
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.


Alvin Belden

unread,
Nov 10, 2003, 3:28:51 PM11/10/03
to
I left out the -fPIC qualifier which is used in the compilation step.
"Alvin Belden" <alvin....@siemens.com> wrote in message
news:19eaabf2d3b77fe3...@news.teranews.com...

Scott Lurndal

unread,
Nov 10, 2003, 6:58:29 PM11/10/03
to
"Alvin Belden" <alvin....@siemens.com> 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 <list of shared
>libraries> -Wl,--end-group \
> <additional libraries> -lstdc++-3-libc6.2-2-2.10.0 -lpthread -L<search
>directory>

What does

$ ldd ${curr_exe}

show?

scott

Alvin Belden

unread,
Nov 10, 2003, 9:30:58 PM11/10/03
to
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" <sc...@slp53.sl.home> wrote in message
news:FCVrb.284$dI6.15...@newssvr21.news.prodigy.com...

0 new messages