What is the best way to compile programs with DMD on a 64bit machine? It doesn't need to compile to 64Bit code. I know about GDC, but want to work with D2 also. There is also chroot, but am hoping for a simpler way.
The actual problem isn't with compiling, but linking. DMD calls on GCC to perform linking with system libraries. Could I get DMD to have GCC link against 32bit library? Or how would I do it manually?
I already have the ia32 libraries installed which is why I can run DMD.
Ask GCC to perform 32-bit link by passing it '-m32' flag.
It appears that DMD doesn't invoke gcc to perform the link, but rather invokes ld directly. The equivalent ld switch is '-melf_i386', and apparently the way to make DMD pass that option to the linker is with '-L-melf_i386' flag.
Note that many systems separate runtime and development libraries. 32-bit runtime packages are almost always installed by default, but 32-bit development packages may not be.
You need development 32-bit packages to build 32-bit programs. The fact that 32-bit DMD can run does not in itself prove that you have all the 32-bit libraries you need in order to build 32-bit programs.
Related
I'm cross-compiling an application for aarch64 on my x86 Ubuntu Bionic system, and I have problems with glibc version mismatch. My cross-compile toolchain was using v2.27, while the system that is to run the application has v2.24. I thought that it might be due to my toolchain having a too high version, so I decided to downgrade.
After removing all previous cross-compilation installs, I installed gcc-4.8-aarch64-linux-gnu (as I had successfully cross-compiled the application with this version on a different host system), thinking that it would install an older aarch64 version of glibc to /usr/aarch64-linux-gnu/lib/. However, again, v2.27 was installed (I verified that this directory didn't exist before installing the new cross-compilation toolchain).
So my question is twofold:
What determines which aarch64 version of glibc is installed on my system when installing gcc-4.8-aarch64-linux-gnu? Is it directly tied to my own system's x86 version of glibc?
Is there a correct way to install the aarch64 version of glibc v2.24 (or lower) on my system?
I concur with your hypothesis. After battling similar symptoms for 40 hours straight, I've discovered this confirmation:
https://packages.ubuntu.com/impish/gcc-10-aarch64-linux-gnu
https://packages.debian.org/bullseye/gcc-aarch64-linux-gnu
Note that Ubuntu 21.10 (Impish) and Debian 11 (Bullseye) have packages for a gcc 10 cross compiler. Be wary of the very confusing fact the Ubuntu's default package is actually gcc 11, but Debian 11's default is gcc 10. The similar version numbers of Debian and gcc are a coincidence. Also ignore for now the fact that Ubuntu's package is gcc 10.3.0 and Debian's is gcc 10.2.1.
Focus instead on the recommendations and dependencies of each package. Ultimately the Ubuntu package calls up libc >= 2.34, while the Debian package calls up libc >= 2.28.
Sure enough, when I cross-compile from Impish on x86 for Bullseye on aarch64 (despite having a complete SYSROOT for the target), I get this at runtime:
/lib/aarch64-linux-gnu/libc.so.6: version 'GLIBC_2.34' not found
But your question remains, is there any tie between the host libc and that used by the cross-compiler? The answer is a definite maybe.
See this excellent answer and links for an overview of a cross-compiler. The take-away:
You don't just cross-compile glibc, you need to cross-compile an entire toolchain. Toolchain components are ALWAYS: ld + gcc + libc + gdb.
So the C library is an integral part of the cross-compiler.
What shenanigans then, are going on when you install gcc-aarch64-linux-gnu? It's just a compiler - only one of the four parts of a toolchain.
Well apparently there's some flexibility. Technically, a cross-compiler can be naked. That's typically only useful when you're compiling an operating system, rather than an executable that runs on an operating system. So you can construct special toolchains for special purposes.
But for the standard purpose (cross compiling for Linux on another architecture) you want a typical toolchain. Which is where the package's dependencies and recommendations come in. A gcc is always in want of an ld which is always in want of a libc, and the ménage à trois is intimate. In fact, gcc is built with libc using ld in a complex do-si-do. See this example from a great guide by Preshing on Programming:
It's possible to force separation and link to other libraries, but it's not easy.
For example, the linker you use has a set of default search directories that are baked in. From the fine manual:
The default set of paths searched (without being specified with -L) depends on which emulation mode ld is using, and in some cases also on how it was configured.
And it gets more intwined. By default, gcc will call on a dynamic linker whose location is hard-coded. For a cross-compiler, it might be something like /lib/ld-linux-aarch64.so.1. Not only that, the executable may also end up with the hardcoded path, as its program interpreter.
Again, if you're careful you can tear apart the toolchain and override things. But not only is it tricky to enforce, particularly if you have a complex build, the multitude of combinations of options and paths means there are also often bugs. So your host environment can easily leak into your cross-compiling toolchain.
So in summary, cross-compiling requires a toolchain. While pulling a cross-compiler from a package manager seems like an easy and legitimate thing to do, it comes with a lot of implicit baggage. You can either carefully follow the package dependencies to check what version you're getting, or use one of the many dedicated toolchain environments, such as crosstool-NG.
Can we configure gcc running on intel x64 architecture to produce binary for ARM chip by just passing some flags to gcc and not using a cross compiler.
Short: Nope
Compiler:
gcc is not a native crosscompiler, the target architecture has to be specified at the time you compile gcc. (Some exceptions apply, as for example x86 and x86_64 can be supported at the same time)
clang would be a native crosscompiler, and you can generate code for arm by passing -target=arm-linux-gnu, but you still cant produce binaries, as you need a linker and a C-library too. Means you can run clang -target=arm-linux-gnu -c <your file> and compile C/C++ Code (will likely need to point it to your C/C++ include paths) - but you cant build binaries.
Rest of the toolchain:
You need a fitting linker and toolchain too, both are specific to the architecture and OS you want to run at.
Possible solutions:
Get a fitting toolchain, or compile your own. For arm linux you have for ex. CrossToolchains if you are on debian, for barebones you can get a crosscompiler from codesourcery.
Since you were very vague, its not possible to give you a clearer answer
I am using Ubuntu 13.04 and installed mingw-w64 using apt-get install mingw-w64. I can compile and link a working 64-bit version of my program with the following command:
x86_64-w64-mingw32-g++ code.cpp -o app.exe
Which generates a 64-bit app.exe file.
What binary or command line flags do I use to generate a 32-bit version of app.exe?
That depends on which variant of toolchain you're currently using. Both DWARF and SEH variants (which come starting from GCC 4.8.0) are only single-target. You can see it yourself by inspecting the directory structure of their distributions, i.e. they contain only the libraries with either 64- or 32-bit addressing, but not both. On the other hand, plain old SJLJ distributions are indeed dual-target, and in order to build 32-bit target, just supply -m32 flag. If that doesn't work, then just build with i686-w64-mingw32-g++.
BONUS
By the way, the three corresponding dynamic-link libraries (DLLs) implementing each GCC exception model are
libgcc_s_dw2-1.dll (DWARF);
libgcc_s_seh-1.dll (SEH);
libgcc_s_sjlj-1.dll (SJLJ).
Hence, to find out what exception model does your current MinGW-w64 distribution exactly provide, you can either
inspect directory and file structure of MinGW-w64 installation in hope to locate one of those DLLs (typically in bin); or
build some real or test C++ code involving exception handling to force linkage with one of those DLLs and then see on which one of those DLLs does the built target depend (for example, can be seen with Dependency Walker on Windows); or
take brute force approach and compile some test code to assembly (instead of machine code) and look for presence of references like ___gxx_personality_v* (DWARF), ___gxx_personality_seh* (SEH), ___gxx_personality_sj* (SJLJ); see Obtaining current GCC exception model.
I'm trying to use the 64-bit MinGW from http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/ but when I compile a program with it, the resulting executable fails when a DLL isn't available.
How do I get this compiler to do static linking with the standard library?
Or is there another distribution of 64-bit MinGW that I should be using instead?
The g++ switch is supposed to be
-static
See
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html.
-static
On systems that support dynamic linking, this prevents linking with
the shared libraries. On other systems, this option has no effect.
You should post the command line, that you use in order to compile/link, in order to get more help if this does not work for you.
I'm trying to use the asmlibrary which I've obtained from here
I'm running in 64-bit, but the pre-compiled static library is build for 32-bit.
I don't really want to recompile the library, because I do not have OpenCV 1.0 installed, and don't really want to install such an old version of this piece of software.
My employer has told me that you may use ia32-libs which would allow me to use the library on a 64-bit machine. I have installed these libs using apt.
In netbeans, my IDE of choice, I'm now attempting to use the library. I keep getting the messages:
/usr/bin/ld: i386 architecture of input file
`../asmlib/libasmlibrary.a(asm_shape.o)' is incompatible with
i386:x86-64 output
Etc..
I have two questions:
1) Will ia32-libs allow me to use this library?
2) How must I "enable" it's use, either generally or preferably specific to netbeans (if applicable)
Thank you
An executable (including the libraries it depends on) has to be entirely 32 bits or 64 bits. You cannot mix and match object files of different types.
So to use a 32 bits library, you must compile your program as a 32 bits executable and link with a 32 bits version of libc and other core libraries. On debian you'll need packages like libc6-dev-i386 and ia32-libs-dev.
To compile foo.c as a 32 bits executable, use
gcc -m32 -o foo foo.c
How to do this with netbeans is left as an exercise.
I don't think that you are able to use ia32-libs to compile a 64-bit program, using 32-bit libraries. That isn't what ia32-libs is designed for...it's designed to run entirely 32-bit programs on 64-bit systems.
I think your best bet would be to compile as 32-bit software. If you were using the command line, you can just add the -m32 flag to gcc. With netbeans, in Project Properties > Build > C Compiler (or C++ compiler if that's what you are using), there is a dropdown to select architecture. If 32-bit is not available in that dropdown, you can add -m32 to the Additional Options box.