I have an open source micromouse robot project. For easier compilation, I use containers (both Podman and Docker should be fine):
make image
make libopencm3
make
This works just fine and generates a main.elf file about 874 kB in size. But that is as long as I fix the arm-none-eabi-gcc-cs to 7.4.0 in the Dockerfile.
If I remove the specific version or set it to 9.2.0, then I get the following error:
$ make
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: main.elf section `.text' will not fit in region `rom'
/usr/lib/gcc/arm-none-eabi/9.2.0/../../../../arm-none-eabi/bin/ld: region `rom' overflowed by 5288 bytes
collect2: error: ld returned 1 exit status
make: *** [opencm3/libopencm3.rules.mk:204: main.elf] Error 1
What could have changed between those versions?
If I add this line to my Makefile:
LDFLAGS += -specs=nano.specs
Then it compiles just fine with version 9.2.0 and generates a main.elf file about 885 kB in size. But I wonder if the performance would be the same (or equivalent) as before.
Update
I am expecting some performance differences, of course, just like I was expecting some differences in the binary size. But I was wondering if I could expect a higher than 20% difference in performance (specially if it could be now 20% slower).
The new binary is less than 2% bigger, and I would consider this to be "the same" as before. :-D
I do perfectly understand you want to use the latest and greatest toolchain from your prefered, mainstream Linux distribution, but this is not always going well.
In my humble opinion, you should:
stick to Linaro or ARM gcc toolchains,
in the case of your specific cortex-m related project, stick to a gcc toolchain more specifically targeting the cortex-m, i.e. the so called 'GNU Arm Embedded Toolchain'.
Some remarks:
There are probably excellent reasons why ARM itself is providing two specifics toolchains for the two profiles,
Latest GCC toolchain version available from Linaro is 7.4.1, but if they used to point to it by default on this page, they now pointing to version 7.2.1, which may (or not) ring a bell regarding 7.4.1 - there are no official 9.2 versions available yet.
Latest GCC toolchain available from ARM is 8.3.1 for cortex-m, and 8.3 for cortex-a - there are no official 9.2 versions available yet.
Back to your specific issue now: I was able to compile your project using the following steps:
wget "https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2019q3/RC1.1/gcc-arm-none-eabi-8-2019-q3-update-linux.tar.bz2?revision=c34d758a-be0c-476e-a2de-af8c6e16a8a2?product=GNU%20Arm%20Embedded%20Toolchain,64-bit,,Linux,8-2019-q3-update" -O gcc-arm-none-eabi-8-2019-q3-update-linux.tar.bz2
mkdir -p /opt/arm
tar jxf gcc-arm-none-eabi-8-2019-q3-update-linux.tar.bz2 -C /opt/arm
export PATH=/opt/arm/gcc-arm-none-eabi-8-2019-q3-update/bin:$PATH
Command which arm-none-eabi-gcc should display /opt/arm/gcc-arm-none-eabi-8-2019-q3-update/bin/arm-none-eabi-gcc.
git clone --recurse-submodules https://github.com/Bulebots/bulebule.git
cd bulebule
scripts/setup_libopencm3.sh
make -s -C src/
Command arm-none-eabi-size ./src/main.elf should display:
text data bss dec hex filename
55152 3336 7100 65588 10034 ./src/main.elf
Please note that there is a Docker file for the latest GCC toolchain from ARM targeting the cortex-m profile here. You may want to use it in your own Docker file and remove those two lines:
arm-none-eabi-gcc-cs-7.4.0 \
arm-none-eabi-newlib-3.1.0-2.fc30 \
I hope this helps.
Related
As part of trying to build a gcc 8.2 cross-compiler (targeting ia64-hp-hpux11.31), I'm running into problems building binutils 2.31.1. The build actually seems to complete just fine. I end with a bunch of binaries (ar, objdump, strings, etc.), but some important ones like as and ld are missing. I think I configured binutils properly, explicitely enabling ld and disabling gold: ../binutils-2.31.1/configure --target=ia64-hp-hpux11.31 --enable-ld=yes --enable-gold=no.
I scanned through the stdout + stderr output of the entire build process, but didn't find any hints. The only suspicous thing is that configure outputs: checking whether we are cross compiling... no. Shouldn't that say yes, since I'm building for cross compilation? If my understanding of how --build, --host and --target work is correct, shouldn't that imply cross compilation?
I should note this is my first time trying to build a cross-compiler. I should also note that my Linux "machine" is Ubuntu 16.04.2 LTS under the Windows Subsystem for Linux, perhaps this has something to do with it.
My config.log
See the configure script at line 3744:
ia64*-**-hpux*)
# No ld support yet.
noconfigdirs="$noconfigdirs gdb libgui itcl ld"
;;
That causes the ld directory to be skipped during the build.
You should have an assembler though, built as gas/as-new (after make install that will get installed as ia64-hp-hpux11.31-as).
I'm trying to follow this blog but on Windows and with the latest Rust. It seems to me that the correct way of doing things like this is changing very frequently with Rust, so I'm hoping for an up-to-date Windows adaptation.
What I've tried so far:
I installed gcc-arm-embedded.
I had unverified partial success manually cross-compiling libcore, but then I switched to use the recommended xargo, the functionality of which (I read) is on its way to being included in Cargo eventually. While I don't understand any of it very well, I'm hoping to get to the part where I can write/run the code and then maybe I can back into understanding the compilation better.
With japaric's awesome help, I was able to get the "aarch64" targeted build working to generate the .o file (as of this particular commit).
And this part seems to verify:
$ file target/aarch64-raspi3-none-elf/release/deps/rust_rasp-ed0c2377e0a7df81.o
target/aarch64-raspi3-none-elf/release/deps/rust_rasp-ed0c2377e0a7df81.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped
When I try to use the GNU Arm Embedded Toolchain linker, I get:
$ arm-none-eabi-gcc -O0 -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s -nostartfiles target/aarch64-raspi3-none-elf/release/deps/rust_rasp-ed0c2377e0a7df81.o -o kernel.elf target/aarch64-raspi3-none-elf/release/deps/rust_rasp-ed0c2377e0a7df81.o: file not recognized: File format not recognized
collect2.exe: error: ld returned 1 exit status
And #rust IRC chatroom helpfuls told me that rpi3 is aarch64, not arm, so I need to find an aarch64 linker ...
I think it's working! Things I learned:
xargo is good
rpi3 is different enough from rpi2 to cause my problems in tool selection
xargo doesn't care what toolchain rustup defaults to because I'm not asking it to link for me and it does its own toolchain selection
I needed to target aarch64, not arm. For this I used the linaro aarch64 mingw32 download, unpacked, added its bin folder to my PATH. Then the aarch64 tools were easy to adapt from the blog.
For people who want to do this themselves, see https://github.com/JasonKleban/rust-rasp . Not so complicated!
I aim to blink the onboard activity led as confirmation that we do really have control, but looks like that will be kinda complicated on the rpi3 (see my readme, if still applicable)
Building GCC (latest revision) on OS X 10.11.1 here, using the command line:
../gccx/configure --with-gmp="/opt/local" --with-mpfr="/opt/local" \
--with-mpc="/opt/local" --with-libiconv-prefix="/opt/local" --with-pkgversion="GCCX" \
--program-transform-name='s/^gcc$/gccx/; s/^g++$/g++x/' --enable-languages=c
Followed build instructions exactly, and getting this error:
g++ -std=gnu++98 -g -DIN_GCC -fno-strict-aliasing
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -Wl,-no_pie -o build/genmatch \
build/genmatch.o ../build-x86_64-apple-darwin15.0.0/libcpp/libcpp.a build/errors.o build/vec.o build/hash-table.o ../build-x86_64-apple-darwin15.0.0/libiberty/libiberty.a Undefined symbols for architecture x86_64: "_iconv", referenced from:
convert_using_iconv(void*, unsigned char const*, unsigned long, _cpp_strbuf*) in libcpp.a(charset.o)
(maybe you meant: __Z14cpp_init_iconvP10cpp_reader, __cpp_destroy_iconv ) "_iconv_close", referenced from:
__cpp_destroy_iconv in libcpp.a(charset.o)
__cpp_convert_input in libcpp.a(charset.o) "_iconv_open", referenced from:
init_iconv_desc(cpp_reader*, char const*, char const*) in libcpp.a(charset.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [build/genmatch] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make:
*** [all] Error 2
(A complete log is available at https://gist.github.com/3cb5d044533e657f4add.)
After investigating gcc/Makefile, it seems that the BUILD_CPPLIB variable does not include $(LIBICONV), since it is in a stage1 bootstrap at the time of the error. The relevant section is preceded by
# For stage1 and when cross-compiling use the build libcpp which is
# built with NLS disabled. For stage2+ use the host library and
# its dependencies.
Yet clearly the stage1 build of build/genmatch is referencing libcpp, which uses symbols from libiconv. So something is amiss here.
How can I fix it?
General discussion
Building GCC on Mac OS X is an occasionally fraught process. I've had various issues with various versions of GCC and various versions of Mac OS X over the years. You can see an earlier explanation of what I did in Install GCC on Mac OS X — that was for building GCC 4.8.x on Mavericks 10.9.x (or possibly Mountain Lion 10.8.x); it also reports success building GCC 4.9.0 on Mavericks 10.9.x, but failure to do so on Yosemite 10.10.x.
This is an updated recipe for building GCC 5.2.0 on Mac OS X 10.11.1 El Capitan.
It starts off using XCode 7.1.1 — I don't know which other versions of XCode are OK.
Note that El Capitan has a feature SIP (System Integrity Protection) that was not in Yosemite and earlier versions. This means you cannot create arbitrary directories under /usr any more. I used to install in /usr/gcc/vX.Y.Z; that is no longer permitted in El Capitan. One major change, therefore, is that I now install in /opt/gcc/v.X.Y.Z.
I've found that having DYLD_LIBRARY_PATH set is problematic — especially on El Capitan. In a major break from the past, I'm now not setting that at all. Note that the scripts unset it. Note too that the script explicitly sets the phase 1 compilers CC and CXX to /usr/bin/clang and /usr/bin/clang++ respectively (the XCode compilers). The current versions of GCC require a capable C++ compiler instead of (or as well as) a C compiler.
I have occasionally had problems with libiconv, but at the moment I've evaded them by not having my own version installed. Similarly, I've occasionally had problems with some awk scripts in the GCC source. I had to hack it/them to get it to work OK. However, with release copy of GCC 5.2.0 source, I seem to be able to build directly out of the box.
If you've only got a single disk partition, this next point isn't crucial. If you have multiple disks, either make sure the target directory does not exist or ensure that its name is exactly what you want. On the machines at work (not Macs but Linux machines, etc), I still use /usr/gcc/vX.Y.Z as the 'official' install location, but the software ends up in some arbitrary file system where there's enough space, such as /work4/gcc, and eventually there is a symlink such that /usr/gcc/vX.Y.Z gets to /work4/gcc/vX.Y.Z. However, it is crucial that /work4/gcc/vX.Y.Z does not exist while GCC is being compiled because it will resolve the name via realpath() or its equivalent and embed /work4/gcc/vX.Y.Z into the binaries, rather than the neutral name /usr/gcc/vX.Y.Z. This limits the portability of the installation; any other machine that it is moved to has to have a directory /work4/gcc/vX.Y.Z, even though you asked to install it in /usr/gcc/vX.Y.Z.
Compiling GCC 5.2.0 on Mac OS X 10.11.1 with XCode 7.1.1
I had to work with down-versions of both GMP (5.1.3 instead of 6.0.0a) and ISL (0.14 instead of 0.15). The builds for the later versions both caused me trouble.
Note that I put the library code for GMP, MPC, MPFR, ISL and Cloog (see the GCC pre-requisites) in the GCC source directory so that GCC builds its own versions of these libraries. I've found that its the simplest way to ensure that GCC locates these libraries correctly.
Target directory: /opt/gcc/v5.2.0
Build time was about 2h 15m on a 17" MacBook Pro (early 2011) running Intel Core i7 at 2.3 GHz, with 16 GiB 1333 MHz DDR3 main memory, and a 750 GB 5400 rpm hard disk drive. The source occupies about 850 MiB; the build tree ends up at about 4.6 GiB — you need plenty of disk space. The installed code ends up at about 420 MiB.
Script used — extract-gcc-5.2.0.sh
#!/bin/bash
unset DYLD_LIBRARY_PATH
TAR=tar
VER_NUM=5.2.0
GCC_VER=gcc-${VER_NUM}
TGT_BASE=/opt/gcc
TGT_DIR=${TGT_BASE}/v${VER_NUM}
CC=/usr/bin/clang
CXX=/usr/bin/clang++
extract() {
echo "Extract $1"
$TAR -xf $1
}
if [ ! -d "$GCC_VER" ]
then extract ${GCC_VER}.tar.bz2 || exit 1
fi
(
cd ${GCC_VER} || exit
nbncl <<EOF |
cloog 0.18.1 tar.gz
gmp 5.1.3 tar.xz
# gmp 6.0.0 tar.lz
isl 0.14 tar.bz2
# isl 0.15 tar.bz2
mpc 1.0.3 tar.gz
mpfr 3.1.3 tar.xz
EOF
while read file vrsn extn
do
tarfile="../$file-$vrsn.$extn"
if [ ! -f "$tarfile" ]
then echo "Cannot find $tarfile" >&2; exit 1;
fi
if [ ! -d "$file-$vrsn" ]
then
(
set -x
extract "$tarfile" &&
ln -s "$file-$vrsn" "$file"
) || exit 1
fi
done
)
if [ $? = 0 ]
then
mkdir ${GCC_VER}-obj
cd ${GCC_VER}-obj
../${GCC_VER}/configure --prefix="${TGT_DIR}" \
CC="${CC}" \
CXX="${CXX}"
make -j8 bootstrap
fi
Script nbncl — non-blank, non-comment lines
#!/usr/bin/env perl
#
# Non-blank, non-comment lines only
use warnings;
use strict;
while (<>)
{
chomp;
s/\s+$//;
s/\s*#.*$//;
print "$_\n" unless /^$/;
}
First, see Jonathan Leffler's very complete answer. I have a few more suggestions here.
The gcc configuration and build process needs to find your system's native header files and C run-time libraries. Newer, clang-based versions of Xcode hide these pretty deeply, and older versions of gcc don't seem to know how to find them. To get gcc 4.6 to build at all, I had to create these symlinks:
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include /usr
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/dylib1.10.5.o /usr/local/lib
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o /usr/local/lib
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/bundle1.o /usr/local/lib
Your mileage will likely vary slightly: note that those pathnames underneath /Applications/Xcode.app/Contents have various version numbers baked in to them, which are likely to be different on your system.
(If, as Jonathan describes, the newest versions of MacOS don't allow you to put anything in /usr, you might have to create the /usr/include symlink in /usr/local/include, instead, and I suspect that would work, too.)
Also, this is mentioned elsewhere, but it's an unusual requirement, and easy to overlook: do not try to build gcc within its own source tree. Always create a build directory which is a parallel sibling, not a child underneath, of the directory into which you've extracted the gcc sources. That is, do not do this:
tar xzf gcc-x.y.z.tar.bz2
cd gcc-x.y.z # WRONG
mkdir build
cd build
../configure # WRONG
make
Instead, do this:
tar xzf gcc-x.y.z.tar.bz2
mkdir build
cd build
../gcc-x.y.z/configure
make
This is counterintuitive, I know, and it's not the way a lot of other packages work, but it definitely does work for gcc, and it's the recommended way to do it.
Another point: if you discover that your build is failing because you configured it improperly, such that you have to rerun configure with different options, it's safer to delete your entire build directory and start from scratch. The configure and build system sometimes, but it seems not 100% reliably, detects what might need rebuilding in that case. (Deleting and starting over is frustrating, I agree, but again, it can really save time in the long run.)
Finally, if you're trying to build a cross-compiler, see some additional suggestions and commentary at install gcc 4.6.1 on OS X 10.11 .
For what it's worth, MacPorts has ports for all recent versions that should be sufficiently easy for everyone (who knows how to code!) to read who doesn't want to install MacPorts but prefers to install the various dependencies mentioned here some other way.
A slightly tweaked personal version of the port for gcc 6.3.0:
https://github.com/RJVB/macstrop/blob/master/lang/gcc6/Portfile
The reason I mention that one (and post this answer) is that this tweaked version shows how to get G++ to use libc++ instead of libstdc++. That's a prerogative for being able to use G++ as a real replacement for clang++ that can be used without worrying about C++ runtime incompatibilities. This patch has allowed me to use g++ to build KDE (KF5) code and run it against Qt5 and the KF5 frameworks built with various clang compiler versions. (The patch files are in .../gcc6/files .)
Some explanation that might help interpreting the Tcl code of the linked file:
Ignore anything that's specific to $subport == "libgcc".
As you can see, you need gmp, mpc, mpfr and isl (the other dependencies should be of no interest if you're installing on your own).
The configure.args expressions construct the argument list to the configure script, configure.env and build.env add environmental variables for the configure and build (make) commands. Many of the configure options here are to ensure that the build uses dependencies from MacPorts but they'd probably be required too if you want or have to use a location not controlled by SIP and that isn't included in standard PATH definitions (the compiler still ought to work when invoked through a process that resets the path).
The configure and build are done in a build directory that sits next to the source directory, which makes it very easy to start over or just clean up without throwing away the sources.
After the configure step the build is done with "make bootstrap-lean" - which still creates about 1.7Gb of data in that build directory.
I have code which produces executables larger than 2GB (it's generated code).
On x64 with gcc 4.3.2 I get errors like:
crtstuff.c:(.text+0x20): relocation truncated to fit:
R_X86_64_32S against `.dtors'
So I understand i need the -mcmodel=large option. However that doesn't do anything or solve the problem on my system.
I am sure I read somewhere, that it was only supported from a particular version of gcc, and the option was ignored on versions before that. I would tell my operations team to install that version of gcc if only I knew what it was. But I just can't find any evidence right now to tell me if that hypothesis is true, and if so in which version the feature was introduced.
For example
(1) Here it is stated that the option doesn't do anything. The book in question claims to cover "GCC 4.x". The book came out 2006.
(2) Here a compiler bug is being reported against the option, therefore I conclude in that version it must do at least something. That seems to be gcc 4.6.1.
So although I can no longer find evidence of exactly in which version the feature was implemented, at least there is evidence that this has changed over time.
I have tried looking through the changelogs for all the various GCC 4.x versions to no avail (and normally they are pretty good so the lack of information there almost implies that I am wrong and nothing has changed between versions.)
Edit: This seems to imply that perhaps it did work, but I need to "recompile crtstuff.c", but I don't really know where I find that file or how I do that.
I believe 4.4 is the version that added support for this feature. I demonstrate below that 4.1 doesn't work while 4.4 does, on something that needs a large data block (rather than code). I'm not sure about 4.2 and 4.3, but both your example and my memory suggest 4.3 didn't have working support for this. My example should let you validate whether a particular installation works or not though, on an otherwise easy to compile bit of code.
As background, I maintain a program that's a fork of the stream benchmark, modified specially to use 64 bit structures for testing larger systems. I was plagued with these "relocation truncated to fit" errors until I started using "-mcmodel=large", and my fork won't compile/run unless that really does work. The oldest version of gcc I've definitely found my program compatible with is the 4.4.5 that ships with Debian Squeeze.
Here's a complete test case showing my fork of stream compiling and using >4GB of RAM with the large model, after failing to do so without the option:
$ gcc --version
gcc (Debian 4.4.5-8) 4.4.5
...
$ git clone https://github.com/gregs1104/stream-scaling.git
$ cd stream-scaling
$ gcc -O3 -DN=200000000 -fopenmp stream.c -o stream
/tmp/cca8rR1I.o: In function `checkSTREAMresults':
stream.c:(.text+0x34): relocation truncated to fit: R_X86_64_32S against `.bss'
...
stream.c:(.text+0x6ab): additional relocation overflows omitted from the output
collect2: ld returned 1 exit status
$ gcc -O3 -DN=200000000 -fopenmp stream.c -o stream -mcmodel=large
$ ./stream
-------------------------------------------------------------
STREAM version $Revision: 5.9 $
-------------------------------------------------------------
This system uses 8 bytes per DOUBLE PRECISION word.
-------------------------------------------------------------
Array size = 200000000, Offset = 0
Total memory required = 4577.6 MB.
...
And here's what happens on a version of gcc that doesn't have the large model, one running RedHat 5 derived software (CentOS 5.8):
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52)
...
$ gcc -O3 -DN=200000000 -fopenmp stream.c -o stream -mcmodel=large
stream.c:1: sorry, unimplemented: code model ‘large’ not supported yet
So on older versions of gcc, it should throw that error out, not just ignore the option.
crtstuff is a library coming with gcc. The bug report you linked to on the gcc mailing list was from someone trying to build their own gcc for a RedHat 5 system, which as you can see in this last example ships with gcc 4.1. They rebuilt part of gcc with the large model, but it was still linking against the original, 4.1 built crtstuff library. You shouldn't run into that problem if you're using a properly packaged gcc, which is why it wasn't considered a real bug by the gcc developers. I think you just need gcc 4.4 or later.
Has anyone successfully compiled TCC on OS X?
From what I know it should be possible but when I run make I get the following error:
$ make
gcc -o tcc tcc.c -DTCC_TARGET_I386 -O2 -g -Wall -fno-strict-aliasing -mpreferred-stack- boundary=2 -march=i386 -falign-functions=0 -Wno-pointer-sign -Wno-sign-compare -D_FORTIFY_SOURCE=0 -lm -ldl
tcc.c:1: error: CPU you selected does not support x86-64 instruction set
tcc.c:1: error: CPU you selected does not support x86-64 instruction set
tcc.c:1: error: -mpreferred-stack-boundary=2 is not between 4 and 12
make: *** [tcc] Error 1
./configure runs fine and gives the following output:
$ ./configure
Binary directory /usr/local/bin
TinyCC directory /usr/local/lib/tcc
Library directory /usr/local/lib
Include directory /usr/local/include
Manual directory /usr/local/man
Doc directory /usr/local/share/doc/tcc
Target root prefix
Source path /Users/aaron/Downloads/tcc-0.9.25
C compiler gcc
CPU x86
Big Endian no
gprof enabled no
cross compilers no
use libgcc no
Creating config.mak and config.h
I'm pretty sure the issue is something simple, but I haven't compiled enough programs on OS X to be aware of the pratfalls...
The primary purpose for installing TCC was to get libtcc so I could start experimenting with dynamic code generation from Ruby (in case that makes a difference :-p)
Thanks!
I have just spent some serious time trying to make tcc run on osx. I have included several fixes, including the one from the answer above, and now they are all in the development repository at http://repo.or.cz/w/tinycc.git. Building, some tests and all examples should work.
I am not sure if you are aware, but http://bellard.org/tcc/ site that belongs to Fabrice Bellard who started this project, is not being updated very regularly. Mostly because there are not many 'official' tcc releases. tcc is one of those projects that mostly lives off of live sources and updates. So if you want to give this another try, please go to http://repo.or.cz/w/tinycc.git and get the 'mob' branch (not 'master'). Please see http://repo.or.cz/w/tinycc.git for details, and do join the mailing list to get involved.
I'll consolidate my comments now.
There seem to be several issues.
There has been a change in the naming scheme for the x86 register access as of Mac OS 10.5. See Access EIP and EBP via ucontext on OS X. This will require hacking the source until the maintainer can be convinced to support Mac OS X.
The executable formats supported by tcc do not overlap with those that Mac OS X will run natively. However, XBinary may address this. (I didn't find either a fink package or a MacPorts package, however and don't have it installed yet. Not sure that I will--this is deep magic, and could in theory do very bad things indeed.) Ah... this was already on SO too: Possibility of loading/executing ELF files on OSX.
The errors can be fixed by edit configure script of TCC package (ver 0.9.25).
In the configure script, line 36 says
cpu=uname -m
If you run uname -m in the console of Mac OS X, it prints "i386" even if it is a 64-bit system.
A solution is to comment off this line, and replace it with cpu=x86_64,
Then some compiling errors will show up because of the register naming conventions in Mac OS X, as mentioned by dmckee in this thread.
My fix is to add a few lines to libtcc.c around line 1512.
Finally it will look like
#ifdef __DARWIN_UNIX03
*paddr = uc->uc_mcontext->__ss.__rip;
#else
*paddr = uc->uc_mcontext.gregs[REG_RIP];
#endif
return 0;
} else {
#ifdef __DARWIN_UNIX03
fp = uc->uc_mcontext->__ss.__rbp;
#else
fp = uc->uc_mcontext.gregs[REG_RBP];
#endif
It compiles then.