Re: [Tinycc-devel] ..on those patches i have sent..

[Steffen Nurpmeso]

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 <address@hidden> 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)