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

[grischka]

Steffen Nurpmeso wrote:
>  |Also instead of showing snippets with "solutions" it might help if
>  |you try to explain what actually the problems are that you try to
>  |solve.
>
> But i actually did, starting with [1], there you can see anything,
> from running into the dead end of not being able to create
> a running binary on AlpineLinux/Musl to a working solution.  It
> actually compiled the binary that sends this message i think.
>
>   [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 ...

Let's make some assumptions:

1) That {B}/include should be the first of sysinclude_paths:
        is correct
2) That tcc tries normal -I includes before sysincludes:
        is correct
3) The paths that you have in C_INCLUDE_PATHS:
        are correct (as you have told us, we believe you)

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.

>  |Anyway I don't see why tcc would need vip paths or that kind of
>  |changes to va_list.  After all it does work already, and that on
>  |systems that are less simple than musl.
>
> That i do not understand.  Messages [2] and [3] show that the
> stdarg.h shipped with TinyCC is not picked because my
> $C_INCLUDE_PATH contains the entire set of system include paths,
> not only user specific extensions.  Therefore the {B} of tcc may
> be the first of sysincludes as much as you wanna, it will not be
> picked.  Please do not ask me why i include all paths in this
> variable, i have forgotten.  But tcc should deal with this!
>
>   [2] http://lists.gnu.org/archive/html/tinycc-devel/2017-09/msg00082.html
>   [3] http://lists.gnu.org/archive/html/tinycc-devel/2017-09/msg00083.html
>
>  |Something you maybe could try is to add some file to the command-line
>  |includes, like:
>  |
>  |#if defined(TCC_MUSL)
>  |     dynarray_add(&s->cmd_include_files,
>  |                  &s->nb_cmd_include_files, tcc_strdup("_musl.h"));
>  |#endif
>  |
>  |In that file you can then define extra stuff or include other files as
>  |you like or even typedef stuff.  Maybe not the best final solution but
>  |might help to find out what's the deal actually.
>
> I do not understand.  Sorry.  To me this sounds as if the changes
> look fine to you.  I think Rich Felker has done well with
> providing the additional typedef __isoc_va_list so that the void*
> is sufficient.  But of course it must be ensured that the correct
> stdarg.h is found, this is why it is there.  I personally like it
> very much that there is no jungle of preprocessor statements, let
> alone non-indented such sort.  It is what it is.  No need for
> a _musl.h.  Of course those paths including {B} could be prepended
> to the normal user includes in addition to the sysinclude ones,
> instead of going over the new VIP includes.  If you like that
> 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.

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.

That is how it should work and that is how it does work ;=)

-- gr

> Thanks for pushing the -enable-new-dtags change back then.
>
> --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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/tinycc-devel