Where can I get compiled libraries specific architectures? My company hired some contractors to port some code to our powerpc platform. I am trying to move this to an arm platform(omap3).
They created a cross compiling environment(in Windows). All of the libraries that are linked at still compiled for PowerPC. For each lib there are 3 files: .so, .so.X and .so.X.Y.Z I can get the second 2 from the deb packages and I found the .so in developer deb package but it is 0 bytes.
Any help would be great.
Maybe in Angstrom?
Theres no way (that I know of) to convert a binary from machine A(power pc) into binaries for machine B(arm). If you have the source, or a way of acquiring the source, you can rebuild them for your arm target. You can accomplish this by either using a local compiler on a arm machine, or cross compile using a cross compiling tool chain (eg code sorcery lite (http://www.codesourcery.com/sgpp/lite/arm) to build libraries from your build machine onto your arm target. Most libraries are not obtainable on arm in a pre-compiled form.
Depending on what OS you're using on your arm target, eg debian or redhat. There may be a package manager available to do this for you.
Related
I have created a bare-bone Linux ARM system. It boots to a busybox shell without any issues on my ARM system.
Now I want to build a working gcc/glibc environment that I can use on my ARM system.
My development machine is x86. I have read tutorials talking about doing a "cross-compiler", but that does not seem what I want. Seem that is just a compiler that runs on x86, but can generate ARM binaries.
I need to create a compiler that runs on ARM and creates ARM binaries. But I need to build it on my x86 machine and then copy it over to my ARM one. Then going forward, I can extend the system by compiling natively on the ARM machine.
So, I probably need to use "cross-compiling" to create this gcc/glibc, but the result should be ARM for ARM and not a ARM for x86. Am I correct? Is it just a matter of playing around with the "taget", "host" variables?
All tutorials I have read shows how you build the system into an isolated target directory, but they don't explain what parts I need to copy to the target ARM system root.
So, I probably need to use "cross-compiling" to create this gcc/glibc, but the result should be ARM for ARM and not a ARM for x86. Am I correct?
This is correct, but not the complete workflow. You need more compilers than you might imagine.
Is it just a matter of playing around with the "target", "host" variables?
This is more complex than you might first imagine. I would like to refer you to
crosstool-NG's Toolchain Types and Wikipedia's Canadian Cross for reference.
A little reading will reveal that you are trying to make a cross native compiler with, I assume, build as x86-glibc-linux, host as arm-glibc-linux and target as arm-glibc-linux. You need a native compiler (x86-glibc-linux) to make a cross arm-glibc-linux that runs on x86 (host). This is because the cross native arm-glibc-linux needs to build a glibc as part of the toolchain that will run on the ARM. You need more than a compiler; linker (gold?), libraries (shared/static), etc.
Crosstool-ng supports this and generally yocto and distros use it some where to create their version. There are often more efficient ways to do this than with crosstool-ng as sometimes only a bootstrap compiler will suffice and/or you can reuse code built for a previous compiler build. See for example,
A “cross-native” toolchain can be built as a trivial case of the “canadian” toolchain. It is suboptimal, as it makes crosstool-NG build the tools targeting the host machine twice (first, as a separate toolchain which is a prerequisite for all canadian builds; and second, as a part of temporary toolchain created as a part of the canadian build itself). This will likely be improved in the future.
However, if this is rarely done you can do this building while you are doing other things. I took several days to make a Canadian cross of "x86-64-linux/x86-mingw/arm-linux" to allow Windows development for an ARM Linux device. If you think you will create this compiler many times (to track gcc development for instance) you might want to look at a custom script instead of crosstool-NG.
Background:
Im using QT and have visual studio 2012 as my IDE (used the QT plugin for visual studio).
And finally the whole project is done. However due to my .NET background I have no experience when it comes to deploying my project so it can be run on Linux.
Question:
Anyone knowing how to deploy a QT project made in visual studio to linux?
You should install Linux and prepare a Qt development environment on it.You can then copy your project there, compile it and see the results in the real environment. This way you can cope with the minor differences when porting from one OS to another easily.
So don't think of cross compiling your app for Linux on Windows. From a complexity point of view, I think setting up a Linux machine (VM or not) and the necessary environment for Qt is a whole lot simpler than cross compiling bug hunting afterwards. After all you will need a real target environment to finally test your application.
Before you can deploy something you have to compile it for that platform, and here you have two main choiches: either you cross-compile which means you compile it on windows using a set of tools so that your software is built to run on a linux, or you get a linux machine, you copy your entire project over and let Qt for linux do the magic.
Once you have your working binary compiled on linux or for linux then you start thnking about deployoment.
If you really want to be fully linux-compatible and "linux-ally correct" you should distribute your source-code precooked using some tools like "automake" that will make it possible to linux users to compile it on any linux version.
If you do not want to release your source code, you technically can distribute binaries without source code (not sure if you will be ok with licenses) but you have to be aware that there is no standard in linux for distributing binary packages, there are at least 2 main package building standards that are the ubuntu/debian style and red hat (and friends) style.
You are going to find plenty of documentation about all this stuff from cross-compile to automake and of course building debian packages and building red hat rpm packages.
I'm trying to build a native ARM GDB for an ARM board to use. Since it lacks a lot of the tools GDB needs for compilation, I'm trying to build it on my x86 machine.
./configure --host=arm-linux-gnueabi --target=arm-linux-gnueabi && make
However, half way through the build process, it complains that "termcap library" is missing. I think it means it couldn't find an ARM version of the library for it to use. So, is there a possible workaround, or should I not bother with this approach and think of another way?
You should be able to do this for your "ARM board". You need to compile GDB library dependencies (e.g. the termcap library) and install them where the cross compiler can find them before you can build GDB. Without a more specific description about the cross compilation toolchain and board it's hard to give more specific advice that will be helpful to you.
I cross build GDB for several Linux targets for my ELLCC cross development tool project (http://ellcc.org). You do need a few libraries built for the target to do a build. In addition to the standard C library, I used libedit, zlib, expat, and ncurses.
I'd like to set up a cross-compilation environment on a Ubuntu 9.10 box. From the documents I've read so far (these ones, for example) this involves compiling the toolchain of the target platforms.
My question is: how do you determine the required version of each of the packages in the toolchain for a specific target platform? Is there any rule of thumb I can follow?
This is a list found in one of the websites linked above:
binutils-2.16.1.tar.bz2
linux-2.6.20.1.tar.bz2
glibc-2.5.tar.bz2
glibc-linuxthreads-2.5.tar.bz2
gcc-core-4.2.0.tar.bz2
gcc-g++-4.2.0.tar.bz2
But suppose I want to generate executables for standard Ubuntu 8.04 and CentOS 5.3 boxes. What are the necessary packages?
My primary need is to avoid errors like "/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found" in the customers' machines but in the future I want to deal with different architectures as well.
It is generally a good idea to build a cross-toolchain that uses the same version of libc (and other libraries) found on the target system. This is especially important in the case of libraries that use versioned symbols or you could wind up with errors like "/usr/lib/libstdc++.so.6: version 'GLIBCXX_3.4.11' not found".
Same Architecture
For generating executables for standard Ubuntu 8.04 and CentOS 5.3 systems, you could install the distributions in virtual machines and do the necessary compilation from within the virtual machine to guarantee the resulting binaries are compatible with the library versions from each distribution.
Another option would be to setup chroot build environments instead of virtual machines for the target distributions.
You could also build toolchains targeted at different environments (different library versions) and build under your Ubuntu 9.10 environment without using virtual machines or chroot environments. I have used Dan Kegel's crosstool for creating such cross-toolchains.
Different Architecture
As I noted in my answer to a another cross-compiler question, I used Dan Kegel's crosstool for creating my arm cross-toolchain.
It appears it may be slightly out of date, but there is a matrix of build results for various architectures to help determine a suitable combination of gcc, glibc, binutils, and linux kernel headers.
Required Package Versions
In my experience, there really isn't a rule of thumb. Not all combinations of gcc, binutils, glibc, and linux headers will build successfully. Even if the build completes, some level of testing is necessary to validate the build's success. This is sometimes done by compiling the Linux kernel with your new cross-toolchain. Depending on the target system and architecture, some patching of the source may be necessary to produce a successful build.
Since you are setting up this cross-compilation environment on Ubuntu 9.10, you might want to look into the dpkg-cross package.
Compiling for other Linux distributions is easiest by installing them in virtual machines (apt-get install kvm) and then doing the compilation from within. You can also script them to do it automatically. Building a cross-compiler and providing the exact same versions of all libraries and such, as the other Linux distro does, is nearly impossible.
My question is: how do you determine
the required version of each of the
packages in the toolchain for a
specific target platform?
...
binutils-2.16.1.tar.bz2
gcc-core-4.2.0.tar.bz2
gcc-g++-4.2.0.tar.bz2
Generally pick the latest stable: these only affect your local toolchain, not runtime.
linux-2.6.20.1.tar.bz2
You don't need this. (For targeting embedded platforms you might use it.)
glibc-2.5.tar.bz2
glibc-linuxthreads-2.5.tar.bz2
You don't need these. I.e. you should not download them or build them; you should link against the versions from the oldest distro you want to support.
Is there any
rule of thumb I can follow?
But suppose I want to generate
executables for standard Ubuntu 8.04
and CentOS 5.3 boxes. What are the
necessary packages?
You survey the distros you want to target, find the lowest common denominator versions of
of libc, libstdc++, pthreads, and any other shared library you will link with, then copy these libs and corresponding headers from the box that has these LCD versions to your toolchain.
[edit] I should clarify, you really want to get all the dependent libs from a single system. Picking and choosing the LCD of each file version from different distributions is a recipe for a quick trip to dependency hell.
Depending on your target platforms, have you considered using Optware?
I'm currently working on getting Mono and Moonlight built for my Palm Pre using the cross-compilation toolchain (and the Optware makefiles handle the majority of dependencies already).
Is there anyway to write dlls in linux?
Do I have to install windows to write dlls in linux? Right now one of my courses requires me to write a dll for this.
You should take a look into 'shared libraries'
http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html
Lots of folks are getting near the right answer but not providing it: gcc can generate win32 PE/COFF files without problem, and of course can always build as a cross compiler on any platform it can target. The binutils port targets windows .exe and .dll files natively, and there's a "dlltool" utility for handling the edge cases where Unix and Windows linkage metaphors are different.
Additionally, the "mingw32" project provides a set of link libraries and header files for building C applications against the win32 API. These likewise install just fine on any Unix.
Here's a site I turned up after a quick google with instructions for building the toolchain.
Not really. Building any kind of executable intended for OS "A" while using OS "B" is a process commonly known as cross-compilation. In this partciluar case, you would need a cross-compiler running on Linux, but targetting Windows. I don't know any vendor selling such a product.