Has anyone ever built omniORB on RHEL? - c++

I am trying to build omniORB libraries on RHEL 5.5.
I tried running configure with
CC=gcc and CXX=g++ and PYTHON=bin/omnipython
I run into this problem where it complains about
gmake[3]: Entering directory `/home/local/NT/jayanthv/omniORB-4.1.4/src/lib/omniORB'
../../../bin/omniidl -bcxx -p../../../src/lib/omniORB -Wbdebug -Wba -p../../../src/lib/omniORB -Wbdebug -v -ComniORB4 ../../../idl/Naming.idl
omniidl: ERROR!
omniidl: Could not open IDL compiler module _omniidlmodule.so
omniidl: Please make sure it is in directory /home/local/NT/jayanthv/omniORB-4.1.4/lib
omniidl: (or set the PYTHONPATH environment variable)
omniidl: (The error was '/home/local/NT/jayanthv/omniORB-4.1.4/lib/_omniidlmodule.so: wrong ELF class: ELFCLASS64')
So, I tried to use the Intel C++ compiler instead, with
export CXX=/opt/intel/Compiler/11.1/080/bin/ia32/icc
export LD_LIBRARY_PATH=/opt/intel/Compiler/11.1/080/lib/ia32
export PYTHON=/home/local/NT/jayanthv/omniORB-4.1.4/bin/omnipython
But, now it complains about
../../../bin/omniidl -bcxx -p../../../src/lib/omniORB -Wbdebug -Wba -p../../../src/lib/omniORB -Wbdebug -v -ComniORB4 ../../../idl/Naming.idl
omniidl: ERROR!
omniidl: Could not open IDL compiler module _omniidlmodule.so
omniidl: Please make sure it is in directory /home/local/NT/jayanthv/omniORB-4.1.4/lib
omniidl: (or set the PYTHONPATH environment variable)
omniidl: (The error was '/home/local/NT/jayanthv/omniORB-4.1.4/lib/_omniidlmodule.so: undefined symbol: __cxa_pure_virtual')
The OS is RHEL 5.5 with x86_64 architecture, and I am trying to build the 32 bit binaries. Would appreciate any insight into this problem.

That's because omniidl is implemented as a Python extension module.
The Python executable you are using is a 64 bit executable, so it
can't load a 32 bit library.
Check this out http://objectmix.com/object/196129-compiling-omniorb-32bits-libraries-64bits-machine-suse.html

I finally found the magic combination to building omniORB on Linux using Intel compiler.
You see where it complains about '__cxa_pure_virtual' not found, this happens under gcc because it can't find a lib called libstdc++
So, make CC="icc -lstdc++" or CC="gcc -lstdc++" depending on which compiler you are using . Do the same for CXX (if using g++, specify it at g++)
And for Python, I used the omnipython which is a python1.5, PYTHON=bin/omnipython
which means it is looking relative to the omniORB root path.
You can see where it complains about 'wrong ELF class: ELFCLASS64', this is because you are trying to link a 32 bit binary using a 64 bit linker.
So, force your compiler and linker flags to 32.
CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
Once done, run your configure
./configure --prefix=/opt/omniInst --build=i686-pc-linux-gnu
Run gmake followed by gmake install, and you will see all the binaries and libs under omniInst or whichever prefix directory you suggested.

Related

NPM sqlite3 with sqlcipher support

I am trying to cross compile NPM Sqlite3 with sqlcipher support. I am using Ubuntu 16.04 to cross compile for linux armv7 based SOC(system on chip).
So I started with cross-compiling OpenSSL to build sqlcipher for arm. I successfully cross compiled sqlcipher to produce a static library (libsqlcipher.a).
Now I am trying to get the NodeJS side of the project. I need sqlite with sqlcipher support, compiled for arm. I am using SOC SDK to built till now.
I am using node v4.6.1 and npm v2.15.9 to cross compile. I made sure I have the same version installed on Ubuntu as the SOC.
The command I use to cross compile is as follows :
npm install sqlite3 --target_arch=arm --enable-static=yes --build-from-source --sqlite_libname=sqlcipher -fPIC --sqlite=home/onkar/Library/sqlcipher-master/.libs --verbose
I exported the location of the libsqlcipher.a to LDFLAGS. I get the following error when I try to cross compile. Can someone help me with this error?
/home/linuximage/sdk/sysroots/x86_64-angstromsdk-linux/usr/libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/5.2.1/real-ld: error: /home/Library/sqlcipher-master/.libs/libsqlcipher.a(sqlite3.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC
collect2: error: ld returned 1 exit status
node_sqlite3.target.mk:129: recipe for target 'Release/obj.target/node_sqlite3.node' failed
make: *** [Release/obj.target/node_sqlite3.node] Error 1
Please let me know if you require any additional information, I would be more than happy to provide you with the same.
Thanks,
Onkar
In the first instance, you should check if the -fPIC (position independent code) flag was correctly applied when the libsqlcipher.a file was originally created.
In your output above, it looks like the linker is using the file at:
/home/Library/sqlcipher-master/.libs/libsqlcipher.a
Run the command
objdump -r /home/Library/sqlcipher-master/.libs/libsqlcipher.a | more
... and check for a line close to the start of the output beginning with the text
RELOCATION RECORDS FOR
If you see this line, then the library doesn't contain position independent code.

How to use Cross Linker instead of native linker

I am trying to cross compile a package for MIPS architecture using toolchain provided by OpenWRT. I come across following error during make:
/usr/bin/ld: skipping incompatible /home/user/package/zlib/zlib-1.2.8/libz.so when searching for -lz
In this case zlib is already cross compiled for MIPS but make is using '/usr/bin/ld' instead of 'mipsel-openwrt-linux-ld'. I have tried ./configure with --with-ld option but it says that '--with-ld' is unknown option.
Did you check following page, https://wiki.openwrt.org/doc/devel/crosscompile?
Pass the host and build to the build system of the package to trigger cross-compile
For GNU configure, use --build=architecture-unkown-linux-gnu --host=architecture-openwrt-linux-uclibc (for example: ./configure --build=x86_64-unkown-linux-gnu –host=mips-openwrt-linux-uclibc)
Run ./config.guess to get the --build= option.
Check the output and ensure that 'checking whether we are cross compiling… yes' is yes.
For GNU make, override the CC and LD environment variables (usually not needed if GNU configure was used)
make CC=architecture-openwrt-linux-uclibc-gcc LD=architecture-openwrt-linux-uclibc-ld
I know that this two years old. I had the same issue when building foreign packages for OpenWrt.
As for the most recent OpenWrt, you have set at least two ENV variables:
add your Path_to_OpenWrt/staging_dir/toolchain-*/bin path to your PATH ENV var
set your Path_to_OpenWrt/staging_dir to your STAGING_DIR ENV var
You should now be able to compile an autoconf based project with AC_CANONICAL_HOST (look it up in the configure.ac) with ./configure --host=architecture-openwrt-linux.
You probably will need to set more ENV vars e.g. PKG_CONFIG_PATH, PKG_CONFIG_LIBDIR to make pkg-config work appropriately.
I have written a bash script which does all the work for you:
sdkenv.sh.
You can activate the script with source sdkenv.sh before configuring.

Building U-Boot is failing

I am trying to build u-boot
Toolchain:
http://web.archive.org/web/20130823131954/http://www.angstrom-distribution.org/toolchains/
U-boot: git.denx.de
I am following this site to build this u-boot
http://beagleboard.org/linux
It says to put cross compiler path before building.
export PATH=/usr/local/angstrom/arm/bin:$PATH
1) I can see angstrom folder in /usr/local. Also I think that we need the toolchain's actual place of binaries. Let suppose in /home/myhome/BBB/angtrom_x_y_z/usr/local/angstrom/arm/bin
So which path actually i should export?
2)I have tried to put both paths, but I am getting errors.
3)I have downloaded three toolchains
angstrom-2011.03-i686-linux-armv5te-linux-gnueabi-toolchain
angstrom-2011.03-x86_64-linux-armv7a-linux-gnueabi-toolchain-qte-4.6.3
angstrom-2011.03-i686-linux-armv7a-linux-gnueabi-toolchain-qte-4.6.3
1st gives errors as
CROSS_COMPILE=arm-angstrom-linux-gnueabi- make am335x_evm
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config.h
GEN include/autoconf.mk
arm-angstrom-linux-gnueabi-gcc: 0: No such file or directory
arm-angstrom-linux-gnueabi-gcc: unrecognized option '-G'
cc1: error: unrecognized command line option "-mabicalls"
make[1]: *** [include/autoconf.mk] Error 1
make: *** No rule to make target `am335x_evm'. Stop.
second one is I think for 64 bit processor, I have i386 one, so it also doesn't worked
Third one is corrupted.
Can anybody tell me how to compile it as the site says. Maybe the site is outdated but still if anybody can tell me a straightforward way how to do this.
It looks like Angstorm toolchian is too old to deal with recent U-Boot. I tried your procedure and get other errors. I'm not sure why you try to use that old toolchain and if you have to use it. But I quickly check Linaro toolchain gcc-linaro-arm-linux-gnueabihf-4.9-2014.07_linux, which I use for boards like Cubietruck and A20-OLinuXino-MICRO and it works fine.
git clone git://git.denx.de/u-boot.git
cd u-boot
export PATH=${PATH}:${PATH_TO_TOOLCHAIN}/gcc-linaro-arm-linux-gnueabihf-4.9-2014.07_linux/bin
CROSS_COMPILE=arm-linux-gnueabihf- make am335x_evm_defconfig
CROSS_COMPILE=arm-linux-gnueabihf- make -j$(nproc)

