I am a java developer. I have some C++ code to make some system realted calls. This code is compiled on Intel 32-bit platform using GCC (I have make files) and it works fine on regular Intel based 32-bit linux machine. Now I need to run this on a linux OS running on Marvell ARM processor. When I load the shared objects in java I get the following error.
cannot open shared object file: No such file or directory (Possible cause: can't load IA 32-bit .so on a ARM-bit platform)
Please tell me how to resolve this issue. I looked at the GCC options and I found one option to specify the architecture (-march=armv5) and I can't compile with that option.
Thanks in advance.
You need more than just a switch, you need a cross-compiler. You can make your own, but probably the easiest way is :
Find the development tools for your board. It probably comes with a development kit that includes a cross-compilation toolchain
If you don't have these, you can try to install a precompiled cross-compilation like the ones provided freely by CodeSourcery
Then you have to make the location of your toolchain (look for something like arm-none-linux-gnueabi-gcc) available in your path.
Cross compiling simple project is then easy, just override the CC variable in your Makefile :
CROSS = arm-none-linux-gnueabi-
CC = $(CROSS)gcc
LD = $(CROSS)ld
Try using the -mcpu=armv5 switch for gcc.
Here is what's written on http://elinux.org/RPi_Software#ARM:
-Ofast -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s
Related
I'm currently trying to compile a project and port it to a 32bit target deploying a Linux based system.
My host machine runs x86_64 Debian Stretch and my target is an Atmel SAMA5d2 running a custom Linux.
My cross toolchain is generated from buildroot.
At the moment I'm able to cross compile applications for the target using the buildroot generated toolchain. However, I would like to integrate Qt and build Qt apps for the target.
To be able to build my applications for the targetted platform I need to compile Qt for my target.
To do so I have to tell Qt to use the buildroot toolchain instead of the native one.
From what I found I either have to provide -device <device> --device-option CROSS_COMPILE=$TOOLCHAIN_PATH or -xplatform <mkspec> to configure Qt with the expected toolchain.
Obviously my target is not in the device list under qtbase/mkspecs/devices so I think the best solution is to create a mkspec for my target.
My command should look like this :
./configure -xplatform <my_mkspec> -embedded arm -prefix <customQtPath>
However I'm kinda lost and I don't know how to do it only from documentation and what I found by googling my problem.
Also do I need to specify the target is 32bit as armv7 is only 32bits?
I would be glad to have some help on this.
Thanks.
Your assumptions are correct. You can read similar specs and create your own, those are pretty simple. For instance Pi2 is an armv7 device, you can start from this qmake.conf. Then, pass to configure:
-device <given_name> -device-option CROSS_COMPILE=<path_and_prefix> -sysroot <your_sysroot>
just change paths, tune cflags if needed etc... Then follow build tutorials.
Has anybody successful cross compiled the Xalan C++ library for armv7/armv7s arch to be used on iOS device (not simulator)?
I was able to cross compile the xerces library by setting the iOS g++/gcc compilers for armv7 but using the same procedure for Xalan gives me below error while running the make file:
iComp:c iComp$ make
Linux, Solaris, AIX, Compaq Tru64, OS/390, MacOSX, HP-UX, NETBSD, FREEBSD, CYGWIN, and MINGW are the only platforms supported.
Above error clearly states that I cannot target the iOS platform.
So was there some problem in configuring the makefiles?
UPDATE
The above issue was occurring because of incorrect usage of Xalan's runConfigure file.
The correct usage to pass additional options to Configure file via runConfigure is to use '-C' option with "--host=arm-apple-darwin --disable-shared"
This has helped to resolve the above platform detection issue and generated the cross-compile make files.
PROBLEM
But now the issue is while running the make, default MsgLoader (inmeme)executable is generated (target: armv7) and after that the make file tries to run the armv7 executable on Mac OSX obviously giving the error 'Bad CpuType in executable'
How can I either avoid the building of Xalan by creating a armv7 exe of MsgLoader or run this armv7 exe in terminal (doesn't seems possible!) so that it proceeds with the build.
Thanks in advance for any help!!!
I'm trying to cross-compile the Boost library for an ARM platform (poky toolchain) and I'm new to cross compilation. I'm having issues at the first step -- running bootstrap.sh. I see many posts regarding boost cross-compilation, but not so many helping at the bootstrap level.
A few questions:
1) What should I put exactly in 'user-config.jam'? I tried:
using gcc : arm : arm-poky-linux-gnueabi-g++ ;
I see many ones specifying an exact path to the compiler.
2) Where's the best place to put the user-config.jam file? I tried my home (~) folder and the current folder.
3) The toolchain has a file named "environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi", should I "source it" before running bootstrap?
Any help appreciated, thanks.
Common tasks - 1.64.0
https://www.boost.org/doc/libs/1_64_0/doc/html/bbv2/tasks.html
Cross-compilation
Boost.Build supports cross compilation with the gcc and msvc toolsets.
When using gcc, you first need to specify your cross compiler in user-config.jam (see the section called “Configuration”), for example:
using gcc : arm : arm-none-linux-gnueabi-g++ ;
After that, if the host and target os are the same, for example Linux, you can just request that this compiler version be used:
b2 toolset=gcc-arm
If you want to target a different operating system from the host, you need to additionally specify the value for the target-os feature, for example:
# On windows box
b2 toolset=gcc-arm target-os=linux
# On Linux box
b2 toolset=gcc-mingw target-os=windows
For the complete list of allowed opeating system names, please see the documentation for target-os feature.
When using the msvc compiler, it's only possible to cross-compile to a 64-bit system on a 32-bit host. Please see the section called “64-bit support” for details.
I'm currently programming an extension to a program, which only supports
i386 (and I am running amd64 Ubuntu 11.10). Whenever I compile my extension source
I need to use the -m32 flag to force 32 bit architecture (otherwise the program will not be able to load my extension). Sooner or later it is inevitable to avoid boost
thanks to its huge and stable library, which leads to my problem.
I want to use the boost filesystem, which uses OS specific function calls, which in turn leads to the requirement of a library file instead of only a header implementation. The problem is; I can't/don't know how to setup the boost filesystem (i386 version) on my amd64 machine. If I download a prebuilt (.deb) package for i386 and install it using -force-architecture it still fails complaining about dependencies.
So basically; how do I setup boost with 32bit (i386) architecture on my (amd64) system?
It seems as if I did it right all along but I was too dumb to realize how to properly link libraries with the GCC linker, coming from a Windows environment. You can easily compile boost libraries by using the -m32 flag and by setting up bjam properly. See the first answer in this question for details: How do I force a 32 bit build of boost with gcc?
Are the gcc and g++ compilers installed on a MAC OS X machine different from the ones on Ubuntu (Linux) GNU gcc and g++ compilers?
I am using Eclipse to develop a C++ program and there is toolchain section where it says MacOSX GCC and I was wondering if I need to install another compiler so that the executable would also run on Linux machines.
I am a bit new to the technical details of C++ development so I am sorry if this question does not make sense.
It it very unlikely that binary will execute on both Mac and on Linux. If is pretty likely that a binary will not execute between different distro's of Linux. You can either compile you binary for each OS. Or you can distribute the source code for you application and let you users compile it themselves.
Different versions of libstdc++.so are likely distributed with different OS's and this will cause you problems. A solution that partly works is to statically compile your binary so you are not depending on the target systems installed version of libraries.
MacOS is not Linux, it might have a bit in common with BSD, but definitely not Linux. They do, or can, use different configurations of the same compiler, but the programs are not compatible.
The only way you're going to run the same program on both is if you have something like Wine to provide a compatibility layer.