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

[Steffen Nurpmeso]

Hello.

grischka <address@hidden> wrote:
 |Steffen Nurpmeso wrote:
 |> So until anyone complains i will (try to) push that stuff to [mob]
 |> on repo.or.cz, on Tuesday?
 |
 |Please don't.
 |
 |Maybe you can make a fork on github (or something like that) first
 |in order to show your work in context.

I do not have a github account.  I had one but removed it.  (They
did want to take cash, only credit cards, but i wanted to pay.)
I like repo.or.cz?.  Yes i do.  But that aspect i never used yet.
(Back in 201? i have not used it, they said it was running on
a single small box, and they had a lot of projects already.  That
somehow counteracts my chaotic style of working, with many pushes
and rebases.  Thanks to git.)

 |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

 |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.

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)