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.
Related
I'm trying to compile and link an assembly file to an executable with NASM and the standard LD linker on my MacBook Air M1. I have no problems with getting the .o file, but if I want to link it with LD, it throws that error:
ld: file not found: elf_i386
Command:
ld -m elf_i386 -s -o hello hello.o
What do I have to change?
Those are options for GNU ld on x86 Linux. (Note the ELF part of the target object-file format, and the i386). MacOS uses the MachO object-file format, not ELF, and apparently their ld takes different options.
Also, MacOS hasn't supported 32-bit x86 for a few versions now, so an M1 mac with an AArch64 CPU definitely can't run 32-bit x86 executables natively.
So get an emulator for a 32-bit Linux environment if you want to follow a tutorial for that environment, or find a tutorial for AArch64 MacOS. Or possibly x86-64 MacOS which should still work transparently thanks to Rosetta, but make sure single-step debugging actually works. That's an essential part of a development environment for learning asm.
Assembly language is not portable at all, you need a tutorial for the OS, CPU-architecture, and mode (32-bit vs. 64-bit) that you're going to built in. Don't waste your time trying to port a tutorial at the same time you're learning the basics it's trying to teach. You'd have to already know both systems to know which parts of the code and build commands need to change.
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)
I have downloaded Bellhop, which is an underwater acoustic simulator written in Fortran. It can be found here with the Makefile.
Question 1: I would like to know if it is possible to compile Fortran code, including everything needed, so a user without gfortran installed, can run it.
I have read here the following:
static linking
This section does not apply to Windows users, except for Cygwin users with gcc4-4.3.2-2 or later.
gfortran is composed of two main parts: the compiler, which creates the executable program from your code, and the library, which is used when you run your program afterwards. That explains why, if gfortran is installed in a non-standard directory, it may compile your code fine but the executable may fail with an error message like library not found. One way to avoid this (more ideas can be found on the binaries page) is to use the so-called "static linking", available with option -static gfortran then put the library code inside the program created, thus enabling it to run without the library present (like, on a computer where gfortran is not installed). Complete example is:
gfortran -static myfile.f -o program.exe
Reading this, I suppose that it is possible to do what I'm asking but I'm not very familiarized with fortran and makefiles. I don't understand this:
put the library code inside the program created
Question 2: How can I put the library code inside the program? Where can I find the library? What does "inside the program" means?
I'm running OSX 10.9.4 and gfortran
I solved my problem about compiling Fortran code with gfortran using static libraries.
As #M.S.B. said, using static-libgfortran worked for me under MacOS.
If somebody is having issues with linking the libquadmath.0.dylb library, remove libquadmath.0.dylib and libquadmath.dylib from /usr/local/gfortran/lib/
This doest the trick. Further information can be found here
I think the meaning of the bold part is actually
gfortran then puts the library code inside the
program created
That means using -static should be enough, there is no additional step. Just be advised you will need a static version of all the libraries that you link with.
I know this is very old tracker, but maybe somebody will be still interested in the solution that works.
Let's say we have code:
! fort_sample.f90
program main
write (*,*) 'Hello'
stop
end
First, compile the stuff:
gfortran -c -o fort_sample.o fort_sample.f90
Then, link stuff
ld -o ./fort_sample -no_compact_unwind \
-arch x86_64 -macosx_version_min 10.12.0 \
-lSystem \
/usr/local/gfortran/lib/libgfortran.a \
/usr/local/gfortran/lib/libquadmath.a \
/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0/libgcc.a \
fort_sample.o
You can execute it
./fort_sample
Hello
You can notice that quadmath is no longer there
> otool -L fort_sample
fort_sample:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.51.1)
I guess this is what you were looking for in a first place. No removing dylibs, no symbolic links, etc.
The current version of the option is -static-libgfortran. This means that the Fortran specific libraries of gfortran will be included into the executable. These are libraries are automatically found for a good installation of gfortran. This should produce an executable that should run on other computers with the same OS, even if that computer doesn't have gfortran installed. This option likely doesn't statically link all libraries, so there is some risk that some other shared library used on your computer won't be available on the other computer.
Is it possible to use the stock (non-apple) version of g++ on Mac OSX 10.7? I want to be able to use the stock g++ without running a virtual linux box on my mac. The reason I want to do this is because apple's version of g++ doesn't warn you when there are unused variables and etc. I'm doing some assessed C++ problems in my numerical methods course and I want to make sure I'm not making any mistakes.
It was suggested I make a symbolic link to a linux version of g++ for compiling the code for the assessments. How do I go about doing that?
Thanks
A linux version of the compiler will not work on what is (essentially) a bsd port.
Are you sure that the current version of g++ cannot warn on the conditions you expect?
Finally, if #2 is true, there is nothing stopping you from getting another version of g++ (compiled for MacOSX) that doesn't have this issue.
A binary for g++ for Linux won't run on MacOSX.
You could compile GCC from its source code; use the latest release i.e. 4.6.2. But that requires some work. Be sure to follow the installation instructions, in particular care about dependencies (like PPL & Cloog) and configure (appropriately) and compile in a build tree outside of the source tree.
I downloaded and installed (I think) gtk on the Mac OSX (Lion). Compilation of test program went fine after getting all the -I's correct. Now the link is failing. A grep for the missing entrypoints
_gtk_init
_gtk_window_new
... 11 more
found them in
/Users/ccpalmer/gtk/inst/lib/libgtk-quartz-2.0.0.dylib
/Users/ccpalmer/gtk/inst/lib/libgtk-quartz-2.0.dylib
Being less familiar with OSX's underlying Unix, I'm not sure how to get thru the link step. I must admit, I've never encountered a "dylib" before.
Are there any OSX dev smarties out there who might shed some light on my mystery?
Charles
As moshbear commented above, dylib files are how shared libraries are packaged on Mac OS X. To use such a shared library, you need to pass two switches to your compiler, -L and -l. The first adds the directory containing your dylib to the linker's library search path, and the second specifies the library to link against. Something like this, for a fictional libfoo.dylib that lives in /usr/mylibs:
clang code.c -L/usr/mylibs -lfoo