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

[Thomas Preud'homme]

Le jeudi 7 juillet 2011 20:22:30, vous avez écrit :
> Thomas Preud'homme wrote:
> > And also sorry for introducing so stupid bugs.
> 
> It was not your fault, it is all strtok's fault. ;)
> 
> As to the new version:
> 
> - I don't seem to like my own suggestion 'tcc_split_path_components'.
>    What about just 'tcc_split_path'?
Changed.
> 
> - The function shouldn't be placed in the middle of the memory wrapper
>    section (rather below it, probably).
Changed
> 
> - Ident by 4 please.
Done. Must come from some previous version of the code.
> 
> - Long names are not good practice always, IMO.  If all the function
>    does is about paths and components then it is useless visual clutter
>    to pre/postfix local variables with 'component' or 'path'.
Done. I don't totally agree though. For example, with the modification you need 
to read the code to now that end is the end of one path and not the end of the 
string. However, as the function is small it's fine.
> 
> - This sequence looks at undefined memory after \0 of 'in':
> 
>          end_component = in;
>          do {
>              while (*end_component && *end_component != ':')
>                  ++end_component;
>              // do stuff ...
>              in = ++end_component;
>          } while (*end_component);
> 
>    Try this instead, for example:
> 
>          do {
>              end = in;
>              while (*end && *end != ':')
>                  ++end;
>              // do stuff ...
>              in = end + 1;
>          } while (*end);
> 
>    (Looks better without '_component', doesn't it?)
True. Fixed.
> 
> 
> 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.
Well, everything is in tcc.h now. However all the variables don't work the 
same way so I agree it could be improved. I will use it for now in Debian as 
for now tcc can't compile there and work for a better solution at the same 
time.
> 
> 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.
I have no opinion about it except I think we should mimic gcc, ld and ld.so on 
this. For example currently tcc -run doesn't read /etc/ld.so.cache but 
probably should. Although, I'll need your advice for how to handle Windows 
properly. As to the multiarch, my feeling is that to all the directory which 
are searched (whether for include or libraries), the code has been changed to 
search in $dir/$multiarch and then $dir. It would mean using a list of suffix 
instead of specifying normal dir + multiarch dir. I mean the search paths are 
the same, but each directory is searched 2 times, one with multiarch subdir 
and one without.
> 
> 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

Nice summary.
> 
> 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?
Not really, but I tried to be a bit more generic by allowing to completely 
change the path. In my case I just need to be able to try each element of the 
path first with multiarch subdir and then alone.
> 
> Imagine that tcc would already support "search path configuration"
> files and you want to write one for your purpose.  How would it look
> like?
I will think about it. I've already pushed the fixes [0] from the first part so 
that we have a working code in the meantime. I shall have time to dedicate on 
it this sunday.

[0] 13121e220cb2b8ddbe1b4218b1734843493a95c8
> 
> Thanks,
> 
> --- grischka
Thanks again for your review.

Best regards.

Thomas Preud'homme

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