Compile c++ code in R does not work anymore

I start saying that i am a newbie in programming and then i am not sure i will be able to explain well my problem.
I had some c++ code i wrote, this code are loaded and used by some R functions.
To compile the code i used the following:
R CMD SHLIB MyCode.cpp
and i loaded the library in R with
dyn.load("MyCOde.so")
Sometimes i built also an R package and i was able to load it into R.
If i do all these stuff on a Mac with mountain lion everything work fine, but now that i switched to mavericks, i have some problems. The R CMD SHLIB MyCode.cpp command works but when i used dyn.load("MyCOde.so") i get the following text:
Errore in dyn.load(paste(dir_function, "MyCOde.so", sep = "")) :
unable to load shared object 'MyCOde.so':
dlopen(MyCOde.so, 6): Symbol not found: __ZNSt8ios_base4InitC1Ev
Referenced from: MyCOde.so
Expected in: flat namespace
in MyCOde.so
Moreover if i try to load the package in R, i get the following
ld: warning: directory not found for option '-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
ld: library not found for -lquadmath
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [MyCode.so] Error 1
Can someone helps me?
Based on the helpful website of:
thecoatlessprofessor
Type this into your terminal shell:
curl -O http://r.research.att.com/libs/gfortran-4.8.2-darwin13.tar.bz2
sudo tar fvxz gfortran-4.8.2-darwin13.tar.bz2 -C /
This will create what you need to resume compiling as before.
Since it starts to work I can publish the answer for such a cases.
When you change the compiler and standard libraries - please note that different libraries have different implementation and different standard support. Changing the basement of your system might require total rebuild of your system with the new C++ standard library.
Your libraries are not the exception. So if have the errors in your linker like this:
warning: directory not found for option
'-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
apply next algorithm:
Check whether the directory /usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2 still exists. I bet it is not.
Check if you still have the libstdc++ from the missed compiler? Usually if you upgrade the same compiler and the C++ standard library ABI does not change everything should continue to work. If the ABI changed or you switch standard C++ library and compiler - you face the massive system rebuild.
Recompile your library and apps with the new C++ standard library and compiler.

