static linking

static linking

[Daniel Andrzejewski]

Hi all,

I have a problem with gcj. I have read couple threads here, but I still have no idea how to fix my 
problem. Usually people say that this is hard but doable, but they don't give much directions.

I'm trying to do it for a system where there's no shared libraries, so I must not even dynamically 
link libc.

I successfully build gcc 4.3.0 with --disable-shared option. I can successfully compile a java 
program, but the executable is still dynamically linked.

/scratch/daniel> ldd ./HelloWorld
         libz.so.1 => /lib64/libz.so.1 (0x00002adcd28dd000)
         libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002adcd29f0000)
         libc.so.6 => /lib64/tls/libc.so.6 (0x00002adcd2b04000)
         libm.so.6 => /lib64/tls/libm.so.6 (0x00002adcd2d26000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00002adcd2e7d000)
         librt.so.1 => /lib64/tls/librt.so.1 (0x00002adcd2f80000)
         /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00002adcd27c6000)

When I use -static flag while compiling I get some warnings, but the executable gets compiled.

/scratch/daniel> gcj --main=HelloWorld -o HelloWorld -static HelloWorld.java 

...
warnings
...
/scratch/daniel> file HelloWorld
HelloWorld: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, statically 
linked, not stripped


And the problem is at the runtime:

/scratch/daniel> ./HelloWorld
Aborted


Has anyone solved this issue yet?

Thank you for you response.

Daniel Andrzejewski

-- 
Daniel Andrzejewski
student IT Administrator
Elec Engr & Comp Science
University of Tennessee
(865) 974 - 4388 (work)

"Investment in knowledge always pays the best interest" Benjamin Franklin
--

Re: static linking

[David Daney]

Daniel Andrzejewski wrote:
> Hi all,
> 
> I have a problem with gcj. I have read couple threads here, but I still 
> have no idea how to fix my problem. Usually people say that this is hard 
> but doable, but they don't give much directions.
> 
> I'm trying to do it for a system where there's no shared libraries, so I 
> must not even dynamically link libc.

One might ask the question: Why?

> 
> I successfully build gcc 4.3.0 with --disable-shared option. I can 
> successfully compile a java program, but the executable is still 
> dynamically linked.
> 
> /scratch/daniel> ldd ./HelloWorld
>         libz.so.1 => /lib64/libz.so.1 (0x00002adcd28dd000)
>         libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002adcd29f0000)
>         libc.so.6 => /lib64/tls/libc.so.6 (0x00002adcd2b04000)
>         libm.so.6 => /lib64/tls/libm.so.6 (0x00002adcd2d26000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00002adcd2e7d000)
>         librt.so.1 => /lib64/tls/librt.so.1 (0x00002adcd2f80000)
>         /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
> (0x00002adcd27c6000)
> 
> When I use -static flag while compiling I get some warnings, but the 
> executable gets compiled.
> 
> /scratch/daniel> gcj --main=HelloWorld -o HelloWorld -static 
> HelloWorld.java
> ...
> warnings
> ...

Do you know a priori that the content of the warnings is not relevant to this problem?  If not, please include them.

First start with only -static-libgcj to isolate C library problems from libgcj problems.


> /scratch/daniel> file HelloWorld
> HelloWorld: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for 
> GNU/Linux 2.4.1, statically linked, not stripped
> 
> 
> And the problem is at the runtime:
> 
> /scratch/daniel> ./HelloWorld
> Aborted
> 

That is not too helpful.  You need to run the thing under gdb and at a minimum see where it is failing (put a breakpoint on abort()). 


> 
> Has anyone solved this issue yet?
> 

I have not used a static glibc, but I successfully do static linking of libgcj.  Most problems come down to missing classes due to the linker not linking classes that are only referred to dynamically.

I put the following into my main code to force some necessary classes to be linked:

extern int _ZN3gnu4java6locale8Calendar6class$E;
int *dummy1 = &_ZN3gnu4java6locale8Calendar6class$E;

