This is not essential for my programs, but merely out of curiosity. Is it possible to, preferably using gcc, compile a 'fat' binary for Linux including multiple architectures such as combinations of amd64, i386, lpia and powerpc?
The ELF format for executables that linux uses does not support fat binaries, so there's currently not a reasonable way to do this.
There's an extension to ELF available at http://icculus.org/fatelf/ , to use it you need to patch various parts (linux kernel,binutils,glibc etc.) as these changes are not integrated in the mainline yet.
You don't need a fat executable in Linux. Instead, you can write a bash script that will choose and execute the correct binary.
Related
ELF binaries of Linux distributions are stripped and don't include ".comment" section.
Therefore, I could not get the information which compiler build the ELF binary.
I guess most of them are created by GCC and want to know which GCC version is used.
I know that if the ".comment" section is included in the ELF binary, I can get the compiler information using "readelf" or "objdump".
The method was posted before at the stackoverflow.com
How to retrieve the GCC version used to compile a given ELF executable?
I guess I can use decompiling tools (e.g., Hex-Rays Decompiler https://www.hex-rays.com/products/decompiler/ ) to estimate the compiler version.
I also want to know the compiler name if the binary is not created by GCC. For example LLVM-clang.
Do you know a tool to estimate the compiler name and version which create the ELF binary?
I prefer to use a free tool.
ELF binaries of Linux distributions are stripped and don't include ".comment" section. Therefore, I could not get the information which compiler build the ELF binary.
Most binaries also come with a separate debuginfo package, which does have .comment sections, and full source package which allows you to configure and build (almost) identical binary.
Examining either the debuginfo, or the source package is a much easier and more reliable way to answer your question, then guessing from the binary will ever be.
Do you know a tool to estimate the compiler name and version which create the ELF binary?
I doubt such a tool exists: writing such a tool would be a mostly pointless exercise.
here is an interesting question that, if answered positively, would make cross compiling a whole lot easier.
Since gcc is written in C++, would it be possible to recompile the Linux gcc compiler on Windows MinGW G++ or VSC++ compiler, so that the resulting Windows executable would be able to compile c code to linux programs?
If so, what would be needed to do that?
So to simplify, here is what I want to do.
mingw32-g++ gcc.cpp -o gcc.exe
The command will probably not work because it would probably have been done before if it were that easy. What I ask is if this concept would be even possible.
Edit: thanks and expanding the question to NVCC
fvu was able to answer the question for the gcc compiler (please use the answer button next time), so if you had the same question you can thank him (or her) .
As an extention to the question, would it be possible to edit or recompile nvcc or the things it uses so that nvcc.exe can create a linux program from CUDA C code? I read that the windows variant of nvcc can only use the Visual Studio cl.exe and not MinGW or CygWin.
Is it possible to create linux programs with cl.exe? And if so, could that be used to generate linux programs with nvcc.exe?
Read the chapter on cross compiling in the gcc manual, gcc's architecture makes it quite easy to set up a toolchain where the target is different from the development machine.
I never went the exact route you describe, but I have built toolchains under Windows that target ARM9 embedded Linux machines, works like a charm - using cygwin btw. Look here for a gentle introduction. Also very useful info here.
I am not going to comment on what can be done with respect to nvcc, CUDA is somewhere on my (long) list of stuff to tinker with...
Now, can cl generate Linux binaries? The answer to this question is "sort of" : as long as the target processor is from a processor family that's supported by cl, the object files generated by it should probably not contain anything that would inhibit its execution on Linux, as they'll just contain machine code. That's the theory. However:
as Linux uses another executable format, you will need a Windows-hosted linker that understands Windows style object files (afaik, COFF), and links them together to a Linux style (ELF) executable. I never heard of such a beast, although in theory it could exist
the startup code (a tiny program that wraps around your main function) will also be different and needs to be written
and some more, eg library related issues
So, the practical answer is no, although it might be a nice summer project for a bored student :)
I am aware that there are (at least) two radically different kinds of shared-library files on Unix-type systems. One is the kind used on GNU/Linux systems and probably other systems as well (with the filename ending in ".so") and the other used in Mac OS X, and also possibly other systems as well (with the filename ending in ".dylib").
My question is this --- is there any type of test I could do from a shell-script that would easily detect which of these two paradigms the current OS uses for shared libraries?
I'm sure I could find some way to easily deal with this variance --- if only I knew of a simple test I could run from a shell-script that would tell me which type of shared library is used on the current system.
Well, I guess you need to check filetypes of executables on a target platform. You may use file for that (check its output for, say, /bin/ls ). ELF is a most widely used executable type on Linux, while Mach-O is "natively" used in MacOS X.
A note: technically there're other executable types on these systems, say a.out and PEF, and, you guess, those formats have their own dynamic libraries. Frankly speaking Linux has a pluggable support for executable formats and even Win32 .EXEs may be executed "quasi-natively" in Linux (of course, they need an implementation of Win32 API working above a given kernel API, WINE is a such implemetation).
Also if you need to create a dynamically loaded library, then you should use one of those portable build systems (to name a few: GNU autotools, CMake, QMake...). Thus you'll get not only ordinary DLL extension but also linker flags, portable methods of installation/uninstallation and so on...
I have a code that I have written in Fortran during my PhD, and now I am collaborating with some researcher that uses Linux, and they need my model, that is basically a single executable file. In the future I will probably make it open source, but up to know they just want the executable, also because they are not programmers and they have never compiled a program in their life. So the question is: is it possible to compile it on my linux machine and then send it to them in order to use it in another linux machine?Or does the linux version and distribution matter?
thank you very much
A.
If you do not use many libraries you can do that. One option is statically linking the executable (-static or similar compiler option). You need to have the static versions of all needed libraries for that. The have .a suffix. They are often not installed by default in Linux distributions and often they are not supplied in the repositories at all.
In my distrbution (OpenSuSE) they are in packages like glibc-devel-static, lapack-devel-static and similar.
The other option would be to compile the executable on a compatible distribution the users will have (GLIBC version is important) and supply all .so dynamically linked libraries they will need with your executable.
All of this assumes you use the same platform, like i586 or amd64 or arm like wallyk comments. I mostly assumed you are on a PC. You can force most compilers to produce a 32-bit or 64-bit executable by -m32 or -m64 option. You need the right version of the development libraries for that.
Is there any way to produce stand alone haskell executable to run on different linux machines assuming the architecture is similar?
Sorry I should have been clearer. The other machines might not have ghc installed on them - a bit like pyinstaller for python is what I was looking for?
You can use the flags -static -optl-pthread -optl-static to avoid dynamically linked dependencies when compiling a Haskell project. This should help you run the compiled executable on two linux machines that do not have the exact same library versions.
Yes it is possible. Just like with gcc-produced binaries, you can copy them between systems assuming the dynamic libraries and platforms match.
In practice, that's a slightly higher bar than GCC binaries because GHC will dynamically link more libraries by default (ex: libgmp, unless you build GHC using integer-simple).