tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Allow configuration of tcc libraries search path


From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] Allow configuration of tcc libraries search path
Date: Fri, 8 Jul 2011 18:42:01 +0200
User-agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.4; x86_64; ; )

Le jeudi 7 juillet 2011 20:22:30, grischka a écrit :
[SNIP fixed issues]

> Anyway.  As to the general issue with search paths, it would be good
> to find something clearer and more flexible.
> 
> Of course we want to support latest systems and multilib and whatnot.
> But all this "CONFIG_stuff" is pretty confusing by now.   I think it
> should be all in one place, at least.  Such that it is immediately
> visually obvious what paths are set on what system.
> 
> We could even introduce a new file that only deals with defining
> search paths.  We could have a file that tcc reads at runtime.
> Say "/usr/local/lib/tcc/tccconfig". Such it would be possible to make
> changes to the default search paths without recompiling tcc.
> 
> Anyway, this are just ideas.  Maybe we should make some list
> to start with:
> 
> 1) what paths does tcc need to search:
> - include paths
> - library paths
> - crt path (crt1.o etc)
> - interpreter path (ld-elf/linux.so)
> - libtcc1.a path (also for bcheck.o)
> 
> 2) on what systems
> - linux
> - freebsd
> - centos
> - win32
> - ....
> 
> 3) with what architecture
> - i386
> - x86-64
> - arm (/-pe)
> - ...
> 
> 4) What variables do we currently have, with what defaults:
> 
> CONFIG_SYSROOT
> - purpose: redirect system root to support cross compilers (?)
> - default: "" (empty)
> 
> CONFIG_TCCDIR
> - purpose: tcc runtime support (libtcc1.a, bcheck.o)
> - default: /usr/local/lib/tcc
> 
> s1->tcc_lib_path
> - purpose: as above, may be modified by -B switch
> - default: CONFIG_TCCDIR
> - win32: tcc.exe's directory
> 
> CONFIG_TCC_LDDIR
> - purpose: library path
> - default: /lib, /lib64
> 
> CONFIG_TCC_CRT_PREFIX
> - purpose: crt path
> - default: CONFIG_SYSROOT "/usr" CONFIG_TCC_LDDIR
> 
> elf_interp[]:
> - purpose: elf interpreter string in executable
> - default: /lib/ld-linux.so.2, ... (see tccelf.c:1334)
> 
> CONFIG_TCC_CROSSLIB
> - purpose: cross compiler runtime support (currently for win32/64)
> - default: undefined, lib/32, lib/64
> 
> CONFIG_TCC_INCSUBDIR
> - purpose: multilib (?)
> - default: ""
> 
> CONFIG_TCC_EXTRA_LDDIR
> - purpose: multilib (?)
> - default: undefined
> 
> CONFIG_USE_LIBGCC
> - purpose: link with CONFIG_SYSROOT CONFIG_TCC_LDDIR"/libgcc_s.so.1"
> - used on: arm (?)
> - default: undefined
> 
> WITHOUT_LIBTCC
> - purpose: do not link with "libtcc1.a"
> - used on: arm (?)
> - default: undefined
> 
> Maybe you could help to bring some structure to that mess.  For example
> how do you play with these for your 'multilib' support in debian?  Does
> it feel comfortable?
> 
> Imagine that tcc would already support "search path configuration"
> files and you want to write one for your purpose.  How would it look
> like?
Ok, I think I found a nice way to do it, although it's just a general design 
for now. Let me give you your opinion about it.


=== Requirements ===

First let's focus on multilib as you said. If more configuration is required 
later for some other uses, we'll modify tcc again. No need to bloat it by very 
generic code if there is no use case now. The requirement for multilib is 
suffix 
all path from search paths (whatever are these search paths: include search 
path, library search paths, etc…) by the multilib subdirectory, thereafter 
represented by <triplet>. The problem is the migration of a system to multilib 
as some libraries will be in multilib subdir and some other not. Hence the 
algorithm to search for a file f would be:

1 for dir in $search_path ; do
2     if [ -f $dir/<triplet> ] ; then
3         break
4     fi
5     if [ -f $dir/$f ] ; then
6         break
7     fi
8 done

You could even add an echo "File $f not found in multilib subdirectory" 
between line 5 and 6.


=== Limits of current solution ===

Right now, even with the introduction of tcc_split_path, we still need lots of 
boiler plate code, for each system file included. Also, lots a additional macro 
need to be introduced, which is not very pretty as you pointed out.

=== Sketch for a (hopefully) better solution ===

One thing to remember though is that almost all files (headers, object, 
archive, but not ld.so) are included via 
tcc_add_file_internal(s1,filename,flags). So if tcc_add_file_internal was 
modified 
to check for dirname(filename)/<triplet> and filename it would solve the 
problem. Only one option of configure and one macro would then be enough:
--with-multilib-subdir=triplet and CONFIG_TCC_MULTILIB_SUBDIR would do the 
job.

Of course we don't want to search all directories for file by trying with 
multilib subdir, only system directories. But fortunetely the difference is 
pretty easy to do. Everything from the command line is user specify and should 
be searched strictly, all the rest can be tried with multilib subdir. So all 
what would be needed is to split paths in two variables and change the 
functions using it, eg. library_paths would become system_library_paths and 
user_library_paths and tcc_add_library would then use both these dynarray 
differently. Same for other search paths. The distinction is even already done 
for includes.

So, what do you think?

Remains that tcc use its own system search path which are different from the 
one used by references tools (cpp, ld and ld.so). But this is completely 
orthogonal to multilib support and could be done later since we lived with 
this since a long time.
> 
> Thanks,
> 
> --- grischka

Best regards,

Thomas Preud'homme

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]