extern int _ZN3gnu4java6locale17LocaleInformation6class$E;
int *dummy2 = &_ZN3gnu4java6locale17LocaleInformation6class$E;

extern int _ZN3gnu3gcj7convert12Output_ASCII6class$E;
int *dummy3 = &_ZN3gnu3gcj7convert12Output_ASCII6class$E;

extern int _ZN3gnu3gcj7convert11Output_UTF86class$E;
int *dummy5 = &_ZN3gnu3gcj7convert11Output_UTF86class$E;

#ifdef STATIC_LIBGCJ_4_3
extern int _ZGr32_java$Sutil$Siso4217$_properties;
int *dummy6 = &_ZGr32_java$Sutil$Siso4217$_properties;

extern int _ZN3gnu3xml8aelfred29XmlParser6class$E;
int *dummy7 = &_ZN3gnu3xml8aelfred29XmlParser6class$E;

#endif


Note that either fewer or more classes may be needed by your application.

Re: static linking

[David Daney]

Daniel Andrzejewski wrote:
> Hi all,
> 
> I have a problem with gcj. I have read couple threads here, but I still 
> have no idea how to fix my problem. Usually people say that this is hard 
> but doable, but they don't give much directions.
> 

Also I assume you have seen this:

http://gcc.gnu.org/wiki/Statically_linking_libgcj

Re: static linking

[Daniel Andrzejewski]

David Daney wrote:
> Daniel Andrzejewski wrote:
>> Hi all,
>>
>> I have a problem with gcj. I have read couple threads here, but I 
>> still have no idea how to fix my problem. Usually people say that this 
>> is hard but doable, but they don't give much directions.
>>
> 
> Also I assume you have seen this:
> 
> http://gcc.gnu.org/wiki/Statically_linking_libgcj

Yes, I have seen it and tried, but it gave some errors that it didn't understand couple of those 
flags, e.g. --as-needed and --no-as-needed.

Daniel

-- 
Daniel Andrzejewski
student IT Administrator
Elec Engr & Comp Science
University of Tennessee
(865) 974 - 4388 (work)

"Investment in knowledge always pays the best interest" Benjamin Franklin
--

Re: static linking

[Daniel Andrzejewski]

David Daney wrote:
> Daniel Andrzejewski wrote:
>> Hi all,
>>
>> I have a problem with gcj. I have read couple threads here, but I 
>> still have no idea how to fix my problem. Usually people say that this 
>> is hard but doable, but they don't give much directions.
>>
>> I'm trying to do it for a system where there's no shared libraries, so 
>> I must not even dynamically link libc.
> 
> One might ask the question: Why?

Don't laugh, but I'm going to run it on a super computer (Cray XT), where on the compute nodes 
there's no shared libraries.

> 
>>
>> I successfully build gcc 4.3.0 with --disable-shared option. I can 
>> successfully compile a java program, but the executable is still 
>> dynamically linked.
>>
>> /scratch/daniel> ldd ./HelloWorld
>>         libz.so.1 => /lib64/libz.so.1 (0x00002adcd28dd000)
>>         libpthread.so.0 => /lib64/tls/libpthread.so.0 
>> (0x00002adcd29f0000)
>>         libc.so.6 => /lib64/tls/libc.so.6 (0x00002adcd2b04000)
>>         libm.so.6 => /lib64/tls/libm.so.6 (0x00002adcd2d26000)
>>         libdl.so.2 => /lib64/libdl.so.2 (0x00002adcd2e7d000)
>>         librt.so.1 => /lib64/tls/librt.so.1 (0x00002adcd2f80000)
>>         /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
>> (0x00002adcd27c6000)
>>
>> When I use -static flag while compiling I get some warnings, but the 
>> executable gets compiled.
>>
>> /scratch/daniel> gcj --main=HelloWorld -o HelloWorld -static 
>> HelloWorld.java
>> ...
>> warnings
>> ...
> 
> Do you know a priori that the content of the warnings is not relevant to 
> this problem?  If not, please include them.

I just thought it would mess up the message. But here you go:

/sw/xt/gcc/4.3.0/lib64/../lib64/libgcj.a(ltdl.o)(.text+0x341a): In function `sys_dl_open':
../../../../gcc/libjava/libltdl/ltdl.c:1114: warning: Using 'dlopen' in statically linked 
applications requires at runtime the shared libraries from the glibc version used for linking
/sw/xt/gcc/4.3.0/lib64/../lib64/libgcj.a(natSystemProperties.o)(.text+0x7b7): In function `hidden 
alias for void gnu::classpath::SystemProperties::insertSystemProperties(java::util::Properties*)':
../../../gcc/libjava/gnu/classpath/natSystemProperties.cc:97: warning: Using 'getpwuid_r' in 
statically linked applications requires at runtime the shared libraries from the glibc version used 
for linking
/sw/xt/gcc/4.3.0/lib64/../lib64/libgcj.a(natVMInetAddress.o)(.text+0x3bf): In function `hidden alias 
for java::lang::String* java::net::VMInetAddress::getHostByAddr(JArray<char>*)':
java/net/natVMInetAddress.cc:148: warning: Using 'gethostbyaddr_r' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
/sw/xt/gcc/4.3.0/lib64/../lib64/libgcj.a(natVMInetAddress.o)(.text+0x201): In function `hidden alias 
for JArray<JArray<char>*>* java::net::VMInetAddress::getHostByName(java::lang::String*)':
java/net/natVMInetAddress.cc:218: warning: Using 'gethostbyname_r' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking



> 
> First start with only -static-libgcj to isolate C library problems from 
> libgcj problems.
> 

If I do -static-libgcj instead of -static it compiles fine and runs perfectly, but it is dynamically 
linked then.

> 
>> /scratch/daniel> file HelloWorld
>> HelloWorld: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), 
>> for GNU/Linux 2.4.1, statically linked, not stripped
>>
>>
>> And the problem is at the runtime:
>>
>> /scratch/daniel> ./HelloWorld
>> Aborted
>>
> 
> That is not too helpful.  You need to run the thing under gdb and at a 
> minimum see where it is failing (put a breakpoint on abort()).

/scratch/daniel> gdb HelloWorld
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
...

(gdb) break 12
Breakpoint 1 at 0x400324: file /tmp/cc0TNqNE.i, line 12.
(gdb) run
Starting program: /scratch/daniel/HelloWorld

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) break 11
Breakpoint 2 at 0x40030e: file /tmp/cc0TNqNE.i, line 11.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /scratch/daniel/HelloWorld

Breakpoint 2, main (argc=1, argv=0x7fff29a68c38) at /tmp/cc0TNqNE.i:11
11      /tmp/cc0TNqNE.i: No such file or directory.
         in /tmp/cc0TNqNE.i
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb)


It's not clear to me why the temp file is missing.

> 
>>
>> Has anyone solved this issue yet?
>>
> 
> I have not used a static glibc, but I successfully do static linking of 
> libgcj.  Most problems come down to missing classes due to the linker 
> not linking classes that are only referred to dynamically.
> 
> I put the following into my main code to force some necessary classes to 
> be linked:
> 
> extern int _ZN3gnu4java6locale8Calendar6class$E;
> int *dummy1 = &_ZN3gnu4java6locale8Calendar6class$E;
> 
> extern int _ZN3gnu4java6locale17LocaleInformation6class$E;
> int *dummy2 = &_ZN3gnu4java6locale17LocaleInformation6class$E;
> 
> extern int _ZN3gnu3gcj7convert12Output_ASCII6class$E;
> int *dummy3 = &_ZN3gnu3gcj7convert12Output_ASCII6class$E;
> 
> extern int _ZN3gnu3gcj7convert11Output_UTF86class$E;
> int *dummy5 = &_ZN3gnu3gcj7convert11Output_UTF86class$E;
> 
> #ifdef STATIC_LIBGCJ_4_3
> extern int _ZGr32_java$Sutil$Siso4217$_properties;
> int *dummy6 = &_ZGr32_java$Sutil$Siso4217$_properties;
> 
> extern int _ZN3gnu3xml8aelfred29XmlParser6class$E;
> int *dummy7 = &_ZN3gnu3xml8aelfred29XmlParser6class$E;
> 
> #endif
> 
> 
> Note that either fewer or more classes may be needed by your application.
> 