What toolchain do I need to cross-compile Clang for iOS

OK, so first of all I know that this can be compiled on iOS (armv7) because I read the documentation. However, I can't find the right toolchain.
So, now, what toolchains I've already tried:
i686-apple-darwin10-cpp-4.2.1
i686-apple-darwin10-g++-4.2.1
i686-apple-darwin10-gcc-4.2.1
The above cross-compiles to x86 (I'm on i386). Works fine. But I don't need it
arm-apple-darwin10-cpp-4.2.1
arm-apple-darwin10-g++-4.2.1
arm-apple-darwin10-gcc-4.2.1
The above compiles fine, but doesn't cross compile to arm as I would have expected, instead, it simply compiles to my current arch.
I'm a real beginner in this matter, in fact this is my first attempt to cross-compile something.
UPDATE:
Here are the commands that I've tried(this is for armv6; armv7 is similar):
configure:
../llvm/configure --host=arm-apple-darwin6 --target=arm-apple-darwin6
--build=i386-apple-darwin --enable-optimized --disable-debug
--disable-expensive-checks --disable-doxygen --disable-threads
env vars:
export DEVROOT=/Developer/Platforms/iPhoneOS.platform/Developer
export SDKROOT=$DEVROOT/SDKs/iPhoneOS$IOS_BASE_SDK.sdk
export CFLAGS="-arch armv6 -pipe -no-cpp-precomp -isysroot $SDKROOT -miphoneos-version-min=$IOS_DEPLOY_TGT -I$SDKROOT/usr/include/"
export CPP="$DEVROOT/usr/bin/arm-apple-darwin10-cpp-4.2.1"
export CXX="$DEVROOT/usr/bin/arm-apple-darwin10-g++-4.2.1"
export CXXCPP="$DEVROOT/usr/bin/arm-apple-darwin10-cpp-4.2.1"
export CC="$DEVROOT/usr/bin/arm-apple-darwin10-gcc-4.2.1"
export LD=$DEVROOT/usr/bin/ld
export AR=$DEVROOT/usr/bin/ar
export AS=$DEVROOT/usr/bin/as
export NM=$DEVROOT/usr/bin/nm
export RANLIB=$DEVROOT/usr/bin/ranlib
export LDFLAGS="-L$SDKROOT/usr/lib/"
export CPPFLAGS=$CFLAGS
export CXXFLAGS=$CFLAGS
UPDATE : The purpose of this cross compile is to make an armv7(armv6) library not a command line tool.
YET ANOTHER UPDATE: I used the following:
CC="$DEVROOT/usr/bin/clang"
CXX="$DEVROOT/usr/bin/clang++"
./llvm/configure --host=i386-apple-darwin --target=armv7-apple-darwin --build=armv7-apple-darwin --enable-optimized --disable-debug --disable-expensive-checks --disable-doxygen --disable-threads --enable-targets=arm
And I managed to get checking whether we are cross compiling... yes out of the configure tool. However, make still outputs a x86_64 binary:(
In principle your configure invocation looks good. I'm trying to shoot a few typical mistakes:
Did you make clean after every change of architecture?
Why are you so sure that the LD, RANLIB etc. of your host system are fine for cross-compilation? It will overwrite the auto-configured value of LD. (The line reading "export LD=ld" would be at fault here.)
Could you check a typical compiler and a typical linker invocation in the output of make for their correct use of the cross-compilation tools?