compiling Open Transactions on 64 bit Linux
BlueMeanie
Anyone else compiling OT on Linux 64bit? I ran into some problems
once before, but successfully compiled it. I would like to streamline
the process this time. Most of the issues were related to FPIC and
emerged when compiling the Java API.
Thanks and congrats to Fellow Traveler for recent accomplishments and
media appearances!
-BM
BlueMeanie
another issue is the JDK location. For instance, one of the compilation commands is:
g++ -I/usr/local/ssl/include -I/usr/lib64/jvm/java-6-openjdk/include -I../xmlrpcpp/src -I../OTLib/irrxml -I../OTLib -I./SSL-Example -I. -fPIC -DOT_XMLRPC_MODE -c -o OpenTransactions.o OpenTransactions.cpp
which uses the -I/usr/lib64/jvm/java-6-openjdk/include for JDK files ( such as jni.h ). This is the wrong JDK.
where is the right place to set the JDK location in the Makefile?
danke! -bm
Dominic Pearson
I have not experimented with Open-Transactions in a few months
unfortunately, for various reasons. I too hit similar issues to you.
For the OpenJDK path:
elsku% find . -type f -exec grep -H openjdk '{}' \;
./testwallet/Makefile.API:JAVA_INCLUDEDIRS = -I/usr/$(LINUX_LIBDIR)/
jvm/java-6-openjdk/include
As for the 64-bit compilation, one could modify the Makefile to make
sure the correct arguments are passed. I can't remember what I did
when I was doing it. From a quick look, it seems that DYNAMIC_FLAG in
the toplevel Makefile might be what you want.
HTH,
dsp
On Apr 27, 1:00 pm, BlueMeanie <josh.josh...@googlemail.com> wrote:
> another issue is the JDK location. For instance, one of the
> compilation commands is:
>
> g++ -I/usr/local/ssl/include -I/usr/lib64/jvm/java-6-openjdk/include
> -I../xmlrpcpp/src -I../OTLib/irrxml -I../OTLib -I./SSL-Example -I.
> -fPIC -DOT_XMLRPC_MODE -c -o OpenTransactions.o OpenTransactions.cpp
>
BlueMeanie
thanks Dominic,
the path should be based on $JDK_HOME , no?
I played around with the fPIC flag for close to 2 days.
Unfortunately, I couldn't find a simple place to add it that seems to
work in a consistent way.
-bm
Dominic Pearson
elsku% env|grep -i java
elsku% env|grep -i jdk
elsku% env|grep -i jre
Things like this are highly distribution-specific I suspect. There is
a reason so many people use autoconf and other similar build systems.
It isn't such an easy fix.
There may well be a way to automatically determine the JDK path, but I
suspect it isn't portable.
- dsp
BlueMeanie
> Things like this are highly distribution-specific I suspect. There is
> a reason so many people use autoconf and other similar build systems.
> It isn't such an easy fix.
>
> There may well be a way to automatically determine the JDK path, but I
> suspect it isn't portable.
>
> - dsp
JDK_HOME and JRE_HOME are Java standards in my understanding... -BM
BlueMeanie
Another issue :
/usr/lib/jvm/java-6-sun-1.6.0.24/include/jni.h:27: fatal error:
jni_md.h: No such file or directory
requires a change in the include path for $JDK_HOME/include/linux
not sure what the structure looks like on Mac/Windows.
just writing this down here so that someone has some reference if they
attempt something similar.
-bm
BlueMeanie
>
> sure the correct arguments are passed. I can't remember what I did
> when I was doing it. From a quick look, it seems that DYNAMIC_FLAG in
> the toplevel Makefile might be what you want.
>
> HTH,
> dsp
Tried setting DYNAMIC_FLAG = -fPIC
Doesn't work. I got this to compile a few weeks ago and I couldn't
find a consistent way to include a new flag in every compilation
statement. Perhaps Fellow Traveler can advise.
the compile error:
/usr/bin/ld: ../xmlrpcpp//libXmlRpc.a(XmlRpcClient.o): relocation
R_X86_64_32 against `.rodata.str1.8' can not be used when making a
shared object; recompile with -fPIC
../xmlrpcpp//libXmlRpc.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
-BM
Dominic Pearson
DYNAMIC_FLAG = DYNAMIC_OTLIB=1
and in OTLib directory, the Makefile has:
ifeq ($(DYNAMIC_OTLIB), 1)
CXXFLAGS = $(INCLUDEDIRS) $(FT_FLAGS) -Wall -fPIC
CFLAGS = $(INCLUDEDIRS) $(FT_FLAGS) -Wall -fPIC
...
so it looks like it adds -fPIC there for that platform already. That
is what I meant.
If it is required elsewhere then that is probably not too useful.
Also, regarding the java environment variables, it might well be a
standard but it isn't set by default on my system. I am not too big on
java stuff though, so perhaps it is accessible from within java itself
rather than as a shell environment variable. I don't know. Regardless,
out of the box, that is not set on Debian.
- dsp
Fellow Traveler
See this:
https://github.com/FellowTraveler/Moneychanger/wiki/Troubleshooting
OT automatically detects 64bit and builds that way.
The problem is OpenSSL. Even on 64 bit systems, OpenSSL still builds in
32 bit, thus causing link errors with 64 bit OT.
I think solution is to use ./configure on openssl and build it properly
for 64 bit. Then it will link fine with OT.
BlueMeanie
> From the Makefile, when you compile on platform 'linux' it sets
>
> DYNAMIC_FLAG = DYNAMIC_OTLIB=1
>
> and in OTLib directory, the Makefile has:
>
> ifeq ($(DYNAMIC_OTLIB), 1)
> CXXFLAGS = $(INCLUDEDIRS) $(FT_FLAGS) -Wall -fPIC
> CFLAGS = $(INCLUDEDIRS) $(FT_FLAGS) -Wall -fPIC
> ...
>
> so it looks like it adds -fPIC there for that platform already. That
> is what I meant.
I haven't really determined what files need -fPIC and which ones
don't. There are innumerable combinations so I don't think the
experimental approach will be too effective here.
> If it is required elsewhere then that is probably not too useful.
>
> Also, regarding the java environment variables, it might well be a
> standard but it isn't set by default on my system. I am not too big on
> java stuff though, so perhaps it is accessible from within java itself
> rather than as a shell environment variable. I don't know. Regardless,
> out of the box, that is not set on Debian.
>
I'm on Ubuntu and it is very similar. Did you install the Sun Linux JDK?
-bm
BlueMeanie
I did recompile openssl the first time I went through this process with
the "-fPIC shared" flags.
-bm
Fellow Traveler
>
> I did recompile openssl the first time I went through this process with
> the "-fPIC shared" flags.
>
> -bm
I could be wrong but...
-fPIC has nothing to do with it.
fPIC is about compiling to account for dynamic libraries.
OT will use fPIC automatically already if it needs to build something in
dynamic mode.
------
What we are talking about here is 64 bit mode. If you are on a 64 bit
machine, OpenSSL will still build in 32 bit mode. You have to EXPLICITLY
configure OpenSSL for 64 bit before you build it.
(and fPIC is not what does that.) The configure script that comes with
openssl has the option I am talking about.
-FT
BlueMeanie
>> I did recompile openssl the first time I went through this process with
>> the "-fPIC shared" flags.
>>
>> -bm
> I could be wrong but...
>
> -fPIC has nothing to do with it.
>
> fPIC is about compiling to account for dynamic libraries.
>
> OT will use fPIC automatically already if it needs to build something in
> dynamic mode.
>
>
> ------
>
>
> What we are talking about here is 64 bit mode. If you are on a 64 bit
> machine, OpenSSL will still build in 32 bit mode. You have to EXPLICITLY
> configure OpenSSL for 64 bit before you build it.
I could not find any simple instructions for doing this. As far as I
can tell it's not a simple config switch.
could you give me a link with instructions for compiling in 64bit?
-bm
Fellow Traveler
How To Build OpenSSL For 64-Bit Linux, So That It Will Link Properly
When Building Open-Transactions:
1) cd openssl
2) ./Configure YOUR_PLATFORM_GOES_HERE
For YOUR_PLATFORM_GOES_HERE, use the correct choice from this list:
linux-alpha+bwx-ccc
linux-alpha+bwx-gcc linux-alpha-ccc linux-alpha-gcc linux-aout linux-armv4
linux-elf linux-generic32 linux-generic64 linux-ia32-icc linux-ia64
linux-ia64-ecc linux-ia64-icc linux-ppc linux-ppc64 linux-s390x
linux-sparcv8
linux-sparcv9 linux-x86_64 linux64-sparcv9
3) THEN BUILD OPENSSL. (Probably just type 'make').
FYI, Open-Transactions *definitely* detects 64 bit and builds that way,
but unfortunately, OpenSSL does not. You must explicitly build OpenSSL
for 64 bit, if you run a 64-bit machine, or you WILL DEFINITELY have
linker problems trying to build OT.
-FT
BlueMeanie
I rebuilt openssl with the linux-generic64 Configuration, and then
cleaned and built both 'rpc' and 'java' make targets.
the 'java' target gives me the same exact link error.
/usr/bin/ld: ../xmlrpcpp//libXmlRpc.a(XmlRpcClient.o): relocation
R_X86_64_32 against `.rodata.str1.8' can not be used when making a
shared object; recompile with -fPIC
../xmlrpcpp//libXmlRpc.a: could not read symbols: Bad value
mind you that I DID get it to work prior by making sure everything was
compiled with -fPIC.
-bm
Fellow Traveler
>
> I rebuilt openssl with the linux-generic64 Configuration, and then
> cleaned and built both 'rpc' and 'java' make targets.
>
> the 'java' target gives me the same exact link error.
>
> /usr/bin/ld: ../xmlrpcpp//libXmlRpc.a(XmlRpcClient.o): relocation
> R_X86_64_32 against `.rodata.str1.8' can not be used when making a
> shared object; recompile with -fPIC
> ../xmlrpcpp//libXmlRpc.a: could not read symbols: Bad value
>
> mind you that I DID get it to work prior by making sure everything was
> compiled with -fPIC.
>
> -bm
>
>
I just did some investigation in the Makefile....
Check out the difference between the RPC target and the Java target:
rpc:
cd xmlrpcpp && $(OT_MAKE)
java:
cd xmlrpcpp && $(OT_MAKE) $(DYNAMIC_FLAG)
As you can see, if you didn't "clean" between builds, then some of the
resulting binaries are dynamic, and some are not. (xmlrpcpp for example.)
THEREFORE: My guess is that it worked correctly when you did "make
rpc", but then you did NOT do a "make clean" before trying "make java".
As a result of that, the XmlRpc files were still built in rpc
(non-dynamic) mode, and thus they were unable to link to the other files
that were built in java (dynamic) mode.
This is why you see the error on the XmlRpc file.
TO FIX, TRY THIS:
cd Open-Transactions && make clean && make java
And tell me if it works, please.
-FT