Thanks,

Daniel

-- 
Daniel Andrzejewski
student IT Administrator
Elec Engr & Comp Science
University of Tennessee
(865) 974 - 4388 (work)

"Investment in knowledge always pays the best interest" Benjamin Franklin
--

Re: static linking

[David Daney]

> 
> /scratch/daniel> gdb HelloWorld
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> ...
> 
> (gdb) break 12
> Breakpoint 1 at 0x400324: file /tmp/cc0TNqNE.i, line 12.
> (gdb) run
> Starting program: /scratch/daniel/HelloWorld
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000000 in ?? ()

Make sure you compile with -g and get a backtrace using gdb's bt command.

David Daney

Re: static linking

[David Daney]

Please keep java@gcc.gnu.org CCed so others can benefit from your discoveries as well...

Daniel Andrzejewski wrote:
> David Daney wrote:
>>>
>>> /scratch/daniel> gdb HelloWorld
>>> GNU gdb 6.3
>>> Copyright 2004 Free Software Foundation, Inc.
>>> ...
>>>
>>> (gdb) break 12
>>> Breakpoint 1 at 0x400324: file /tmp/cc0TNqNE.i, line 12.
>>> (gdb) run
>>> Starting program: /scratch/daniel/HelloWorld
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0000000000000000 in ?? ()
>>
>> Make sure you compile with -g and get a backtrace using gdb's bt command.
>>
>> David Daney
> 
> I compiled with -ggdb. I think it's the same, isn't it.
> 
> To be honest, it worked on the compute nodes :)
> 
> daniel@kraken /lustre/scratch/daniel> aprun -n 4 -N 1 ./HelloWorld
> Hello World!
> Hello World!
> Hello World!
> Hello World!
> Application 159447 resources: utime 5, stime 1
> 
> Thanks for your time,
> 

I am surprised.  -g should not change the runtime behavior of the code.

David Daney

Re: static linking

[Andrew Haley]

Daniel Andrzejewski wrote:
> David Daney wrote:
>> Daniel Andrzejewski wrote:
>>> Hi all,
>>>
>>> I have a problem with gcj. I have read couple threads here, but I
>>> still have no idea how to fix my problem. Usually people say that
>>> this is hard but doable, but they don't give much directions.
>>>
>>
>> Also I assume you have seen this:
>>
>> http://gcc.gnu.org/wiki/Statically_linking_libgcj
> 
> Yes, I have seen it and tried, but it gave some errors that it didn't
> understand couple of those flags, e.g. --as-needed and --no-as-needed.

We need more information.

Please copy what you typed, what gcc and ld versions, *all* of the output,
etc, etc.

We will not understand "it gave some errors".  We need the output.

Andrew.

Re: static linking

[Bryce McKinlay]

Tom Tromey wrote:

> I tried it but I'm seeing an odd regression.  I get a segv in the utf8
> comparison function.  I know I've seen this before but I don't recall
> what it means and I don't want to track it down right now.

IIRC, this used to be what happened on Solaris due to the old
libtool/linker bug. It indicated that C++ static initializers had not been
run. Maybe you're seeing it for different reasons though.

regards

  [ bryce ]

Re: static linking

[Tom Tromey]

>>>>> "Jeff" == Jeff Sturm <jeff.sturm@appnet.com> writes:

Jeff> At least the following four classes should always be present,
Jeff> and are not referenced explicitly:
Jeff> [ ... ]

Thanks.  Could you try this patch?
I tried it but I'm seeing an odd regression.  I get a segv in the utf8
comparison function.  I know I've seen this before but I don't recall
what it means and I don't want to track it down right now.

It seemed to make sense to put this stuff in FirstThread since that
class is already used for bootstrapping.

