AutoConf has --host option to specify an architecture the file will be run on. But if I specify --host=i686-linux-gnu, no option -m32 is added to gcc compiler. What did I understand wrong about AutoConf? Because in this case, if I compile my program on 64 bit machine, it won't run on host machine.
Passing --host=i686-linux-gnu will cause autoconf to look for and use i686-linux-gnu-gcc, etc. rather than gcc. This is expected to be a cross toolchain that produces 32-bit binaries. If you don't want to use a cross toolchain but just -m32, you should just pass CC="gcc -m32" (and CXX="g++ -m32" if the program uses C++) to configure.
Related
When using clang v8.0.0 on Windows (from llvm prebuilt binaries) with -g or -gline-tables-only source map tables are not being picked up by gdb or lldb debuggers.
Upon including -g flag file grows in size (which is to be expected) yet neither gdb nor lldb pickes the source up
When compiled with gcc though (with -g flag) source files are detected by debugger.
I have tried running the same command (clang -g <codefile>) on macOS High Sierra (clang -v says it is Apple LLVM version 10.0.0 (clang-1000/10.44.4)) where there source files are being picked up by lldb. So I guessed it is localized to my windows instance or llvm for windows build.
P.S. output of clang -v on windows:
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
On Windows, Clang is not self-sufficient (at least not the official binaries). You need to have either GCC or MSVC installed for it to function.
As Target: x86_64-pc-windows-msvc indicates, by default your Clang is operating in some kind of MSVC-compatible mode. From what I gathered, it means using the standard library and other libraries provided by your MSVC installation, and presumably generating debug info in some MSVC-specific format.
Add --target=x86_64-w64-windows-gnu to build in GCC-compatible mode. (If you're building for 32 bits rather than 64, replace x86_64 with i686). This will make Clang use headers & libraries provided by your GCC installation, and debug info should be generated in a GCC-compatible way. I'm able to debug resulting binaries with MSYS2's GDB (and that's also where my GCC installation comes from).
If you only have GCC installed and not MSVC, you still must use this flag.
How do I know this is the right --target? This is what MSYS2's Clang uses, and I assume they know what they're doing. If you don't want to type this flag every time, you can replace the official Clang with MSYS2's one, but I'm not sure if it's the best idea.
(I think they used to provide some patches to increase compatibility with MinGW, but now the official binaries work equally well, except for the need to specify the target. Also, last time I checked their binary distribution was several GB larger, due to their inability to get dynamic linking to work. Also some of the versions they provided were prone to crashing. All those problems come from them building their Clang with MinGW, which Clang doesn't seem to support very well out of the box. In their defence, they're actively maintaining their distribution, and I think they even ship libc++ for Windows, which the official distribution doesn't do.)
Can anyone tell me how to compile the Clang compiler into LLVM bytecode (that is, self-host Clang)? The reason I want to do this is so that I can take the resulting LLVM bytecode and then use Emscripten to produce a C to Javascript compiler.
You can get clang to output into LLVM bytecode by using the -emit-llvm command-line flag, along with the -c flag. (If you use the -S flag instead of -c, you get a textual representation of the LLVM bytecode.) You don't need to compile clang into LLVM bytecode for that to work.
If you want to try to run clang itself inside a browser, then you will need to compile all of clang into LLVM bytecode, and then link the object files together using llvm-link. Then you'll need to figure out how to give the compiled compiler access to the system header files it needs. I don't know if there is a build option for all that, but I haven't ever seen anything in the ./configure options for that, so I suspect not. But it's possible that it exists.
In my 64-bit Solaris, my gcc by default will generate 32-bit executable file (for generating 64-bit executable file, need add "-m64" compile option) by default. While in my 64-bit Linux, my gcc will generate 64-bit executable file by default. I try to find the cause in gcc website, but unfortunately, there are so many related options (--with-arch, --with-cpu, --with-abi, etc). From the document, I can't see which can determine generating 32-bit or 64-bit executable file.
Could anyone give some advices on this issue?
It depends on how the compiler is installed, which really comes down to the distribution and possibly install options. If there is any doubt and need for certainty, simply include the -m option; it does not hurt to use -m32 when 32-bit is the default, and likewise for -m64 when 64-bit is the default.
When you compile gcc, you use the --target option to specify the appropriate system you want to generate the compiler for. For knowing what all targets GCC supports, you can either check gcc/configure file or oogle through the gcc/config/ folder. Once you generate the compiler, the "compile" command, i.e., gcc source.c -o object.o will always generate object for the default target you have compiled gcc for.
However, you may be able to generate objects for various variations around the specified target. E.g. you may be able to generate both 32-bit and 64-bit binaries for 64-bit systems.
As an example, configure --target=mips64-elf will generate the gcc compiler for the 64-bit mips target. Once the compiler is generated, whenever you type in gcc -c source.c -o object.o, a 64-bit mips object file will be generated.
So if you type in gcc -v on both of your systems in question, you will see how the gcc was configured to begin with, and that should answer your concern.
At the document you referred, please grep for "enable-targets" option.
I've compiled clang to use it as a cross compiler for ARM (by configuring it with ./configure --target=armv7l-unknown-linux-gnueabihf ), but when I try to compile any C code, it tries to use /usr/bin/as. I already have binutils compiled for ARM, and they are in a separate directory. How do I direct clang (or llvm) to use the assembler that I specify?
try passing the --host option to configure which will cause all the cc ar etc utilities to prefix with armv7l-unknown-linux-gnueabihf-
eg:
./configure --host=armv7l-unknown-linux-gnueabihf --build=i686-unknown-linux-gnu
Since you are using configure with hopefully autotools take a look at:
automake Cross compiling
I've always had trouble configuring from the source directory using ./configure and gave up in the end. These days I always configure from a separate directory i.e. ..//configure although I'm told it's recommended to use an absolute path for configure.
Your ARM binutils should be installed in the same prefix you're using for clang and make sure that they're in the path when you configure & build clang - i.e. PATH=/some/prefix/bin:$PATH; /configure --target=armv7l-unknown-linux-gnueabihf. If you're keeping them in separate directories for packaging purposes then make install DESTDIR= should help.
I don't generally build clang but the buildscripts I use for devkitARM might be helpful - http://sourceforge.net/p/devkitpro/buildscripts/ci/c372699fc7b4de90eb044314ce5bed04db640291/tree/
I'm trying to build a C library with a non-native architecture. I'm running OSX 10.6 (which is x86_64) but I need the library compiled for i386. Normally, you can just add the compiler flag: -arch i386. But I'm using Autoconf and it ignores this in the configure file and it also ignores it if I try running: ./configure CC="gcc -arch i386".
I know its building x86_64 object files because I've looked at the header using otool. The real kicker is that when autoconf writes out the configuration summary, it lists -arch i386 in the cc flags. What's going on here??
specs:
OSX 10.6.2
gcc 4.2.1
autoconf 2.64
make 3.81
Assuming that "CFLAGS='-arch i386' is what you meant when you said "normally, you can just add the compiler flag", my best guess is that the maintainer of the code has done something wrong in the configure.ac and overwritten CFLAGS. Check through the configure.ac (or configure.in if the project is old) and see if they've explicitly assigned to CC or CFLAGS. Also check the Makefile.am for assignments. Chances are something is wrong. What you've done should work.
You want to set it in the CFLAGS environmental variable, autoconf should append it to whatever it decides CFLAGS should be. If you type ./configure --help, you should get a list of all influential environmental variables.