This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: static linking
- From: Daniel Andrzejewski <andrzeje at cs dot utk dot edu>
- To: David Daney <ddaney at avtrex dot com>
- Cc: java at gcc dot gnu dot org
- Date: Fri, 15 Aug 2008 14:22:11 -0400
- Subject: Re: static linking
- References: <48A48047.4030005@cs.utk.edu> <48A48BA1.30005@avtrex.com>
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
--