libgcc_s.so.1 and libgcj.so.4

[Andrew Haley]

Erik Poupaert writes:
 > 
 > I have to refine my previous question.
 > 
 > When I ldd on a gcj executable on linux, I can typically see the following
 > dependencies:
 > 
 > (A) The following dependencies are related to my gcj snapshot
 > libgcc_s.so.1 => /usr/local/gcc/3.3/20030414/lib/libgcc_s.so.1
 > libgcj.so.4 => /usr/local/gcc/3.3/20030414/lib/libgcj.so.4
 > 
 > (B) The following dependencies are not related to my gcj snapshot:
 > libm.so.6
 > libpthread.so.0
 > libdl.so.2
 > libc.so.6
 > /lib/ld-linux.so.2
 > 
 > The dependencies in (B) can happily remain dynamic. It's just a requirement
 > for the target (deployment) system to have all these libraries in place. I
 > can live with that.
 > 
 > The dependencies in (A) are only present on my development
 > machine. I cannot expect users to go and find and then install the
 > exact gcc snapshot in order to run my application. I also do not
 > want to pollute the user's machine with libraries which are
 > absolutely specific to my application. No one else is going to
 > deploy applications and expect that the exact snapshot libraries
 > are present as for my application!

Why not?

If you're deployong on Linux, I assume you'll either be using some
sort of package manager like RPM or you'll be shipping source.  If
you're shipping binaries via RPM, you can depend on the appropriate
version of libgcj and libgcc.  If you're not using any of the standard
versions of libgcc and libgcj that come with linux distributions, you
can provide your own RPM.  It's better to use a shipped version of
libgcj and libgcc, because if there are any bug fixes they'll be
automatically applied.

 > Therefore, I would want to link libgcc_s.a and libgcj.a statically
 > into the executable's body. The other dependencies (B) will, for
 > their part, be expected to be present on the user's machine.

This is a bad idea, for reasons I already explained.  Nonetheless, you
can do this by invoking the linker by hand.

Andrew.