Building shared libraries that contain static libraries.

Building shared libraries that contain static libraries.

Post by Simon Wie » Tue, 05 Nov 2002 18:42:34



I am trying to build a shared library in C++ which incorporates a
third party library which is only available for static linking. I am
experiencing the same problem on both Solaris 2.7 and Linux (RH 7.0),
although a windows version works fine.

I am getting an unresolved symbol error when I try and load the shared
library and the symbol it is looking for is in the static library that
was linked with my code. I believe this is related to the way the
WSpro 5 compiler and gcc 2.96 compiler work with static libraries
linked in dynamic libraries. I have been told that the compiler does
not actually link the static elements in but expects any client apps
to link in the static libraries as well. My problem here is that the
client is a java app using JNI so I cannot link in the static
libraries.

Is my understanding correct and is there any way to force either
compiler to include the static components ? I have approached the 3rd
party vendor and they are quoting in excess of 6 months to get a
dynamic version of their library available, I have to complete this by
Christmas so this is not an option.

Thanks

Simon

 
 
 

Building shared libraries that contain static libraries.

Post by M?ns Rullg? » Tue, 05 Nov 2002 18:53:59



> I am trying to build a shared library in C++ which incorporates a
> third party library which is only available for static linking. I am
> experiencing the same problem on both Solaris 2.7 and Linux (RH 7.0),
> although a windows version works fine.

> Is my understanding correct and is there any way to force either
> compiler to include the static components ? I have approached the 3rd
> party vendor and they are quoting in excess of 6 months to get a
> dynamic version of their library available, I have to complete this by
> Christmas so this is not an option.

You could try

  ld -shared -o libfoo.so --whole-archive libfoo.a

It will (almost certainly) fail on Solaris, but might work in
Linux/Intel.

--
M?ns Rullg?rd


 
 
 

Building shared libraries that contain static libraries.

Post by Kenny McCorma » Tue, 05 Nov 2002 21:05:37





>> I am trying to build a shared library in C++ which incorporates a
>> third party library which is only available for static linking. I am
>> experiencing the same problem on both Solaris 2.7 and Linux (RH 7.0),
>> although a windows version works fine.

>> Is my understanding correct and is there any way to force either
>> compiler to include the static components ? I have approached the 3rd
>> party vendor and they are quoting in excess of 6 months to get a
>> dynamic version of their library available, I have to complete this by
>> Christmas so this is not an option.

>You could try

>  ld -shared -o libfoo.so --whole-archive libfoo.a

>It will (almost certainly) fail on Solaris, but might work in
>Linux/Intel.

This is not rocket science - in fact, this question is asked and answered
often enough for it to achieve FAQ status.  So, the usual advice to use
google and/or the FAQ's is appropriate.

The standard answer is use "ar" to pull all of the .o's out of the .a and
then build a shared lib from all the .o's.

 
 
 

Building shared libraries that contain static libraries.

Post by Ralf Fasse » Tue, 05 Nov 2002 22:25:18



| The standard answer is use "ar" to pull all of the .o's out of the
| .a and then build a shared lib from all the .o's.

Wouldn't this require a -fPIC of some sort for the .o files to be
compiled with?

R'

 
 
 

Building shared libraries that contain static libraries.

Post by M?ns Rullg? » Tue, 05 Nov 2002 22:56:57




> | The standard answer is use "ar" to pull all of the .o's out of the
> | .a and then build a shared lib from all the .o's.

> Wouldn't this require a -fPIC of some sort for the .o files to be
> compiled with?

That depends on OS and architecture.  On Linux/x86 and Linux/Alpha it
works.  On Solaris/SPARC it doesn't.

--
M?ns Rullg?rd

 
 
 

Building shared libraries that contain static libraries.

Post by Kenny McCorma » Wed, 06 Nov 2002 00:10:24






>> | The standard answer is use "ar" to pull all of the .o's out of the
>> | .a and then build a shared lib from all the .o's.

>> Wouldn't this require a -fPIC of some sort for the .o files to be
>> compiled with?

>That depends on OS and architecture.  On Linux/x86 and Linux/Alpha it
>works.  On Solaris/SPARC it doesn't.

That can't be true on the face of it (there must be some other sense in
which it is true, or else you wouldn't be saying it).

The reason it isn't true is that I have done exactly this on Solaris.
For further info, you might want to Google for a thread of mine awhile back
that illustrated how w/o -fPIC, the shared lib still works (on Solaris),
albeit non-optimally.

 
 
 

