grischka <[email protected]> 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. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
