Using gcc for building shared libraries

Using gcc for building shared libraries

Post by Andy Plat » Tue, 16 Mar 1999 04:00:00



We have a product used for debugging applications. This creates shared
libraries from a set of 'debugging actions' specified by the user in a
largely-C based file.

Currently, we compile and link the user's actions using the Sun Workshop
C compiler but we wish to support using gcc. However, there is a problem
when building shared libraries with gcc if you specify the '-z defs'
option since the gcc startup object file (crt1.o) references main.

For instance:

gcc -z defs -G -o libgcctest.ual testgcclib.c

gives:

Undefined                       first referenced
 symbol                             in file
main                              
/opt/gnat_311/lib/gcc-lib/sparc-sun-solaris2.5.1/2.8.1/crt1.o

Is there any way of getting around this on the command line, apart from
removing the '-z defs' option. I wondered about using the linker's
mapfile option to create a dummy symbol for main but attempts at doing
this have not been successful. An alternative solution would be to
define a weak symbol for main in assembler and link with this file. That
works but I would prefer to find a less messy, more general purpose
solution.

Any assistance is appreciated,

Andy Platt.

--
I'm not really here - it's just your warped imagination.

 
 
 

1. Using libtool to build shared libraries that depend on static libraries

I'm trying to link an object file and a static library into a shared
library.  I can easily do this with gcc, but now I would like to use libtool
for more portability.  But, libtool gives me an error like this when I try
to link:

*** Warning: This library needs some functionality provided by -lplugin.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module libsyncmal.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.

Bummer.  I tried following the advice of the first warning, and created a
shared version of the static library.  I thought I had succeeded when
libtool produced a shared library, but the shared library produced depended
on the shared version of the static library.  Not what I wanted.

Can libtool do this?  Any help would be greatly appreciated.  I can post a
snapshot of the code on my website if that would help.

Thanks,
Jason
--
Jason Day                                       jasonday at
http://jasonday.home.att.net                    worldnet dot att dot net

"Of course I'm paranoid, everyone is trying to kill me."
    -- Weyoun-6, Star Trek: Deep Space 9

2. xf86config

3. Help with building shared libraries with dependencies on other shared libraries

4. xgroups uploaded

5. Problems with shared libraries built in gcc...

6. config for S3_764 chip

7. Building shared library on Solaris by gcc

8. Netscape Setup Part 2

9. Using tools to build shared libraries

10. Building/using SVR4 (AT&T) shared libraries (i486 platform)

11. Using 'ld' to build an ELF SHARED LIBRARY

12. need help building/using a shared library

13. Building a shared library using curses?