2000-12-08  Tom Tromey  <tromey@redhat.com>

	* gnu/gcj/runtime/FirstThread.java (Kcert, Kfile, Khttp, Kjar):
	New static final fields.

Tom

Index: gnu/gcj/runtime/FirstThread.java
===================================================================
RCS file: /cvs/java/libgcj/libjava/gnu/gcj/runtime/FirstThread.java,v
retrieving revision 1.5
diff -u -r1.5 FirstThread.java
--- FirstThread.java	2000/08/26 19:25:13	1.5
+++ FirstThread.java	2000/12/10 02:27:53
@@ -1,6 +1,6 @@
 // FirstThread.java - Implementation of very first thread.
 
-/* Copyright (C) 1998, 1999  Free Software Foundation
+/* Copyright (C) 1998, 1999, 2000  Free Software Foundation
 
    This file is part of libgcj.
 
@@ -74,4 +74,13 @@
   private Class klass;
   private String klass_name;
   private Object args;
+
+  // If the user links statically then we need to ensure that these
+  // classes are linked in.  Otherwise bootstrapping fails.  These
+  // classes are only referred to via Class.forName(), so we add an
+  // explicit mention of them here.
+  static final Class Kcert = java.security.cert.Certificate.class;
+  static final Class Kfile = gnu.gcj.protocol.file.Handler.class;
+  static final Class Khttp = gnu.gcj.protocol.http.Handler.class;
+  static final Class Kjar  = gnu.gcj.protocol.jar.Handler.class;
 }

Re: static linking

[Jeff Sturm]

Tom Tromey wrote:
> One more idea is that we could identify the classes needed for proper
> bootstrapping and ensure that those are always linked in, for instance
> by referencing them from prims.cc.  Jeff, do you have this list?  I
> don't have time this week to look at this, but if you had the list
> handy I could make a patch.

At least the following four classes should always be present, and are
not referenced explicitly:

java.security.cert.Certificate
gnu.gcj.protocol.file.Handler
gnu.gcj.protocol.http.Handler
gnu.gcj.protocol.jar.Handler

There may be others but this is sufficient for simple programs at
least.  The file and jar handlers are needed for VMClassLoader to
initialize.  (We may be able to omit http, but it does no harm.)

Jeff

Re: static linking

[Alexandre Oliva]

On Dec  6, 2000, Tom Tromey <tromey@redhat.com> wrote:

Alexandre> That's because libtool only extracts convenience libraries,
Alexandre> which -lsupc++ isn't; -lsupc++convenience is, but it's not
Alexandre> (and shouldn't be) installed.

> But we could solve this in the unified tree by linking against that,
> right?

As long as libgcj starts requiring the unified tree, yes.

> Or should we just add -lsupc++ to libgcj.spec?

That would be better, but libtool might start complaining about it on
platforms in which a static library can't always be linked into a
shared library.  This would only affect the creation of shared
libraries with libtool, of course.  So it seems like a reasonable
trade off.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: static linking

[Tom Tromey]

Alexandre> That's because libtool only extracts convenience libraries,
Alexandre> which -lsupc++ isn't; -lsupc++convenience is, but it's not
Alexandre> (and shouldn't be) installed.

But we could solve this in the unified tree by linking against that,
right?

Or should we just add -lsupc++ to libgcj.spec?

Tom

Re: static linking

[Alexandre Oliva]

On Dec  6, 2000, Tom Tromey <tromey@redhat.com> wrote:

>>> gcj shouldn't need to do anything special to get the supc++ stuff,
>>> it should all be put into libgcj.a, the same way it gets built into
>>> libstdc++.

Alexandre> Methinks explicitly linking libstdc++ in should be enough.

> We don't want to do this.  Java programs don't need all of libstdc++.

For static linking, they'll get only as much as they need.  But for
shared linking, it can indeed make a significant difference.

>>> The best solution, I think, would be to make a compiler option that
>>> allows you to do this more easily. eg
>>> "--link=gnu.gcj.protocol.jar.Handler,gnu.gcj.protocol.http.Handler"
>>> or something.

Alexandre> Good idea.

> I agree.  Like Jeff says, we could do this by further hacking
> jvgenmain.

Yep.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: static linking

[Tom Tromey]

>> gcj shouldn't need to do anything special to get the supc++ stuff,
>> it should all be put into libgcj.a, the same way it gets built into
>> libstdc++.

Alexandre> Methinks explicitly linking libstdc++ in should be enough.

We don't want to do this.  Java programs don't need all of libstdc++.

>> The best solution, I think, would be to make a compiler option that
>> allows you to do this more easily. eg
>> "--link=gnu.gcj.protocol.jar.Handler,gnu.gcj.protocol.http.Handler"
>> or something.

Alexandre> Good idea.

I agree.  Like Jeff says, we could do this by further hacking
jvgenmain.

One more idea is that we could identify the classes needed for proper
bootstrapping and ensure that those are always linked in, for instance
by referencing them from prims.cc.  Jeff, do you have this list?  I
don't have time this week to look at this, but if you had the list
handy I could make a patch.

Otherwise, could someone submit a PR for this stuff so it doesn't get
dropped?

Tom

Re: static linking

[Alexandre Oliva]

On Dec  6, 2000, Jeff Sturm <jeff.sturm@appnet.com> wrote:

> Now that's odd.  I see the -lsupc++ flag all right, but libtool doesn't
> try to extract it:

That's because libtool only extracts convenience libraries, which
-lsupc++ isn't; -lsupc++convenience is, but it's not (and shouldn't
be) installed.

This is one of the cases in which you have to use libtool to link the
final executable, or explicitly list all dependencies of any libtool
libraries you link with.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: static linking

[Jeff Sturm]

Anthony Green wrote:
> Jeff wrote:
> > 2) classes loaded dynamically (via Class.forName) don't get linked
> >
> > I don't see any good solution.  I got around it by linking the following
> dummy
> > class into my executable, but YMMV:
> 
> Hmm.. won't the class loader rummage around in appropriately named shared
> libraries?  What happens when you make a symlink from libgcj.so to gnu-gcj.so?

Interesting.  It might have worked, had gnu-gcj.so been available, but I
suspect there's a bootstrap problem also because VMClassLoader needs the
URL handlers during initialization.

The exact failure was inifite recursion in VMClassLoader.init until
stack was exhausted.  Explicitly linking gcj.protocol.file.Handler
solved it.

Jeff

Re: static linking

[Jeff Sturm]

Bryce McKinlay wrote:
> Hmm. Works for me. libtool should figure it out based on the -lsupc++ flag that is
> passed to it:

Now that's odd.  I see the -lsupc++ flag all right, but libtool doesn't
try to extract it:

/bin/sh ./libtool --mode=link gcc -L/opt/gcj/lib
-L/home/jsturm/Cygnus/libgcj/build-i386-linux/i686-pc-linux-gnu/libjava
-g -O2 -ffloat-store  -o libgcj.la -rpath /opt/gcj/lib -lsupc++ -rpath
/opt/gcj/lib -version-info `grep -v '^#'
../../../libjava/libtool-version` prims.lo posix.lo jni.lo exception.lo
resolve.lo defi
...

rm -fr  .libs/libgcj.a .libs/libgcj.la .libs/libgcj.lai
rm -fr .libs/libgcj.lax
mkdir .libs/libgcj.lax
rm -fr .libs/libgcj.lax/libltdlc.a
mkdir .libs/libgcj.lax/libltdlc.a
(cd .libs/libgcj.lax/libltdlc.a && ar x
/home/jsturm/Cygnus/libgcj/build-i386-linux/i686-pc-linux-gnu/libjava/./libltdl/.libs/libltdlc.a)
ar cru .libs/libgcj.a  prims.o posix.o jni.o exception.o resolve.o
defineclass.o interpret.o name-finder.o
gnu/gcj/convert/JIS0208_to_Unicode.o
gnu/gcj/convert/JIS0212_to_Unicode.o gnu/gcj/convert/Unicode_to_JIS.o
gnu/gcj/convert/natIconv.o gnu/gcj/convert/natInput_EUCJIS.o
gnu/gcj/convert/natInput_SJIS.o gnu/gcj/convert/natOutput_EUCJIS.o
gnu/gcj/convert/natOutput_SJIS.o gnu/gcj/io/natSimpleSHSSt

Jeff

RE: static linking

[Anthony Green]

Bryce wrote:
> Hmm. Works for me. libtool should figure it out based on the -lsupc++ flag
> that is passed to it:

FWIW, the last time I tried this I got the same results as Jeff.  I didn't 
report it as it seemed like people were still shaking out bugs from libstdc++ 
and libsupc++, but perhaps this is a real problem.

Jeff wrote:
> 2) classes loaded dynamically (via Class.forName) don't get linked
>
> I don't see any good solution.  I got around it by linking the following 
dummy
> class into my executable, but YMMV:

Hmm.. won't the class loader rummage around in appropriately named shared 
libraries?  What happens when you make a symlink from libgcj.so to gnu-gcj.so?

AG

Re: static linking

[Bryce McKinlay]

Jeff Sturm wrote:

> Bryce McKinlay wrote:
> > gcj shouldn't need to do anything special to get the supc++ stuff, it should all
> > be put into libgcj.a, the same way it gets built into libstdc++. libtool seems to
> > do this automatically for me. Does it not work for you?
>
> No.  I get undefined references to std::terminate, etc.

Hmm. Works for me. libtool should figure it out based on the -lsupc++ flag that is
passed to it:

/bin/sh ./libtool --mode=link gcc -L/home/bryce/cvs/libgcj/build/i686-pc-linux-g
nu/libjava -g   -ffloat-store  -o libgcj.la -rpath /home/bryce/gcc/lib -lsupc++
-rpath /home/bryce/gcc/lib -version-info `grep -v '^#' ../../../libjava/libtool-
version` prims.lo posix.lo jni.lo exception.lo resolve.lo defineclass.lo interpr
et.lo name-finder.lo gnu/gcj/convert/JIS0208_to_Unicode.lo
[,....]

runs:
rm -fr .libs/libgcj.lax/libsupc++.a
mkdir .libs/libgcj.lax/libsupc++.a
(cd .libs/libgcj.lax/libsupc++.a && ar x /home/bryce/gcc/lib/libsupc++.a)
ar cru .libs/libgcj.a  prims.o posix.o jni.o exception.o resolve.o defineclass.o
 interpret.o name-finder.o gnu/gcj/convert/JIS0208_to_Unicode.o gnu/gcj/convert/
JIS0212_to_Unicode.o gnu/gcj/convert/Unicode_to_JIS.o
[...]
/types.o ../libffi/raw_api.o ../libffi/java_raw_api.o ../libffi/ffi.o ../libffi/
sysv.o .libs/libgcj.lax/libltdlc.a/ltdl.o  .libs/libgcj.lax/libsupc++.a/del_op.o
 .libs/libgcj.lax/libsupc++.a/del_opnt.o .libs/libgcj.lax/libsupc++.a/del_opv.o
.libs/libgcj.lax/libsupc++.a/del_opvnt.o .libs/libgcj.lax/libsupc++.a/exception_
support.o .libs/libgcj.lax/libsupc++.a/new_handler.o .libs/libgcj.lax/libsupc++.
a/new_op.o .libs/libgcj.lax/libsupc++.a/new_opnt.o .libs/libgcj.lax/libsupc++.a/
new_opv.o .libs/libgcj.lax/libsupc++.a/new_opvnt.o .libs/libgcj.lax/libsupc++.a/
pure.o .libs/libgcj.lax/libsupc++.a/tinfo.o .libs/libgcj.lax/libsupc++.a/tinfo2.
o .libs/libgcj.lax/libsupc++.a/vec.o

regards

  [ bryce ]

Re: static linking

[Alexandre Oliva]

On Dec  5, 2000, Bryce McKinlay <bryce@albatross.co.nz> wrote:

> gcj shouldn't need to do anything special to get the supc++ stuff,
> it should all be put into libgcj.a, the same way it gets built into
> libstdc++.

Methinks explicitly linking libstdc++ in should be enough.

> The best solution, I think, would be to make a compiler option that allows you to
> do this more easily. eg
> "--link=gnu.gcj.protocol.jar.Handler,gnu.gcj.protocol.http.Handler" or something.

Good idea.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: static linking

[Jeff Sturm]

Bryce McKinlay wrote:
> gcj shouldn't need to do anything special to get the supc++ stuff, it should all
> be put into libgcj.a, the same way it gets built into libstdc++. libtool seems to
> do this automatically for me. Does it not work for you?

No.  I get undefined references to std::terminate, etc.

> There's a linker flag which will force it to link in certain classes. Its a bit
> ugly because you have to pass the mangled classname. Try something like
> -Wl,-u,_Q53gnu3gcj8protocol3jar7Handler.class$ (untested).

That gets ugly quick if there are many such classes.  I didn't mean to
suggest there are only four; that was just enough to make my app work.

The Dummy class is a convenient (albeit gross) workaround that somebody
might find useful until static linking gets fixed in libgcj.  I don't
think the current situation is satisfactory.  One consideration is
platforms (i.e. win32) on which a shared libgcj isn't currently an
option.

> The best solution, I think, would be to make a compiler option that allows you to
> do this more easily. eg
> "--link=gnu.gcj.protocol.jar.Handler,gnu.gcj.protocol.http.Handler" or something.

One way to accomplish that could be to pass the --link option to
jvgenmain and let it mangle the class, just as it does now for the main
class.

Jeff

Re: static linking

[Bryce McKinlay]

Jeff Sturm wrote:

> 1) libsupc++ doesn't get linked by gcj
>
> This seems like an oversight.  Since libgcj.so is linked against libsupc++,
> normal (shared) linking just happens to work.  I "fixed" it by adding supc++ to
> libgcj.spec.  I'll see if I can cobble together a patch.

gcj shouldn't need to do anything special to get the supc++ stuff, it should all
be put into libgcj.a, the same way it gets built into libstdc++. libtool seems to
do this automatically for me. Does it not work for you?

> 2) classes loaded dynamically (via Class.forName) don't get linked
>
> I don't see any good solution.  I got around it by linking the following dummy
> class into my executable, but YMMV:
>
> class Dummy {
>         java.security.cert.Certificate dummy1;
>         gnu.gcj.protocol.file.Handler dummy2;
>         gnu.gcj.protocol.http.Handler dummy3;
>         gnu.gcj.protocol.jar.Handler dummy4;
> }

There's a linker flag which will force it to link in certain classes. Its a bit
ugly because you have to pass the mangled classname. Try something like
-Wl,-u,_Q53gnu3gcj8protocol3jar7Handler.class$ (untested).

The best solution, I think, would be to make a compiler option that allows you to
do this more easily. eg
"--link=gnu.gcj.protocol.jar.Handler,gnu.gcj.protocol.http.Handler" or something.

regards

  [ bryce ]

static linking

[Jeff Sturm]

I think it was Tom who said static linking might be broken now.  Turns out he's
right. :\

I see two problems:

1) libsupc++ doesn't get linked by gcj

This seems like an oversight.  Since libgcj.so is linked against libsupc++,
normal (shared) linking just happens to work.  I "fixed" it by adding supc++ to
libgcj.spec.  I'll see if I can cobble together a patch.

2) classes loaded dynamically (via Class.forName) don't get linked

I don't see any good solution.  I got around it by linking the following dummy
class into my executable, but YMMV:

class Dummy {
        java.security.cert.Certificate dummy1;
        gnu.gcj.protocol.file.Handler dummy2;
        gnu.gcj.protocol.http.Handler dummy3;
        gnu.gcj.protocol.jar.Handler dummy4;
}

BTW I haven't noticed any ICEs yet with today's compiler.  Nice work!

--
Jeff Sturm
jeff.sturm@commerceone.com