Building shared libraries that contain static libraries.

Post by Paul Pluzhniko » Wed, 06 Nov 2002 01:05:04





> > | The standard answer is use "ar" to pull all of the .o's out of the
> > | .a and then build a shared lib from all the .o's.

> > Wouldn't this require a -fPIC of some sort for the .o files to be
> > compiled with?

The -fPIC is never required -- in the absense of it the library
text will be written to by the loader (during relocation process),
which will make it effectively non-shareable between processes,
but it will still work.

Quote:> That depends on OS and architecture.  On Linux/x86 and Linux/Alpha it
> works.  On Solaris/SPARC it doesn't.

It works just as well on Solaris, you just have to provide
proper flags to 'ld' ... In particular, you *must not* use
'-z text' (which gcc adds when you use -shared).

Cheers,
--
In order to understand recursion you must first understand recursion.

 
 
 

Building shared libraries that contain static libraries.

Post by M?ns Rullg? » Wed, 06 Nov 2002 00:53:37



> >> | The standard answer is use "ar" to pull all of the .o's out of the
> >> | .a and then build a shared lib from all the .o's.

> >> Wouldn't this require a -fPIC of some sort for the .o files to be
> >> compiled with?

> >That depends on OS and architecture.  On Linux/x86 and Linux/Alpha it
> >works.  On Solaris/SPARC it doesn't.

> That can't be true on the face of it (there must be some other sense in
> which it is true, or else you wouldn't be saying it).

> The reason it isn't true is that I have done exactly this on Solaris.
> For further info, you might want to Google for a thread of mine awhile back
> that illustrated how w/o -fPIC, the shared lib still works (on Solaris),
> albeit non-optimally.

What I'm saying is based on my own experience.  The Solaris linker
always gives a bunch of warnings like these:

$ gcc -shared -o libfoo.so png.o
Text relocation remains                         referenced
    against symbol                  offset      in file
memset                              0x6a8       png.o
[lots of similar lines]
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status

Compiling with -fPIC solves this.  On Linux/x86 and Linux/Alpha it
usually works with or w/o -fPIC, but I've seen it fail.

--
M?ns Rullg?rd

 
 
 

Building shared libraries that contain static libraries.

Post by Simon Wie » Wed, 06 Nov 2002 19:10:20






> > > | The standard answer is use "ar" to pull all of the .o's out of the
> > > | .a and then build a shared lib from all the .o's.

> > > Wouldn't this require a -fPIC of some sort for the .o files to be
> > > compiled with?

> The -fPIC is never required -- in the absense of it the library
> text will be written to by the loader (during relocation process),
> which will make it effectively non-shareable between processes,
> but it will still work.

> > That depends on OS and architecture.  On Linux/x86 and Linux/Alpha it
> > works.  On Solaris/SPARC it doesn't.

> It works just as well on Solaris, you just have to provide
> proper flags to 'ld' ... In particular, you *must not* use
> '-z text' (which gcc adds when you use -shared).

> Cheers,

Do you have the prooper flags for ld ? I have tried this with linux
and solaris and I get errors with both. On it fails with a number of
undefined references to things like memset and malloc, on solaris I
get a number of multiply defined errors.

The original ld with --whole-arcive seemed to work for linux but then
gave an undefined reference for __pure_virtual but now I cant even get
that working again.

Simon
Thanks

 
 
 

Building shared libraries that contain static libraries.

Post by Paul Pluzhniko » Thu, 07 Nov 2002 13:04:56



> Do you have the prooper flags for ld ? I have tried this with linux
> and solaris and I get errors with both. On it fails with a number of
> undefined references to things like memset and malloc, on solaris I
> get a number of multiply defined errors.

