testwallet/API compiling csharp / python

[BlueWall]

I have been trying to build the csharp and python client api on OpenSUSE 11.3 and 11.4 . I have been running into a couple of things that prevent me from building it.

With the python api, I needed to add an include path -I/usr/include/python, which is odd because I have /usr/include/python2.6. and am running python 2.6.5. The build system is getting python2.5 somehow. After that, it starts building, but I get this: http://pastebin.com/1ejzz5Ar

Building csharp gives: http://pastebin.com/Xm3E44Ki

[FellowTraveler]

Hiya.

I just released a new version, v0.61 (it's in the "storage" branch), and I made some fixes based on your experience here.

Basically SWIG auto-generates wrappers for the different languages... Python, Java, Ruby, etc.

===> the Python header file was being improperly overwritten by the Java file.

===> Due to your comment, I have fixed the "buildwrappers" script in the testwallet folder, so that it properly generates and sets aside the wrapper for each language. Then I modified the Makefile in the Open-Transactions folder so that it would copy over the proper files at build time, based on the language you are building.

===> So that should clear up a big piece of it, please let me know how it goes.

===> You will probably still have to edit the Makefiles for the hardcoded Python path and libs. It only appears in a couple of places. To find them, type this from the Open-Transactions folder: fgrep -n -i python / It's there for various platforms.

I had some code that autogenerated it, but it wasn't working on some platforms, so I hardcoded whatever is there. Will be fixed as soon as we get a real ./Configure script.

Please give feedback so we can continue to improve the process.

Thank you.

[BlueWall]

It looks like it is all building but I get this at the linking stage --> http://pastebin.com/1Enw06Yq I get the same message when building the java API too. I did do: make DYNAMIC_OTLIB=1

Thanks

[FellowTraveler]

I think OT is definitely building in the proper -fPIC mode, but not necessarily in the proper 64-bit mode. (Solution below for all of these potential problems, we will have this fixed I think, after this comment. I'm closing this issue, but please re-open it if the problem persists after these fixes.)

It's also common that OpenSSL is built in 32-mode, or wasn't built with -fPIC. (A very common problem right now with OT on 64-bit systems, is how OPENSSL is built, not OT itself.) Other possible suspects in your case would be Python dev libs, csharp dev libs, MsgPack, and Protobuf. Possibly XmlRpc or BitInt as well. (i.e. everything else being linked in...)

===> The solution is to rebuild OpenSSL in 64-bit mode, (which is NOT the default for OpenSSL on 32-bit systems, unfortunately!!) ===> When rebuilding OpenSSL, we will also make sure that fPIC ("shared" mode) is turned on.

===> You also definitely want to use "make clean" between builds, since "make python" builds in fPIC mode and "make rpc" does NOT, so you don't want to mix the object files between those builds! Use "make clean" before every build.

===> You also definitely want to grab the latest code, since I added "csharp" as a top-level build option.

===> From now on, just go to the MAIN FOLDER (Open-Transactions) and type "make csharp" or "make python", and be sure to use "make clean" between builds. You can build everything from the top-level that way, and it will automatically set the DYNAMIC_FLAGS where necessary.

===> Please also send me the change you made to the Python directory (in the Makefiles) so I can add it to my records.

Here are the solutions to the fPIC and 64-bit issues, from the Troubleshooting page:

https://github.com/FellowTraveler/Moneychanger/wiki/Troubleshooting

I AM ON 64-BIT LINUX AND HAVING BUILD ISSUES...

Open Transactions does a pretty good job of detecting your system and building appropriately. In fact, Open-Transactions will even detect 64-bit linux and it switches the lib folders appropriately to match.

The problem is, OpenSSL itself, even on a 64-bit system, does not build as 64-bit by default -- it builds as 32-bit. Thus, when you try to build Open Transactions, there are resulting link errors, from OpenSSL. (From trying to mix 32-bit and 64-bit code.)

===> The solution is to ./configure OpenSSL for 64-bit, and then rebuild OpenSSL. OpenSSL comes with a "configure" script that you can run before building, and you have to specify the 64-bit status on the command line when you run that script.

===> After rebuilding OpenSSL, it will link properly with OT when you build OT.

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 shared no-threads

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 supposedly 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.

If the problems persist, then please do this next, since I don’t run Linux 64-bit at home: 1) Edit testwallet/Makefile.API 2) Find the line that says: FT_FLAGS = #empty 3) Change it to say: FT_FLAGS = -m64

Then go to the Open-Transactions folder, make clean, and make python. THEN EMAIL ME and tell me what happened! But do the OpenSSL fix first, so we have a definitive answer on this issue! And email me!

---

RECOMPILE WITH -fPIC ??

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

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.

[FellowTraveler]

Also remember, the latest stuff is in the "storage" branch, not the master branch.

[FellowTraveler]

I had a mistake in the above comment. (I edited/fixed it.) But it's important, so I wanted to make sure you try this:

If the problems persist, then please do this next, since I don’t run Linux 64-bit at home: 1) Edit testwallet/Makefile.API 2) Find the line that says: FT_FLAGS = #empty 3) Change it to say: FT_FLAGS = -m64

Then go to the Open-Transactions folder, make clean, and make python. THEN EMAIL ME and tell me what happened! (But do the OpenSSL fix first, so we have a definitive answer on this issue! And email me!)

[FellowTraveler]

Another quick note: I do believe that the OpenSSL fix is what will work, so I suggest you do that one first. The reason I say this, is because your error message indicates an fPIC issue, when clearly OT itself is building its own C++ files with the -fPIC flag.

The next culprit after this would be the msgpack and protobuf libs, making sure they are built in -fPIC and -m64 modes. (FYI.)

[BlueWall]

OpenSSL fix did it. So-far I have csharp and python + the testwallet.exe and transaction.exe. Now to start learning :)

Thanks