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

[grischka]

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'?

- The function shouldn't be placed in the middle of the memory wrapper
  section (rather below it, probably).

- Ident by 4 please.

- 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'.

- 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?)


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?

Thanks,

--- grischka