Having trouble with proprietary library and linux compat

T

Tyrael

hello everybody,

first things first: I'm relatively new to FreeBSD (install is just about 1 week old) but have some Linux experience so please excuse any failures in understanding.

I've developed a Java application that uses a proprietary library (SAP Java Connector if you want to know). The library itself is built for use with a x64 Linux system and consists of a jar and a libsapjco3.so .

Here are the details:

FreeBSD:
Code: 
 [root@localhost /server_bin]# uname -a
FreeBSD localhost.localdomain 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010     root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

Java:
Code: 
 [root@localhost /server_bin]# java -version
java version "1.6.0_03-p4"
Java(TM) SE Runtime Environment (build 1.6.0_03-p4-root_01_oct_2010_15_46-b00)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-p4-root_01_oct_2010_15_46-b00, mixed mode)

The problem:

I have added /compat/linux/lib to my LD_LIBRARY_PATH but when I want to launch my java application it stops with the following error:
Code: 
dl failure on line 705Error: failed /usr/local/jdk1.6.0/jre/lib/amd64/server/libjvm.so, because /compat/linux/lib/libgcc_s.so.1: unsupported file layout

Here are some file specifics, first the library and then the libs it depends on (as far as I can see):
Code: 
[root@localhost /server_bin]# file /server_bin/libsapjco3.so
/server_bin/libsapjco3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
[root@localhost /server_bin]# file /compat/linux/lib/libdl.so.2
/compat/linux/lib/libdl.so.2: symbolic link to `libdl-2.8.so'
[root@localhost /server_bin]# file /compat/linux/lib/libdl-2.8.so
/compat/linux/lib/libdl-2.8.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
[root@localhost /server_bin]# file /compat/linux/lib/libgcc_s.so.1
/compat/linux/lib/libgcc_s.so.1: symbolic link to `libgcc_s-4.3.0-20080428.so.1'
[root@localhost /server_bin]# file /compat/linux/lib/libgcc_s-4.3.0-20080428.so.1
/compat/linux/lib/libgcc_s-4.3.0-20080428.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

I have tried linux_base-f9 and linux_base-f10 ports as linux userland, they seem to be running fine (below is from f9)
Code: 
[root@localhost /server_bin]# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/da0s1a    445M    283M    126M    69%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/da0s1e    421M     14K    387M     0%    /tmp
/dev/da0s1f    6.6G    1.7G    4.3G    29%    /usr
/dev/da0s1d    815M     20M    729M     3%    /var
linprocfs      4.0K    4.0K      0B   100%    /usr/compat/linux/proc
server_data     31G     19G     12G    62%    /server_data
[root@localhost /server_bin]# kldstat
Id Refs Address            Size     Name
 1   20 0xffffffff80100000 d6aa98   kernel
 2    1 0xffffffff81022000 fd86d    zfs.ko
 3    1 0xffffffff81120000 19ba     opensolaris.ko
 4    1 0xffffffff81122000 3a28     linprocfs.ko
 5    1 0xffffffff81126000 1c4c4    linux.ko

My guess is that the linux userland libraries, which are 32Bit, don't work with x64 libraries? Can anyone please give me some pointers as I have run out of words to google ...
 
Thanks for your speedy reply SirDice.

Guess I'll have to design a different "show" to circumvent that showstopper ;)
 
I'm sure that library is also available in a 32 bit version.
 
Yes there is a 32 Bit version. Problem is I don't know if it will be able
to handle the amounts of data I'm confronted with.

That being said I am sure I can control that amount by re-designing my
application (be it query or code), which is what I meant by "designing a
different show".
 
Tyrael said:
Yes there is a 32 Bit version. Problem is I don't know if it will be able to handle the amounts of data I'm confronted with.
Click to expand...
That's completely irrelevant and has nothing to do with 32 vs 64 bit. The only reason to go for 64 bit is because it allows you to address more then 4GB of memory without having to resort to things like PAE.
 
SirDice said:
That's completely irrelevant and has nothing to do with 32 vs 64 bit. The only reason to go for 64 bit is because it allows you to address more then 4GB of memory without having to resort to things like PAE.
Click to expand...

You misinterpret what PAE does, and there are absolutely some circumstance where a 64 system can do things much easier than 32 bit system. Simply having a PAE enabled system doesn't mean your application can address more than the 4 GB limit. In fact nearly all programs are still limited by this and it takes special performance sapping tricks(on top of the performance hit by simply just having PAE enabled) to overcome the barrier. That in addition to all the crap that comes with PAE is the reason 64 OS's arose, contrary to your position.
 
Galactic_Dominator said:
Simply having a PAE enabled system doesn't mean your application can address more than the 4 GB limit.
Click to expand...
I never claimed that. I'm quite aware that the process space is still limited to 4GB. I'm also aware that applications need to be specifically written to make use of PAE.

That in addition to all the crap that comes with PAE is the reason 64 OS's arose, contrary to your position.
Click to expand...
You misunderstood my position.

My argument was that the amount of data is irrelevant. Both 32bit and 64bit can cope with large amounts. As long as they are written properly.
 
You must log in or register to reply here.
Back
Top