grischka <
address@hidden> wrote:
|Steffen Nurpmeso wrote:
..
|> mildly. I guess the right thing to do would be to strip all paths
|> which are also in the system array from the user paths present in
|> the non-standardized $C_INCLUDE_PATH environment variable, even if
|> that means that this possibly changes the search order desired by
|> the user anyway.
|
|Not quite. Really the only thing you can do is to clean up that
|suspicions system path cruft from the C_INCLUDE_PATH on YOUR OWN
|computer:
I see no reason to start screaming. If that would have been the
first reply of yours i would have looked around earlier for sure.
I think it was clear that i have no idea of compiler internals.
| - /usr/local/include
| - /usr/include
|
|Search order is fixed by conventions, and the built-in system
|paths have least priority.
|
|This implies that it is the compiler's business to set them and
|that at the same time the user is allowed to override them, even
|if then the compiler stops to work at all.
|
|Therefor your C_INCLUDE_PATH cannot work for tinycc.
|
|(The public version of tinycc that is, and as long as it needs
|its own stdarg.h / does not have __builtin_va_stuff)
I have recreated my patch locally, because i need tcc for working.
I do not know whether gcc and pcc create __builtin sauce in code,
but they do the right thing here, regardless of my C_INCLUDE_PATH.
gcc does not read its own stdarg.h, therefore i would assume it.
tcc also works like this on GNU LibC systems, by the way.
But hey, the bug has been reported, a simple-minded patch has been
rejected, i am eagerly awaiting a true fix.
Ciao. And have a nice weekend, of course.