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.
Related
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.
I am trying to recompile binutils and GCC as a cross-compiler for m68k architecture. I am following these instructions:
http://darkdust.net/writings/megadrive/crosscompiler
However, the process keeps failing on one part or another. I have tried with binutils 2.16.1 and gcc 3.4.6, binutils 2.15 and gcc 3.4.2 and binutils 2.15 and gcc 3.4.6.
This last attempt fails when running "make" on gcc, after making and installing binutils. It gives the following error:
gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H
-I. -I. -I../../gcc-3.4.2/gcc -I../../gcc-3.4.2/gcc/. -I../../gcc-
3.4.2/gcc/../include \
-DTARGET_MACHINE=\"m68k-coff\" \
-c ../../gcc-3.4.2/gcc/collect2.c -o collect2.o
In file included from /usr/include/fcntl.h:289:0,
from ../../gcc-3.4.2/gcc/system.h:214,
from ../../gcc-3.4.2/gcc/collect2.c:30:
In function ‘open’,
inlined from ‘collect_execute’ at ../../gcc-3.4.2/gcc/collect2.c:1535:20:
/usr/include/x86_64-linux-gnu/bits/fcntl2.h:50:4: error: call to
‘__open_missing_mode’ declared with attribute error: open with O_CREAT or
O_TMPFILE in second argument needs 3 arguments
__open_missing_mode ();
^
Makefile:1364: recipe for target 'collect2.o' failed
make[1]: *** [collect2.o] Error 1
make[1]: Leaving directory '/home/gabriel/src/gcc-build/gcc'
Makefile:23339: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2
I don't expect to fix this error, but does anyone know of a combination of binutils and gcc release that work? Should I be using a certain version of gcc to recompile gcc successfuly?
Thanks for any insight you may have on this!
EDIT:
My linux has GCC 5.4.0 so I just downloaded the 5.4.0 source to try and rebuild that for m68k cross-compiling. I now get the following error when running "make" on the gcc source:
*** Configuration m68k-unkown-coff not supported
What could be the cause of this? Is it because I need an older version of GCC? (the binutils version i'm using definately supports the m68k target). The tutorial I'm using always defines "--target=m68k-coff", should that instead be "--target=m68k-unkown-coff"?
EDIT 2:
So I tried compiling for m68k-elf but now I get this error:
checking for m68k-elf-gcc... /home/gabriel/src/gcc-build/./gcc/xgcc -B/home/gabriel/src/gcc-build/./gcc/ -B/opt/m68k/m68k-elf/bin/ -B/opt/m68k/m68k-elf/lib/ -isystem /opt/m68k/m68k-elf/include -isystem /opt/m68k/m68k-elf/sys-include
checking for suffix of object files... configure: error: in `/home/gabriel/src/gcc-build/m68k-elf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
I ran download_prerequisites before building so it should not be a problem with the MPC library. Any idea how to move on? I need assembler only so I don't mind what the format of the object files is. Thanks!
I used to do pretty much what you are doing right now.
My advice is to use crosstool-ng (http://crosstool-ng.github.io), as it does pretty much everything in an automated manner.
If you are studying m68k assembly, I used to host a modified version of gcc-explorer by Matt Godbolt (https://godbolt.org/). You can find a runnable docker image here (https://hub.docker.com/r/esantoro/acso-explorer/) and some more details here (https://znpy.wordpress.com/2017/05/08/decommisioning-acso-explorer-santoro-tk/)
Hope it helps,
znpy
you can build most versions with a current Linux. To install the prerequisites have a look at https://github.com/bebbo/amiga-gcc
unpack the gcc archive, e.g. to /opt/cross/gcc-6.5.0
create a separate build folder, e.g. /opt/cross/xcc-6.5.0 - never build inside gcc's source folder!
create the prefix folder, that's where binaries are installed to, e.g. /opt/cross/gcc65
ensure that these folders exist and are writable, then
configure from within that build folder using an absolute path for configure
cd /opt/cross/xcc-6.5.0/
/opt/cross/gcc-6.5.0/configure --target=m68k-elf --program-prefix=m68k-elf- --enable-languages=c,c++ --prefix=/opt/cross/gcc65 --disable-libssp --disable-nls --disable-multilib
make all-gcc
make install-gcc
I'm also running the compiler explorer for 68k gccs at https://franke.ms/cex/
I wanted to configure an autotooled project to invoke a non-standard
linker (the gold linker),
using the stock autotools of Linux Mint 16/Ubuntu 13.10
I believed I would achieve this by:
libtoolize-ing the project
Running ./configure LD=/path/to/my/linker ... etc.
However this has been ineffective. libtoolize has been successful. After
a standard ./configure; make I now see that libtool is doing the
linking:
/bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -o helloworld helloworld.o
But passing LD=/path/to/my/linker to configure makes no difference. Experimentally,
I even ran:
./configure LD=/does/not/exist
expecting to provoke an error, but I didn't. The output contains:
checking if the linker (/does/not/exist -m elf_x86_64) is GNU ld... no
checking whether the g++ linker (/does/not/exist -m elf_x86_64) supports shared libraries... yes
And thereafter a make continues to link, successfully, invoking g++ exactly as before.
What is the right way to configure a non-standard linker?
But passing LD=/path/to/my/linker to configure makes no difference
This is because LD is almost never and should almost never be used to link any user-space program. Correct links are performed by using the appropriate compiler driver (gcc, g++, etc) instead.
What is the right way to configure a non-standard linker?
If you have /some/path/ld and you want gcc to use that ld, pass -B/some/path flag to gcc.
It then follows that you likely want:
./configure CC='gcc -B/some/path' CXX='g++ -B/some/path' ...
I landed on this via a Google search, though my scenario is a bit different from yours; there was no libtool involved. An old open source program's Makefile was hard-coding ld to create an object file with a symbol from binary data.
This is what I ended up doing to work around the lack of $(LD) being recognized when passed to configure:
https://github.com/turboencabulator/tuxnes/commit/bab2747b175ee7f2fc3d9afb28d69d82db054b5e
Basically I added to configure.ac:
AC_CHECK_TOOL([LD], [ld])
Leaving this answer here for if someone else lands via a google search.
I have a uclibc toolchain that works. I can compile a simple hello.c program statically (arm-linux-gcc hello.c -o hello -static -s) but source packages are automatically compiled dynamically. How can I change the default to static?
You have to edit the makefile of the source packet you are compiling (extra LDFLAG -static, just as you did for the hello.c file). Most of the time source packets are delivered with autoconf. In that case you can probably pass the --enable-static-link flag to configure. See configure --help for the set of possible arguments.
Other note: be careful when cross compiling packages which need other libraries. You do not want to link in your host machine libraries statically.
I am a newbie to libhistory, so I was looking at the sample found with readline library. Compiled it on command prompt using: gcc -o ./a.out /usr/local/share/readline/histexamp.c -lreadline -L/usr/local/lib/It compiles and maintains history.
Then crated a xcode project with the same file and linked against readline library it compiles fine. But when I run , it won't maintain history and crashing while enumeration of history entries. After some trials i found that -isysroot argument is the cause for this problem:-isysroot /Developer/SDKs/MacOSX10.6.sdk The gcc man page says isysroot is like the --sysroot option, but applies only to header files.
Why the same program behaves differently with this option?
-isysroot is used to define the SDK that you build with. If you build with the 10.6 SDK and then try and run on OS X 10.5 then you will probably fail. You should build with whichever SDK corresponds to the minimum required OS for your program (for maximum backward-compatibility).
-isysroot /Developer/SDKs/MacOSX10.6.sdk
the sysroot will overwrite the system path /usr/local etc.
In my opinion, it is a problematic way to use the SDK path by XCode.
It will result in a non-existent path like
/Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/
if you want to search in the user link -L/usr/local/lib/
I don't think it is a good idea at all to change sysroot just in order to use SDK