Proper flags depend on exactly what you are doing.
Assuming you want to build a C++ shared library with
g++ on solaris, and you want to include all of libVendor.a,
here is what to do:

  mkdir junk; cd junk; ar xv /path/to/libVendor.a; cd ..
  g++ -v -shared -o libResult.so obj1.o obj2.o junk/*.o

the command above should fail with many 'text relocations
remain' errors, since objects in libVendor.a were not
-fPIC/-KPIC compiled ...

Note the actual 'ld' command that g++ used (you'll see
it because of the -v flag).
Capture that command, remove '-z text' from it, and repeat it.
This 'ld' command should succeed, and you should now have a
"shared but not shareable" libResult.so.

In the original message you said:

Quote:> I have been told that the compiler does
> not actually link the static elements in but expects any client apps
> to link in the static libraries as well. My problem here is that the
> client is a java app using JNI so I cannot link in the static
> libraries.

This is a misconception: you *can* in fact build your own 'java'
executable, and link it with whatever static libraries you wish.
Note: you don't need to rebuild all of java runtime; just link your
new exe against libjvm.so already included in your JRE distribution.

The main in 'java' is a 1-page source (well, it's actually 200-lines)
which invokes InitializeJVM(), then calls 'main' method in the class
that was passed in. You can get the source to jdk 1.{234}, and study
hotspot/src/os/solaris/launcher/java.c. Many (most?) JNI books also
have sample code for embedding java VM into your compiled executable.

Cheers,
--  
In order to understand recursion you must first understand recursion.

 
 
 

Building shared libraries that contain static libraries.

Post by Simon Wieh » Thu, 07 Nov 2002 21:06:38


Paul,

The building a new java executable sounds interesting, it might be the
quickest way to solve my problem until I can force the vendor of the third
party library to give me a shared library.

I have managed to build a .so on Linux using the various methods mentioned
on this thread and I can now load my own shared library but now I get an
unhandled exception when I try and access the .so I create from the third
party library.

Are there any onlune resources that tell me how to build my own java
executable on Linux ?

Thanks

Simon Wiehe


> > Do you have the prooper flags for ld ? I have tried this with linux
> > and solaris and I get errors with both. On it fails with a number of
> > undefined references to things like memset and malloc, on solaris I
> > get a number of multiply defined errors.

> Proper flags depend on exactly what you are doing.
> Assuming you want to build a C++ shared library with
> g++ on solaris, and you want to include all of libVendor.a,
> here is what to do:

>   mkdir junk; cd junk; ar xv /path/to/libVendor.a; cd ..
>   g++ -v -shared -o libResult.so obj1.o obj2.o junk/*.o

> the command above should fail with many 'text relocations
> remain' errors, since objects in libVendor.a were not
> -fPIC/-KPIC compiled ...

> Note the actual 'ld' command that g++ used (you'll see
> it because of the -v flag).
> Capture that command, remove '-z text' from it, and repeat it.
> This 'ld' command should succeed, and you should now have a
> "shared but not shareable" libResult.so.

> In the original message you said:
> > I have been told that the compiler does
> > not actually link the static elements in but expects any client apps
> > to link in the static libraries as well. My problem here is that the
> > client is a java app using JNI so I cannot link in the static
> > libraries.

> This is a misconception: you *can* in fact build your own 'java'
> executable, and link it with whatever static libraries you wish.
> Note: you don't need to rebuild all of java runtime; just link your
> new exe against libjvm.so already included in your JRE distribution.

> The main in 'java' is a 1-page source (well, it's actually 200-lines)
> which invokes InitializeJVM(), then calls 'main' method in the class
> that was passed in. You can get the source to jdk 1.{234}, and study
> hotspot/src/os/solaris/launcher/java.c. Many (most?) JNI books also
> have sample code for embedding java VM into your compiled executable.

> Cheers,
> --
> In order to understand recursion you must first understand recursion.

 
 
 

1. Building shared library which includes static libraries

SPARC Solaris 2.4 using 4.0.1 SPARC C++ compiler.

My application comprises of an executable and a number of shared libraries.
One of the shared libraries is an interface to Oracle using OCI calls. This
shared (database) library was built as follows:

    ld -G -dy -B symbolic -o my_shared_lib.so mod1.o mod2.o ... Oracle static
        libraries ... more libraries..

mod1.o, mod2.o ... were compiled with the -PIC option.

Now, when I run my application, I crash, with a bad opcode, whenever any
Oracle function is accessed from the mod1.o mod2.o ... modules. If I link the
Oracle static libraries with the executable, then everything is fine. However,
that is not what I want.

How can I get the above to work, or is it not possible? Any comments/advice
will be greatfully appreciated.

Thanks in advance,

Sanjay Agrawal
--

555 Twin Dolphin Drive #400      Voice: (415)594-8754
Redwood City, CA 94065           Fax:   (415)594-8645

2. SCO binaries under kernel 2.x?

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

4. Using major/minor device numbers to determine SCSI or ATAPI CD-ROM drives

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

6. Usermode PPP

7. Compiling static libraries as shared libraries

8. Cannot browse the web in the apache server

9. Can a static library be compiled into a shared library?

10. Converting a Static Library to a Shared Library

11. Using static libraries and shared libraries in same program?

12. link static libraries into a shared library

13. libtool and shared libraries with static library references