- use {B} to substitute tcc_lih_path (instead of \b)
- expand CONFIG_TCC_CRTPREFIX in CONFIG_TCC_LIBPATHS
which fixes duplicate CONFIG_SYSROOT.
- put default CONFIG_SYSROOT ("") into tcc.h
- remove hack from commit db6fcce78f
because $(tccdir)/include is already in sysincludes
- configure: error out for unrecognized options.
- win32/build-tcc.bat: put libtcc into base dir where it will
find lib/include automatically, and build libtcc_test example.
--sysincludepaths=.. specify system include paths, colon separated"
Sets CONFIG_TCC_SYSINCLUDEPATHS
--libpaths=... specify system library paths, colon separated"
Sets CONFIG_TCC_LIBPATHS
--crtprefix=... specify location of crt?.o"
Sets CONFIG_TCC_CRTPREFIX
--elfinterp=... specify elf interpreter"
Sets CONFIG_TCC_ELFINTERP
Also the CONFIG_TCC_XXX were renamed to make them look
more consistent.
Also move the elf_interp definitions to tcc.h.
This allows passing colon separated paths to
tcc_add_library_path
tcc_add_sysinclude_path
tcc_add_include_path
Also there are new configure variables
CONFIG_TCC_LIBPATH
CONFIG_TCC_SYSINCLUDE_PATHS
which define the lib/sysinclude paths all in one and can
be overridden from configure/make
For TCC_TARGET_PE semicolons (;) are used as separators
Also, \b in the path string is replaced by s->tcc_lib_path
(CONFIG_TCCDIR rsp. -B option)
This was already possible using
make NOTALLINONE=1
and is now the default.
To build as previously from one big source, use
make ONE_SOURCE=1
Cross compilers are still build from one source because using
separate objects requires separate build directories one per
platform which currently is not (yet) supported by the makefile.
We could probably use gnu-makeish target variables like
$(I386_CROSS): OUTDIR=build/i386
$(X64_CROSS): OUTDIR=build/x86-64
and so on ...
Also NEED_FLOAT_TYPES for arm-gen is removed. It was about
variables that are referenced from outside (libtcc, tccgen).
We could declare them in tcc.h (as with reg_classes) or have
them twice in arm-gen.c. I chose option 2.
Use @BINDIR@ in shebang of examples to put the right path on the target
system. That is, use #!/usr/local/bin/tcc if tcc is installed in /usr/local/bin
and #!/usr/bin/tcc if tcc is installed in /usr/bin/tcc.
* Set CFLAGS entirely in configure if not already set.
* Compile bcheck.c with the same flags as the other source files
* Don't strip binaries by default (GB are cheap now) but provide a
--strip-binaries option in configure script.
ARM architecture doesn't have any libtcc1 implementation but tcc load
libtcc1.a in all case. This patch add a conditional preprocessor
instruction to load libtcc1.a only when there is an implementation for
the target architecture.
Summary of what was changed or added so far:
These won't work on Win32
* --disable-static option builds libtcca.so.1.0 and associated simlinks.
This replaces libtcca.a, which is a static library with a dynamic one.
* --with-selinux option uses mmap to enable tcc -run to work with Selinux.
* attempt to build tcc1.def on i386 / x86_64 when --enable-cross is used.
If successful, this gets around the "_start not found" or "_winstart not
found" messages when i386-win32-tcc is run on these systems. I say "if"
because it gave me fits of trouble on my system and not all others have
been tested yet. tcc1.def is not a real .def file by the way, but it works,
so it's kind of a dancing bear at this point. We're not concerned that
it's getting the steps wrong. We're just happy it's not eating us for lunch.
* additional make target for lib/tcc1.def on non-win32 builds
tcc1.def was formerly lib/libtcc1.a but has bee made into its
own Makefile target, tcc1.def
* use mv instead of cp on config.h
this fixes a mistake I made which caused Makefile to rebuild
all targets every time
* make links from libtcc.so.1.0 to libtcc.so.1 and libtcc.so
merge more changes from Fedora spec file into Makefile
I did a lot of reading on Makefiles. It should be a lot less hacked now that I got rid of my temporary cross-build script. I had to build i386-win32-tcc as 32 bit in order to use it to build the windows version of libtcc1.a and move that into lib directory. Still testing, but it does build windows fib.exe smoothly now and generates shard lib, libtcc.so.1.0 and test links against it.
on x86_64 using --enable-cross. The easiest way to fix this is
to put -m32 in the Makefile.
Committer: Henry Kroll <henry@comptune.com>
Committer: Henry Kroll <henry@comptune.com>
(Because GNU's alloca.h unconditionally #undef's alloca)
Also, remove gcc specific sections in headers. and
instead change tests such that gcc does not use them.
Most change was done in #ifdef TCC_TARGET_X86_64. So, nothing should be broken by this change.
Summary of current status of x86-64 support:
- produces x86-64 object files and executables.
- the x86-64 code generator is based on x86's.
-- for long long integers, we use 64bit registers instead of tcc's generic implementation.
-- for float or double, we use SSE. SSE registers are not utilized well (we only use xmm0 and xmm1).
-- for long double, we use x87 FPU.
- passes make test.
- passes ./libtcc_test.
- can compile tcc.c. The compiled tcc can compile tcc.c, too. (there should be some bugs since the binary size of tcc2 and tcc3 is differ where tcc tcc.c -o tcc2 and tcc2 tcc.c -o tcc3)
- can compile links browser. It seems working.
- not tested well. I tested this work only on my linux box with few programs.
- calling convention of long-double-integer or struct is not exactly the same as GCC's x86-64 ABI.
- implementation of tcc -run is naive (tcc -run tcctest.c works, but tcc -run tcc.c doesn't work). Relocating 64bit addresses seems to be not as simple as 32bit environments.
- shared object support isn't unimplemented
- no bounds checker support
- some builtin functions such as __divdi3 aren't supported
This patch adds a switch --with-libgcc to configure.
When passed it prevents libtcc1.a from being built and links to
/lib/libgcc_s.so.1 instead of PREFIX/lib/tcc/libtcc1.a.
It will work on ARM when using libgcc from GCC >= 4.2.0.
Prior versions don't have the __floatun[sd]i[sdx]f functions.
It won't work on i386 because of two missing symbols emitted when
floats are cast to integers, but users can provide those symbols
(global short constants) in their code if needed.
Daniel
- Builds all four possible ARM targets when cross compiling
- Adds some auto detection to select the target for native ARM builds
The auto detection will select EABI if it finds /lib/ld-linux.so.3.
It will select VFP floating point support when /proc/cpuinfo lists
a VFP or iWMMXt coprocessor. Intel Wireless MMX does not imply VFP,
but it conflicts with FPA, so VFP is the only choice (apart from
yet unsupported soft-float).
Daniel
