Installation on Debian testing (etch)
Brought to you by:
aeby
Menu
▾
▴
#5 Installation on Debian testing (etch)
Hi Tom!
I am about to compile and install the Node Director on the amd64 architecture, using Debian testing (etch). The problem occurs as well on the ordinary i386 architecture of Debian testing as well; i.e., it seems to be a general problem.
The environment is:
gcc: 4.1.2
Java: sun-java5-jdk, 1.5.0-08
gcj: 4.1.1
Though there is java version 1.5. installed, the Node Director needs to be compiled with 1.4, i.e., the option "-source 1.4" has to be added to the javac command.
The problem is:
After some javac and gcc compiling, while executing the line
$(CC) $(LINK_FLAGS) -static-libgcc -o $@ build/libs/$(SYSID)/native_main.o build/libs/$(SYSID)/daemon.o $(OBJFILES) $(GCJOBJS) build/libs/$(SYSID)/*.a -Wl,-whole-ar
chive,-Bstatic $(statlibs) -Wl,-no-whole-archive -lgcj -Wl,-Bdynamic -lpthread -ldl
of the Makefile the make stops with the error message:
/usr/bin/ld: cannot find -lgcj
The research in the internet points to a gcc and gcj problem and often patches are added. But since you offer Debian packages for the i386 architecture, you hardly had to go that far, I assume. May I ask you about your environment for the build of your offered Debian packages? There might be something missing which is not checked by the configure script?
Thanks!
Stefan
Logged In: YES
user_id=77961
Originator: NO
Hi Stefan,
I have tested the build procedure up to gcc 4.1.1, but actually I am using a patched 4.0.1 for the official builds since static linking is broken in 4.1. Potentially, the latter problem implies that the official GCC/GCJ packages for etch come without libgcj.a (which is required for static builds ...). Can you please check if your GCJ includes libgcj.a?
Anyway, since static building is broken for 4.1.1, anyway, try building the Director with the configure option "--disable-static". The drawback of this is that you will need all the shared libraries installed on all the systems you will be running the binary built this way.
BTW: Just curious: does the static binary as distributed in the official version not work on amd64?
Regards,
Tom
Logged In: YES
user_id=1372411
Originator: YES
Thanks for the answer!
The package gcj does not include any libgcj.a. According to http://www.debian.org/distrib/packages#search_contents there is no package in Debian etch, neither for amd64 nor i386.
With the configure option "--disable-static" the make passes the place of the described error, but now it stops at
build/libs/Linux-x86_64/native_main.o: In function `main':
native_main.c:(.text+0x1d4): undefined reference to `JNI_GetDefaultJavaVMInitArgs'
native_main.c:(.text+0x1ec): undefined reference to `JNI_CreateJavaVM'
collect2: ld returned 1 exit status
I haven't thought yet at installing the i386 packages, but, yes, why should it not work?! I did the following to install the relevant packages for i386 on the amd64 architecture:
dpkg -i --force-architecture bigclerk_0.12-1_all.deb \
bigswaf_0.12-3_i386.deb \
sfidirector_4.2.1-2_i386.deb \
sfidirector-server_4.2.1-2_i386.deb \
sfidirector-init_4.2.1-2_i386.deb
They are properly installed, i.e., dpkg does not leave any error messages and "ps aux" shows some new processes. But I am not yet further with the installation procedure. (Next steps would be the LDAP configuration, according to the installation guide.) However, the Debian system, i.e., the apt systems mentions other problems: All newly installed packages are "i386"s but not bigclerk, which is "all". Bigclerk depends on bigswaf, but the apt system does not see the latter as being installed, since it is from another architecture. As a consequence, bigclerk is installed with broken dependencies and apt will remove it while doing an upgrade. (Or working with aptitude, it will be removed as soon as any action is taken.) No "hold" seems to prevent apt from undertaking this drastic step.
A bigclerk only for i386 will help, otherwise I will have to compile and install that one manually...
I will let you know more about the installation with the i386 packages. Thank you very much, anyway.
Regards
Stefan
Logged In: YES
user_id=77961
Originator: NO
Oh, my "slow-answer-problem", again :-)
> native_main.c:(.text+0x1d4): undefined reference to
> `JNI_GetDefaultJavaVMInitArgs'
I haven't got an instant solution for that. Most probably I'll try out building the Director on an out-of-the-box Debian/Etch system in order to see what happens.
Regarding the i386 packages: Did they actually work apart from the dependency problems? Maybe, rather than releasing an i386 bigclerk-Package (it's "all", because it is actually platform independent) I could build a fake amd64 package of the binaries ... not optimal, but, well, a workaround until the multiarch approach is finally going into Debian.
Regards,
Tom