* Rename tcc_split_path_components
* Move tcc_split_path below memory wrapper section
* Ident tcc_split_path by 4
* Remove prefix and suffix clutter in tcc_split_path
* Don't dereference beyond the end of the search paths string
Add the possibility to search headers in several subdirectories of
/usr/local/include and /usr/include. A possible use case would be for
tcc to search for headers in /usr/local/include/x86_64-linux-gnu,
/usr/local/include, /usr/include/x86_64-linux-gnu and /usr/include in
turn.
By default, tcc search libraries in /lib and /usr/local/lib while crt*.o
files are searched in /usr/lib and ld.so is searched in /lib.
Unfortunetely the path are hardcoded in source code. This patch allow
tcc to look in an other directory and also to look in extra directories.
It's then possible to make tcc search libraries in /lib/x86_64-linux-gnu
and /usr/local/lib/x86_64-linux-gnu while crt*.o files are searched in
/usr/lib/x86_64-linux-gnu and ld.so is searched in
/lib/x86_64-linux-gnu.
To make this the default, enable this line in libtcc.c:tcc_new:
#if defined(TCC_TARGET_PE) && 0
s->leading_underscore = 1;
and then recompile tcc and also libtcc1.a
- Fix function assembly label mechanism introduced in commit
9b09fc376e to only accept alternative
name for function declaration.
- merge the code with the one introduced in commit
264a103610.
- Don't memorize token for asm label but directly the asm label.
Add support for __REDIRECT_NTH as eglibc makes use of this macro to
redirect long double functions to long functions on arch not supporting
long double.
Add support for asm labels for functions, that is the ability to rename
a function at assembly level with __asm__ ("newname") appended in
function declaration.
This affectes where `tcc -E -MD file.c` will place generated dependency
information -- previously, for `tcc -E` output_default was a.out, and so
deps were put into a.d .
Avoid this behaviour, by treating `tcc -E` as `tcc -c` with respect to
output_default computation.
This will not hurt anything else (preprocessor outputs to either stdout,
or to explicitely given (-o <file>) destination, so no default filename
is used here), and on the other hand `tcc -E -MD file.c` now puts
dependencies into file.d (the same behaviour as for gcc -E).
v2:
- restructured condition a bit to make it more clear
Since for upcoming -MD support default _compile_ output file be needed
even when preprocesssing (tcc -E), let's move this code out of one
particular condition block into a common function, so that we could use
it in deps generation code too.
v2:
- As suggested by grischka, moved into libtcc function instead of always
computing near start of main()
- There is a FIXME about how to return result - I don't want to bother
callers with allocating temp buffers, not I think it will be a good
idea to hook default_target to TCCState. Clearly, I'm to used to
things like std::string and python's str...
files[0], and reloc_outpu will be needed for (upcoming in the next
patch) "compute default outfile name" refactored into libtcc function.
Also, since for symmetry and from libification point of view, it makes
some sense to also put all information about what was given as input to
compilation into TCCState, let's not only put files[0], but all
files and all libraries given explicitely by user.
One point: I've used bitfield for reloc_output & trimmed down
output_type to 8 bits so that TCCState stays the same in size, and also
access to output_type is (hopefully) is not slower.
By the way -- as of today, sizeof(TCCState) on i686-pc-linux-gnu is 2884
bytes...
gcc -o libtcc1.o -c lib/libtcc1.c -O2 -Wall
libtcc.c: At top level:
libtcc.c:1063: error: static declaration of 'tcc_add_file_internal' follows non-static declaration
tccelf.c:2915: note: previous implicit declaration of 'tcc_add_file_internal' was here
Signed-off-by: Sergei Trofimovich <st@anti-virus.by>
On Sun, Nov 22, 2009 at 05:43:14PM +0100, Luigi Rizzo wrote:
> Hi,
> there is a well known problem with tcc and FreeBSD in the generation
> of elf objects -- see
> http://lists.gnu.org/archive/html/tinycc-devel/2005-07/msg00070.html
>
> Apparently Sergey Lyubka has tried a partial fix to the problem.
> I was wondering if Sergey or someone can post some more detail on
> what needs to be done so we can try to help fixing this issue
I think i have managed to solve the problem and produce
almost valid elf files on FreeBSD. The two patches attached
address a few problems (trying to explain to the
best of my knowledge; i am not very familiar with ELF and
the FreeBSD ELF conventions):
1. ELF file format
tcc produces an ELF executable which is good for linux but
not for FreeBSD. It misses the PHDR section which is almost
mandatory for shared executables, puts in the .dynsym section
some relocation info that FreeBSD expects to be in .got,
and expect the relocation sections to be contiguous.
patch-tccelf.c tries to address the above problem using
conditional sections (so hopefully can be imported upstream)
and also adds the ability to override the name of the dynamic
loader through an environment variable (this is important to
debug tcc).
2. predefined macros
patch-libtcc.c adds/fixes some predefined macros when compiling
on FreeBSD: these are __FreeBSD__ and the usual set of
__i386__ and __unix__ variants.
It also sets __INTEL_COMPILER so we can grab the __aligned
macro from cdefs.h , otherwise many programs would fail
The resulting elf file is still not 100% correct -- if you strip it,
the program will not run (presumably there is some dangling reference).
Other than that, program do seem to run correctly.
It would be nice to integrate these patches in the main repository.
The FreeBSD specific code is in #ifdef so it should not harm
linux users
cheers
luigi
(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.
