Hey. Note the ML or who generates reply-to which point to gnu.org but replying to that causes delivery failure. My former response i have resend (but without adding Resent headers), which is why it was later than the updated patch.
grischka <[email protected]> wrote: |Steffen Nurpmeso wrote: puff |> [1] http://lists.gnu.org/archive/html/tinycc-devel/2017-09/msg00081.html | |I meant, we need not just to see the problem, but we also need |to know what causes the problem that we see ... i am afraid you will not find the smallest gleam of humour here. |Let's make some assumptions: | |1) That {B}/include should be the first of sysinclude_paths: | is correct False. It has nothing to do with system headers but a compiler-specific overlay. Not that i like that. It is part of the ABI, right. Nonetheless, today (and not that it was that much better once i started non-script programming) all that comes from "__builtin", and you will not find __builtin, you will follow an endless chain of include files and preprocessor jungles and typedefs and end up with nothing. One more reason to favour BSD and musl LibC's over GNU: noone will be able to find just anything. It was a fantastic experience to come from Suse / RedHat (Halloween) and Debian Linux to FreeBSD 4.7 i think. You need something, look in the sources, and there it is. |2) That tcc tries normal -I includes before sysincludes: | is correct I already left, right. |3) The paths that you have in C_INCLUDE_PATHS: | are correct (as you have told us, we believe you) Better watch out 'cause I'm a .. |So, either: | a) we can prove that one of assumptions 1)..3) above is false | b) the problem that you see is caused by a problem elsewhere | c) the problem that you see is not a problem really. No. ... |> better, i can do it like that. Or rename sysincludes to |> tccincludes, which would be even better. That latter i would |> like. | |Maybe. It is just that we will not need any of these names. How do you want to solve the problem then? |Because when I have for example my own file | foo/stdarg.h |then | $ tcc -I foo ... |must pick up that file in 'foo' and not the one in {B}/include. You want to override stdarg.h. How would that work with GNU LibC? |That is how it should work and that is how it does work ;=) Not that i know? Likely only because the compiler you use simply injects __builtin_va_list no matter what. But that will not work out, tcc only allows preprocessor definitions as far as i know it? (And they are not even "protectable" but can be #undef'd?!) If there is a way to provide a fixed structure type that always exists, that would be cool, and could be used to solve the problem. But otherwise i will (try to) commit that tomorrow, because the definition of __builtin_va_list must be available once first used, because it is not pointer-based, but a typedef to an array of size one. Right? Ciao. --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
