where goith the static libs?

where goith the static libs?

[Leslie Rohde]

I will grant that I am new to RHUG, and to Autotools
in general, but I it looks like this should work, and does
not.

In my setup, it appears that the building of static libs
is enabled, and the .o files are indeed in the tree, but
only .so and .la are put in .libs.

I am using gcj-ssa on a RH9 system and a new dl
of the rhug sources.  the libtool version string
says 1.4e (is this correct?).

All help is appreciated.

best regards

-- 
--
Leslie Rohde
http://www.optitext.com

Re: where goith the static libs?

[Jeff Sturm]

On Fri, 13 Feb 2004, Leslie Rohde wrote:
> In my setup, it appears that the building of static libs
> is enabled, and the .o files are indeed in the tree, but
> only .so and .la are put in .libs.

Last I checked, rhug uses a broken libtool configuration.

http://sources.redhat.com/ml/rhug-rhats/2002-12/msg00031.html

Jeff

Re: where goith the static libs?

[Jeff Sturm]

On Mon, 16 Feb 2004, Leslie Rohde wrote:
> the first thing to notice is that most java programs do
> enough late binding that you can not depend on linking
> to include everything, so doing -Wl,-whole-archive when
> building the final app is pretty much a given.  (and don't
> forget to turn it off before the std libs are tacked on, 'cause
> that _really_ doesn't work!)

Right.  I suspect many gcj users avoid static libs for this reason.

> what i am really trying to do is to build a _standalone_
> xml-savvy application (file size is a non-issue) that i can copy
> to an arbitrary linux box (rh7.3 or later) without vetting what
> versions of the gcc/gcj runtime exist.  the assumption is that i do
> _not_ have admin priv, so i can not do an 'install' per se.

Well... you don't need admin privs to install/use a DSO in a user
directory.  Perhaps a tarball of executable + DSOs doesn't meet your
standalone requirement though.

> as a minimum, i will link statics of xerces and xalan plus a
> couple non-rhug packages  (nekohtml being one).  fine,
> but i also need to separate myself from libgcj/libgcc and on
> that i have had no joy using -static and -static-libgcc in any
> combination.  i just started trying explicit includes of the
> static versions of the standard libs in conjunction with
> -nostdlib and friends, but have not quite found the right
> arrangement of runes.  am i on the right track?  what
> (known) land mines exist?

If you require no dependencies on libgcj.so or libgcc_s.so, it'll be far
simpler to configure/build gcj/libgcj with --disable-shared than
dealing with -nostdlib and all the required libraries (IMO, having done it
both ways myself) especially if you need a portable makefile.

I did just that with an uberbaum tree on RH 7.3, to create an executable
that runs on any Red Hat release >= 7.3.  (If you don't use an uberbaum or
otherwise unified GCC tree, make sure you get up-to-date binutils from
somewhere.  The gas distributed with RH 7.3 is no longer sufficient to
build the 3.4 branch, for instance.)

Good luck,

Jeff