Re: [Tinycc-devel] some thoughts on the search path mess

[Thomas Preud'homme]

Le mercredi 11 mars 2015, 21:28:25 Edmund Grimley Evans a écrit :
> Currently the search paths for a non-cross tcc on Debian arm64 look
> like this (./tcc -vv):
> 
> crt:
>   /usr/lib/aarch64-linux-gnu
> libraries:
>   /usr/lib/aarch64-linux-gnu
>   /usr/lib
>   /lib/aarch64-linux-gnu
>   /lib
>   /usr/local/lib/aarch64-linux-gnu
>   /usr/local/lib
> include:
>   /usr/local/include/aarch64-linux-gnu
>   /usr/local/include
>   /usr/include/aarch64-linux-gnu
>   /usr/include
>   /usr/local/lib/tcc/include
> 
> Does that seem correct?
> 
> I note that /usr/local/lib comes after /usr/lib, but
> /usr/local/include comes before /usr/include. Why is that?

Probably a mistake.

> 
> Also, should /usr/lib be on the search path for crt?

For symmetry we could, but I've never met a system where they are stored in 
/usr/lib.

> 
> Also, is it correct for /usr/local/lib/tcc/include to come last rather
> than first in the "include" list?

I'm not sure what's the usual way. Isn't the set of files in this directory and 
others include directory different?

> 
> Presumably the search paths for any other Debian architecture could be
> the same with the appropriate triplet substituted for
> "aarch64-linux-gnu".

Yes.

> 
> Now, it seems that some other Linux distributions use lib32 and lib64.
> Is that only on Intel, or do they do the same on other architectures
> that have 32-bit and 64-bit variants?

I'm pretty sure others do.

> 
> What should the search paths look like on one of those Linuxes?

You forget about the triplet-qualified paths and replace lib by lib64. It's 
important *not* to look on /lib as it's where 32 bit libraries would be. 
Basically /lib and /lib64 is a specialization of the multiarch directories 
where files for any architecture can coexist.

> 
> A general question: should "configure" try to work out what kind of
> Linux we're on, or it should it just merrily include all the
> possibilities in the search paths?

I've pondered about it and I think we could make things a bit simpler. That 
said on a multiarch system for amd64 you want to look at x86_64-linux-gnu/lib 
and then /lib while on a non multiarch system for amd64 you only look at 
/lib64. You cannot make it look in the 3 directories as /lib if not empty will 
contain some 32bit libraries on a non-multiarch system.

> 
> The situation for a cross compiler is mostly very similar, except:
> 
> * You can't run a test program. But TCC's configure doesn't do that
>   anyway.

Yeah, and there is no switch to specify the triplet on multiarch systems, you 
have to set all the path manually which is cumbersome.

> 
> * There's no point in including generic paths like /usr/lib in the
>   search paths. They are almost certainly wrong. However, if you're
>   cross-compiling between variants of the same architecture then it
>   probably make sense to include things like /usr/lib32 in the paths.

Except for biarch (-m 32) precisely.

> 
> * With a cross-compiler it's quite probable that the user will install
>   libraries after building TCC so it perhaps makes more sense to
>   include directories that don't yet exist in the search paths.

We don't look at whether there is file in the directory searched now, do we?

> 
> That last point suggests that for symmetry between cross and non-cross
> compilers it might make sense to put, by default, all likely
> directories into the search path whether or not they exist.

In the limits mentionned above.

> 
> Another general point: You can put complex "sh" logic in "configure",
> complex "make" logic in "Makefile", or complex "cpp" logic in the C
> source files: a choice of three crap programming languages! If you're
> a masochist, you can also put double-escaped sh code in the Makefile.
> Also, you can make the logic at each stage attempt to pre-empt bzw.
> second-guess what the logic at other stages has done or will do. I
> tend to think that "configure" is probably the best place to do things
> as "sh" is arguably the least hostile of the three environments. Also,
> configure produces a human-readable output and you can insert print
> statement into it, both of which help with debugging.

The problem is the --enable-cross option. It will build all cross compiler 
currently supported by tcc and each will have different search directory. You 
could maybe output the different paths into different file and then play with 
symlink when compiling the cross-compiler now that I think about it.

> 
> Thoughts?

It would be nice to clean the build system mess. The configure is still 
readable but the Makefile has become a bit crazy yeah.

Best regards,

Thomas

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