Very Computer

> 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.

>> 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.

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

>> | 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.

> > | 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?

> >> 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.

> > > | 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.

> 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.