Hi folks, I've got a test Java class with a single native method. The native method lives in a C++ shared library and is implemented with gcj's CNI. The lib compiles fine and a Linux shared object file is created. The java class compiles fine into an object file, but when linking the executable the linker complains about undefined references to a hidden alias: de/dbt/simplelibclient/SimpleCPPLib.o:(.data.rel+0xc): undefined reference to `hidden alias for de::dbt::simplelibclient::SimpleCPPLib::square(int)' de/dbt/simplelibclient/SimpleCPPLib.o:(.data.rel+0x68): undefined reference to `hidden alias for de::dbt::simplelibclient::SimpleCPPLib::square(int)' When linking directly to the object file - SimpleCPPLib.o - the library consists of and not the library - libSimpleCPPLib.so - itself, an executable is created without errors. (Don't be confused about SimpleCPPLib.o. There are two of them. The Java class compiles to a SimpleCPPLib.o and the C++ class implementing the native method also compiles to a SimpleCPPLib.o.) I put all relevant files into a tar archive "simplecpplib_sample.tar.bz2" attached to this mailing list mail (is it possible to attach a file to a bugzilla report?): http://sources.redhat.com/ml/binutils/2007-03/msg00321.html I can reproduce problem - on an Athlon-XP system running openSUSE 10.2 - on a Pentium-Core2-Duo system running openSUSE 10.2 - on an Athlon-XP system running Kubuntu 6.1 products used - gcc/gcj 4.1.2 (on all systems) - binutils 2.17 (on all systems) - glibc 2.5 (on all systems) - Linux kernel 2.6.18.8 (on openSUSE Athlon-XP system) I also reproduced the problem (on the openSUSE Athlon-XP system) with - gcc/gcj 4.1.2 built from the current release sources (with and without --enable-bootstrap configure option) - gcc/gcj 4.2.0 from the snapshot sources of 2007/03/07 - binutils 2.17 built from the current release sources I also tested different compiler optimizations when building gcc/gcj and binutils - -O2 -march=athlon-xp -mmmx -m3dnow -msse -mfpmath=sse - -O2 -m486 - -O2 which seems to have no effect Thanks in advance.
Created attachment 1643 [details] java/c++ source, object and lib files, output of build, output of "nm -C"
Subject: Re: New: hidden alias not found while linking gcj compiled Java class with native C++ lib and CNI binding under Linux x86 Hi Andreas, Well I can shed some light on how this problem is happening, although not necessarily why: > de/dbt/simplelibclient/SimpleCPPLib.o:(.data.rel+0x68): undefined reference to > `hidden alias for de::dbt::simplelibclient::SimpleCPPLib::square(int)' Looking at libSimpleCPPLib.so, where you would expect to find the definition of the alias shows: % nm -C SimpleCPPLib/Debug/libSimpleCPPLib.so | grep square 0000071c t hidden alias for de::dbt::simplelibclient::SimpleCPPLib::square(int) 0000071c T de::dbt::simplelibclient::SimpleCPPLib::square(int) The "t" is critical. It indicates that the hidden alias is local to the file and not visible outside the library. Hence you are getting the link-time error. Looking at the SimpleCPPLib.o file on its own, (ie not inside the library) shows: % nm -C SimpleCPPLib/Debug/SimpleCPPLib.o | grep square 00000000 T hidden alias for de::dbt::simplelibclient::SimpleCPPLib::square(int) 00000000 T de::dbt::simplelibclient::SimpleCPPLib::square(int) ie here the hidden alias is type "T", an exported text symbol. This explains why you can link directly against the SimpleCPPLib.o file and obtain a fully resolved executable. I am not an expert on java, but it seems to me that you should not be trying to reference the hidden alias at all, (after all it is hidden). Instead SimpleLibClient/de/dbt/simplelibclient/SimpleCPPLib.o ought to be referencing the unaliased symbol [de::dbt::simplelibclient::SimpleCPPLib::square(int)] which *is* exported from libSimpleCPPLib.so. So to me this implies that this is a java compiler (gcj) problem. If there is a good reason for referencing the hidden alias then the problem is either that you should not be linking against the libSimpleCPPLib.so library but instead linking against the object file, or that the transformation of SimpleCPPLib.o into libSimpleCPPLib.so should not be transforming the globally visible hidden alias into a local-only hidden alias. Cheers Nick
I just compiled gcc 4.0.4 from the release sources and used it on my example. With this gcc version the executable builds fine and runs as expected without complaining about undefined references to a hidden alias. So this may be a gcc problem of gcc > 4.0.4 rather than being a binutils problem. Kind regards, Andreas
Not a binutils bug