/usr/include/syslog.h:68: error: invalid type #24

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

/usr/include/syslog.h:68: error: invalid type #24

James Mills
Hi All,

Sorry for the bad subject line; but this is the best I could come up with!

I am trying to understand this "invalid type" I keep getting when trying to compile software that wants to pull in syslog.h -- e.g: libressl and most recently I also tried util-linux.

You can see the full issue/details here: https://github.com/prologic/ulinux/issues/24

Some background:

- ulinux is a custom Linux-based OS/Distro thing I'm trying to create :)
- It uses a busybox userland
- It ships with a tcc+musl toolchain

I've successfully managed to get a few other pieces of software building inside a uLinux running environment okay (VM) as you can see from the now available ports tree at: https://github.com/prologic/ulinux/tree/master/ports (so so far so good! only a few minor patches mostly with sed!)

I would appreciate some help understanding this syslog.h "invalid type" problem. I don't quite get it :) FWIW that line references va_list which I've been able to get other software built that wants to use valist successfully be ensuring -I/usr/lib/tcc/include comes first by adding this to an export CFLAGS=... in /etc/pkg.conf (pkg is what builds ports from Pkgfile(s))

Kind regards

James

James Mills / prologic

E: [hidden email]

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: /usr/include/syslog.h:68: error: invalid type #24

Michael Matz-4
Hello,


On Wed, 15 Apr 2020, James Mills wrote:

> Sorry for the bad subject line; but this is the best I could come up
> with!
>
> I am trying to understand this "invalid type" I keep getting when trying to
> compile software that wants to pull in syslog.h -- e.g: libressl and most
> recently I also tried util-linux.
>
> You can see the full issue/details
> here: https://github.com/prologic/ulinux/issues/24

Well, what declaration or type is on syslog.h:68 ?  (Possibly look at
preprocessed output (-E) in case some macro substitution is going on).

> Some background:
>
> - ulinux is a custom Linux-based OS/Distro thing I'm trying to create :)
> - It uses a busybox userland
> - It ships with a tcc+musl toolchain

That sounds quite fascinating :)  (Note that with musl you'll probably run
into problems with stdarg.h usages; musl want's to rely on compiler
provided builtins for those, which TCC doesn't provide, even though our
implementation is binary compatible with the psABI, ... one of those days
...)

> I would appreciate some help understanding this syslog.h "invalid type"
> problem. I don't quite get it :) FWIW that line references va_list which

... ah, oh, see?  :)  Hmm, so is TCC's stdarg.h really being included, or
is it picking up some other stdarg.h?


Ciao,
Michael.

> I've been able to get other software built that wants to use valist
> successfully be ensuring -I/usr/lib/tcc/include comes first by adding this
> to an export CFLAGS=... in /etc/pkg.conf (pkg is what builds ports from
> Pkgfile(s))
>
> Kind regards
>
> James
>
> James Mills / prologic
>
> E: [hidden email]: prologic.shortcircuit.net.au
>
>
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: /usr/include/syslog.h:68: error: invalid type #24

Steffen Nurpmeso
Hello prologic, Michael,

Michael Matz wrote in
<[hidden email]>:
 |On Wed, 15 Apr 2020, James Mills wrote:
 |> I am trying to understand this "invalid type" I keep getting when \
 |> trying to
 |> compile software that wants to pull in syslog.h -- e.g: libressl and most
 |> recently I also tried util-linux.
 |>
 |> You can see the full issue/details
 |> here: https://github.com/prologic/ulinux/issues/24
 |
 |Well, what declaration or type is on syslog.h:68 ?  (Possibly look at
 |preprocessed output (-E) in case some macro substitution is going on).
 ...
 |> I would appreciate some help understanding this syslog.h "invalid type"
 |> problem. I don't quite get it :) FWIW that line references va_list which
 |
 |... ah, oh, see?  :)  Hmm, so is TCC's stdarg.h really being included, or
 |is it picking up some other stdarg.h?

On AlpineLinux with musl, at [096c93c], if i add the diff

  diff --git a/lib/Makefile b/lib/Makefile
  index 9d74dc3..cb67731 100644
  --- a/lib/Makefile
  +++ b/lib/Makefile
  @@ -11,7 +11,7 @@ X = $(if $(CROSS_TARGET),$(CROSS_TARGET)-)
   XTCC ?= $(TOP)/$(X)tcc$(EXESUF)
   XCC = $(XTCC)
   XAR = $(XTCC) -ar
  -XFLAGS-unx = -B$(TOPSRC)
  +XFLAGS-unx = -B$(TOPSRC) -B$(TOPSRC)/include -I$(TOPSRC)/include
   XFLAGS-win = -B$(TOPSRC)/win32 -I$(TOPSRC)/include
   XFLAGS = $(XFLAGS$(XCFG)) -I$(TOP)
   XCFG = $(or $(findstring -win,$T),-unx)
  diff --git a/lib/bt-log.c b/lib/bt-log.c
  index 73e0067..d767f08 100644
  --- a/lib/bt-log.c
  +++ b/lib/bt-log.c
  @@ -1,6 +1,7 @@
   /* ------------------------------------------------------------- */
   /* function to get a stack backtrace on demand with a message */
   
  +#include <stdarg.h>
   #include <stdio.h>
   #include <string.h>

then i get to it, if i also include my patches from 2017

  diff --git a/libtcc.c b/libtcc.c
  index fdbe2e7..73b0b05 100644
  --- a/libtcc.c
  +++ b/libtcc.c
  @@ -922,6 +922,7 @@ LIBTCCAPI TCCState *tcc_new(void)
   # if defined(TCC_MUSL)
       tcc_define_symbol(s, "__DEFINED_va_list", "");
       tcc_define_symbol(s, "__DEFINED___isoc_va_list", "");
  +    tcc_define_symbol(s, "__builtin_va_list", "va_list");
       tcc_define_symbol(s, "__isoc_va_list", "void *");
   # endif /* TCC_MUSL */
       /* Some GCC builtins that are simple to express as macros.  */
  @@ -940,6 +941,7 @@ LIBTCCAPI void tcc_delete(TCCState *s1)
       dynarray_reset(&s1->crt_paths, &s1->nb_crt_paths);
   
       /* free include paths */
  +    dynarray_reset(&s1->tccinclude_paths, &s1->nb_tccinclude_paths);
       dynarray_reset(&s1->include_paths, &s1->nb_include_paths);
       dynarray_reset(&s1->sysinclude_paths, &s1->nb_sysinclude_paths);
   
  @@ -983,6 +985,7 @@ LIBTCCAPI int tcc_set_output_type(TCCState *s, int output_type)
       if (!s->nostdinc) {
           /* default include paths */
           /* -isystem paths have already been handled */
  +        tcc_add_tccinclude_path(s, CONFIG_TCC_TCCINCLUDEPATHS);
           tcc_add_sysinclude_path(s, CONFIG_TCC_SYSINCLUDEPATHS);
       }
   
  @@ -1020,6 +1023,12 @@ LIBTCCAPI int tcc_set_output_type(TCCState *s, int output_type)
       return 0;
   }
   
  +LIBTCCAPI int tcc_add_tccinclude_path(TCCState *s, const char *pathname)
  +{
  +    tcc_split_path(s, &s->tccinclude_paths, &s->nb_tccinclude_paths, pathname);
  +    return 0;
  +}
  +
   LIBTCCAPI int tcc_add_include_path(TCCState *s, const char *pathname)
   {
       tcc_split_path(s, &s->include_paths, &s->nb_include_paths, pathname);
  diff --git a/libtcc.h b/libtcc.h
  index e164f5c..60c87a3 100644
  --- a/libtcc.h
  +++ b/libtcc.h
  @@ -39,6 +39,9 @@ LIBTCCAPI void tcc_set_options(TCCState *s, const char *str);
   /*****************************/
   /* preprocessor */
   
  +/* add in tcc include path, searched before anything else */
  +LIBTCCAPI int tcc_add_tccinclude_path(TCCState *s, const char *pathname);
  +
   /* add include path */
   LIBTCCAPI int tcc_add_include_path(TCCState *s, const char *pathname);
   
  diff --git a/tcc.c b/tcc.c
  index 34bfa00..fed6dc2 100644
  --- a/tcc.c
  +++ b/tcc.c
  @@ -183,6 +183,7 @@ static void print_search_dirs(TCCState *s)
   {
       printf("install: %s\n", s->tcc_lib_path);
       /* print_dirs("programs", NULL, 0); */
  +    print_dirs("tcc-include", s->tccinclude_paths, s->nb_tccinclude_paths);
       print_dirs("include", s->sysinclude_paths, s->nb_sysinclude_paths);
       print_dirs("libraries", s->library_paths, s->nb_library_paths);
   #ifdef TCC_TARGET_PE
  diff --git a/tcc.h b/tcc.h
  index a4506f4..1329ffe 100644
  --- a/tcc.h
  +++ b/tcc.h
  @@ -214,13 +214,20 @@ extern long double strtold (const char *__nptr, char **__endptr);
   /* Below: {B} is substituted by CONFIG_TCCDIR (rsp. -B option) */
   
   /* system include paths */
  +#ifndef CONFIG_TCC_TCCINCLUDEPATHS
  +# ifdef TCC_TARGET_PE
  +#  define CONFIG_TCC_TCCINCLUDEPATHS "{B}/include"PATHSEP"{B}/include/winapi"
  +# else
  +#  define CONFIG_TCC_TCCINCLUDEPATHS "{B}/include"
  +# endif
  +#endif
  +
   #ifndef CONFIG_TCC_SYSINCLUDEPATHS
   # ifdef TCC_TARGET_PE
  -#  define CONFIG_TCC_SYSINCLUDEPATHS "{B}/include"PATHSEP"{B}/include/winapi"
  +#  define CONFIG_TCC_SYSINCLUDEPATHS ""
   # else
   #  define CONFIG_TCC_SYSINCLUDEPATHS \
  -        "{B}/include" \
  -    ":" ALSO_TRIPLET(CONFIG_SYSROOT "/usr/local/include") \
  +    ALSO_TRIPLET(CONFIG_SYSROOT "/usr/local/include") \
       ":" ALSO_TRIPLET(CONFIG_SYSROOT "/usr/include")
   # endif
   #endif
  @@ -753,7 +760,10 @@ struct TCCState {
       DLLReference **loaded_dlls;
       int nb_loaded_dlls;
   
  -    /* include paths */
  +    /* include paths, search order */
  +    char **tccinclude_paths;
  +    int nb_tccinclude_paths;
  +
       char **include_paths;
       int nb_include_paths;
   
  diff --git a/tccpp.c b/tccpp.c
  index 2802d8e..52d46d9 100644
  --- a/tccpp.c
  +++ b/tccpp.c
  @@ -1809,7 +1809,8 @@ ST_FUNC void preprocess(int is_bof)
           /* push current file on stack */
           *s1->include_stack_ptr++ = file;
           i = tok == TOK_INCLUDE_NEXT ? file->include_next_index: 0;
  -        n = 2 + s1->nb_include_paths + s1->nb_sysinclude_paths;
  +        n = 2 + s1->nb_tccinclude_paths + s1->nb_include_paths +
  +            s1->nb_sysinclude_paths;
           for (; i < n; ++i) {
               char buf1[sizeof file->filename];
               CachedInclude *e;
  @@ -1831,8 +1832,14 @@ ST_FUNC void preprocess(int is_bof)
   
               } else {
                   /* search in all the include paths */
  -                int j = i - 2, k = j - s1->nb_include_paths;
  -                path = k < 0 ? s1->include_paths[j] : s1->sysinclude_paths[k];
  +                int k, j = i - 2;
  +
  +                if (j < (k = s1->nb_tccinclude_paths))
  +                    path = s1->tccinclude_paths[j];
  +                else if ((j -= k) < s1->nb_include_paths)
  +                    path = s1->include_paths[j];
  +                else if ((j -= s1->nb_include_paths) < s1->nb_sysinclude_paths)
  +                    path = s1->sysinclude_paths[j];
                   pstrcpy(buf1, sizeof(buf1), path);
                   pstrcat(buf1, sizeof(buf1), "/");
               }

which is ugly since there is no equivalent to the -B option which
can drive this, but it then works.
However, it seems you need more for libressl, so i added for
tinycc a new internal header in include/, syslog.h:

  #ifndef _TINY_SYSLOG_H
  #define _TINY_SYSLOG_H

  #include <stdarg.h>
  #include <syslog.h>

  #endif /* _TINY_SYSLOG_H */

because musl plays around with va_list in syslog.h.

 |> I've been able to get other software built that wants to use valist
 |> successfully be ensuring -I/usr/lib/tcc/include comes first by adding \
 |> this
 |> to an export CFLAGS=... in /etc/pkg.conf (pkg is what builds ports from
 |> Pkgfile(s))

Ah ja, that and syslog.h wrapper could get you going, until you
fail with

    CCLD     libcompat.la
  ar: `u' modifier ignored since `D' is the default (see `U')
    CCLD     libcrypto.la
  tcc: error: invalid option -- '--whole-archive'
  make[2]: *** [Makefile:3904: libcrypto.la] Error 1
  make[2]: Leaving directory '/tmp/x/libressl-3.1.0/crypto'
  make[1]: *** [Makefile:2165: all] Error 2
  make[1]: Leaving directory '/tmp/x/libressl-3.1.0/crypto'
  make: *** [Makefile:453: all-recursive] Error 1

Ciao, out for cycling now :)

--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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: /usr/include/syslog.h:68: error: invalid type #24

Steffen Nurpmeso
Steffen Nurpmeso wrote in
<20200415150909.F9guS%[hidden email]>:
 |Michael Matz wrote in
 |<[hidden email]>:
 ||On Wed, 15 Apr 2020, James Mills wrote:
 ||> I am trying to understand this "invalid type" I keep getting when \
 ...
 |However, it seems you need more for libressl, so i added for
 |tinycc a new internal header in include/, syslog.h:
 |
 |  #ifndef _TINY_SYSLOG_H
 |  #define _TINY_SYSLOG_H
 |
 |  #include <stdarg.h>
 |  #include <syslog.h>
 |
 |  #endif /* _TINY_SYSLOG_H */
 |
 |because musl plays around with va_list in syslog.h.

Actually we also need at the end of include/stdarg.h a "#define
__DEFINED_va_list" so that it is not redefined.  I have no more
musl here, only on the VM, sorry, forgot to copy that over to
here.  Out now.

--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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: /usr/include/syslog.h:68: error: invalid type #24

tinycc-devel mailing list
Hello,

I've already had some success building musl using tinycc for my own kernel.
While this probably isn't applicable to your particular problem I still would like to note this down if anyone ever needs it.

This involves building musl with custom CFLAGS to add the tcc stdarg.h to the include path and deleting things that don't work.

Musl can compile almost everything of musl, except for some math (complex numbers) and some assembly (unimplemented instructions) and a few bits of c (__syscall4, __syscall5, __syscall6).
I've attached a patch for musl version 1.2.0, while this makes musl buildable using tinycc it won't actually work since the syscall implementations are missing.
This doesn't really matter for my own kernel since I provide my own implementation of the syscall interface.
I also haven't tested if musl still compiles with other compilers, e.g. gcc, using my patch.

It would be nice if someone could implement "proper" support for va_list (__builtin_va_start and friends, so no calls to an external library, etc..).

See also https://lists.gnu.org/archive/html/tinycc-devel/2017-05/msg00042.html for more details.

- bauen1


On 4/15/20 5:18 PM, Steffen Nurpmeso wrote:

> Steffen Nurpmeso wrote in
> <20200415150909.F9guS%[hidden email]>:
>  |Michael Matz wrote in
>  |<[hidden email]>:
>  ||On Wed, 15 Apr 2020, James Mills wrote:
>  ||> I am trying to understand this "invalid type" I keep getting when \
>  ...
>  |However, it seems you need more for libressl, so i added for
>  |tinycc a new internal header in include/, syslog.h:
>  |
>  |  #ifndef _TINY_SYSLOG_H
>  |  #define _TINY_SYSLOG_H
>  |
>  |  #include <stdarg.h>
>  |  #include <syslog.h>
>  |
>  |  #endif /* _TINY_SYSLOG_H */
>  |
>  |because musl plays around with va_list in syslog.h.
>
> Actually we also need at the end of include/stdarg.h a "#define
> __DEFINED_va_list" so that it is not redefined.  I have no more
> musl here, only on the VM, sorry, forgot to copy that over to
> here.  Out now.
>
> --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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

0001-build-using-tcc.patch (97K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

stdarg.h overhaul (was: /usr/include/syslog.h:68: error: invalid type)

Michael Matz-4
In reply to this post by Michael Matz-4
Hello all,

On Wed, 15 Apr 2020, Michael Matz wrote:

>>  I would appreciate some help understanding this syslog.h "invalid
>>  type" problem. I don't quite get it :) FWIW that line references
>>  va_list which
>
> ... ah, oh, see?  :)  Hmm, so is TCC's stdarg.h really being included,
> or is it picking up some other stdarg.h?

So, I've dusted off an old patch of mine that overhauls how TCC is doing
stdarg.h support.  mob at 2f943902 has it.  In particular our own stdarg.h
now looks like this:

-----
typedef __builtin_va_list va_list;
#define va_start __builtin_va_start
#define va_arg __builtin_va_arg
#define va_copy __builtin_va_copy
#define va_end __builtin_va_end
-----

(not much different from musl stdarg.h)

In other words, TCC now always defines __builtin_va_list,
__builtin_va_start, __builtin_va_arg, __builtin_va_copy and
__builtin_va_end.  The way it does so is unconventional but as
identifiers with __builtin are purely for compiler implementations that
shouldn't matter (see below).

I've tested this on glibc linux (x86-64, riscv64, arm64, armhf and i386),
and on alpine linux x86-64 (i.e. a musl distro, my rootfs was a bit
oldish, but still).

So, hmm, that might mean that TCC is now working a bit more out of the box
for musl systems.  Lacking something like a MacOS rootfs/sandbox I can't
verify if this also helps MacOS, it might make things better or worse, so
I'd appreciate some testing there.  And all other testing as well of
course.

For the curious: the way it's implemented is still partially via
macros which are pre-loaded from a header named tcc_predefs.h before any
other processing.  It is loaded unconditionally, and I'm using it simply
to make the implementation of these builtins easier to maintain; for all
intents and purposes these are now really built into tcc.  Programs can
detect a difference to e.g. GCC by #ifdef testing of those identifiers,
and if absolutely necessary that could also be disabled, but as programs
really have no business in doing such hackery we should do that only when
we have evidence that it's necessary.

Would be nice if you could check that on ulinux and libressl :)


Ciao,
Michael.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: stdarg.h overhaul (was: /usr/include/syslog.h:68: error: invalid type)

Steffen Nurpmeso
Michael Matz wrote in
<[hidden email]>:
 |On Wed, 15 Apr 2020, Michael Matz wrote:
 ...
 |So, I've dusted off an old patch of mine that overhauls how TCC is doing
 |stdarg.h support.  mob at 2f943902 has it.  In particular our own stdarg.h

Very cool!

  +    if (!is_asm && s1->output_type != TCC_OUTPUT_PREPROCESS)
  +        cstr_cat(&cstr, "#include \"tcc_predefs.h\"\n", -1);

That is it!  Great!  I tried to fool around to get the va thing
defined as a real type somewhere in the code base for an entire
afternoon, but simply enforcing the load of some special tcc
internal file is much easier.

  I was hoping for some kind of #include_next indeed, without ever
  being motivated enough to look in the codebase i have no plan
  of.  Like i said back in 2017 or so after grischka reverted that
  tccinclude commit of mine, i never understood why compilers
  install a tremendous load of internal headers which shadow or
  provide standard headers, like stdarg.h, but if you sprinkle
  #error's you note they never get even loaded.  Either you need
  it for proper functioning or not, i do not understand.  But
  granted the patch was much worse than what you are doing now!

 |Would be nice if you could check that on ulinux and libressl :)

Works much better now, great!  Thank you.  I hope he gets it done,
ulinux could be a really easy VM server thing for me.
(Unfortunately he removed a shell confirmation prompt() function
that was really neat; at least that function was in a pasteboard
thing i have seen.)

--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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: stdarg.h overhaul (was: /usr/include/syslog.h:68: error: invalid type)

James Mills
I dunno what you guys did here[1] but you've solved all my compilation problems related to syslog.h :D Thank you!
(I'm not a C dev by any stretch of the imagination!)

I can now close all issues related to this in https://github.com/prologic/ulinux :)

Thanks!

Kind regards

James


On Thu, Apr 16, 2020 at 8:23 AM Steffen Nurpmeso <[hidden email]> wrote:
Michael Matz wrote in
<[hidden email]>:
 |On Wed, 15 Apr 2020, Michael Matz wrote:
 ...
 |So, I've dusted off an old patch of mine that overhauls how TCC is doing
 |stdarg.h support.  mob at 2f943902 has it.  In particular our own stdarg.h

Very cool!

  +    if (!is_asm && s1->output_type != TCC_OUTPUT_PREPROCESS)
  +        cstr_cat(&cstr, "#include \"tcc_predefs.h\"\n", -1);

That is it!  Great!  I tried to fool around to get the va thing
defined as a real type somewhere in the code base for an entire
afternoon, but simply enforcing the load of some special tcc
internal file is much easier.

  I was hoping for some kind of #include_next indeed, without ever
  being motivated enough to look in the codebase i have no plan
  of.  Like i said back in 2017 or so after grischka reverted that
  tccinclude commit of mine, i never understood why compilers
  install a tremendous load of internal headers which shadow or
  provide standard headers, like stdarg.h, but if you sprinkle
  #error's you note they never get even loaded.  Either you need
  it for proper functioning or not, i do not understand.  But
  granted the patch was much worse than what you are doing now!

 |Would be nice if you could check that on ulinux and libressl :)

Works much better now, great!  Thank you.  I hope he gets it done,
ulinux could be a really easy VM server thing for me.
(Unfortunately he removed a shell confirmation prompt() function
that was really neat; at least that function was in a pasteboard
thing i have seen.)

--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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: stdarg.h overhaul (was: /usr/include/syslog.h:68: error: invalid type)

James Mills
I guess there's a new problem now [1]

It seems tcc -ar doesn't support the `x` command to extract an archive?

Building libressl borkes on this and I'm not sure hwo to get around it (yet).

Kind regards

James

James Mills / prologic

E: [hidden email]


On Fri, Apr 17, 2020 at 1:00 PM James Mills <[hidden email]> wrote:
I dunno what you guys did here[1] but you've solved all my compilation problems related to syslog.h :D Thank you!
(I'm not a C dev by any stretch of the imagination!)

I can now close all issues related to this in https://github.com/prologic/ulinux :)

Thanks!

Kind regards

James


On Thu, Apr 16, 2020 at 8:23 AM Steffen Nurpmeso <[hidden email]> wrote:
Michael Matz wrote in
<[hidden email]>:
 |On Wed, 15 Apr 2020, Michael Matz wrote:
 ...
 |So, I've dusted off an old patch of mine that overhauls how TCC is doing
 |stdarg.h support.  mob at 2f943902 has it.  In particular our own stdarg.h

Very cool!

  +    if (!is_asm && s1->output_type != TCC_OUTPUT_PREPROCESS)
  +        cstr_cat(&cstr, "#include \"tcc_predefs.h\"\n", -1);

That is it!  Great!  I tried to fool around to get the va thing
defined as a real type somewhere in the code base for an entire
afternoon, but simply enforcing the load of some special tcc
internal file is much easier.

  I was hoping for some kind of #include_next indeed, without ever
  being motivated enough to look in the codebase i have no plan
  of.  Like i said back in 2017 or so after grischka reverted that
  tccinclude commit of mine, i never understood why compilers
  install a tremendous load of internal headers which shadow or
  provide standard headers, like stdarg.h, but if you sprinkle
  #error's you note they never get even loaded.  Either you need
  it for proper functioning or not, i do not understand.  But
  granted the patch was much worse than what you are doing now!

 |Would be nice if you could check that on ulinux and libressl :)

Works much better now, great!  Thank you.  I hope he gets it done,
ulinux could be a really easy VM server thing for me.
(Unfortunately he removed a shell confirmation prompt() function
that was really neat; at least that function was in a pasteboard
thing i have seen.)

--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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: stdarg.h overhaul (was: /usr/include/syslog.h:68: error: invalid type)

Michael Matz-4
Hello,

On Fri, 17 Apr 2020, James Mills wrote:

> I guess there's a new problem now [1]
> It seems tcc -ar doesn't support the `x` command to extract an archive?

That's correct.  busybox contains a mini implementation of ar(1), so you
don't have to use the TCC provided one as wrapper script.


Ciao,
Michael.

>
> Building libressl borkes on this and I'm not sure hwo to get around it
> (yet).
>
> Kind regards
>
> James
>
> James Mills / prologic
>
> E: [hidden email]: prologic.shortcircuit.net.au
>
>
> On Fri, Apr 17, 2020 at 1:00 PM James Mills <[hidden email]>
> wrote:
>       I dunno what you guys did here[1] but you've solved all my
>       compilation problems related to syslog.h :D Thank you!(I'm not a
>       C dev by any stretch of the imagination!)
>
> I can now close all issues related to this in
> https://github.com/prologic/ulinux :)
>
> Thanks!
>
> Kind regards
>
> James
>
> [1]: https://github.com/mirror/tinycc/commit/245f6a0d1392a2862a0a1d2f370519
> 7f92452569
>
> James Mills / prologic
>
> E: [hidden email]: prologic.shortcircuit.net.au
>
>
> On Thu, Apr 16, 2020 at 8:23 AM Steffen Nurpmeso <[hidden email]>
> wrote:
>       Michael Matz wrote in
>       <[hidden email]>:
>        |On Wed, 15 Apr 2020, Michael Matz wrote:
>        ...
>        |So, I've dusted off an old patch of mine that overhauls
>       how TCC is doing
>        |stdarg.h support.  mob at 2f943902 has it.  In
>       particular our own stdarg.h
>
>       Very cool!
>
>         +    if (!is_asm && s1->output_type !=
>       TCC_OUTPUT_PREPROCESS)
>         +        cstr_cat(&cstr, "#include \"tcc_predefs.h\"\n",
>       -1);
>
>       That is it!  Great!  I tried to fool around to get the va
>       thing
>       defined as a real type somewhere in the code base for an
>       entire
>       afternoon, but simply enforcing the load of some special
>       tcc
>       internal file is much easier.
>
>         I was hoping for some kind of #include_next indeed,
>       without ever
>         being motivated enough to look in the codebase i have no
>       plan
>         of.  Like i said back in 2017 or so after grischka
>       reverted that
>         tccinclude commit of mine, i never understood why
>       compilers
>         install a tremendous load of internal headers which
>       shadow or
>         provide standard headers, like stdarg.h, but if you
>       sprinkle
>         #error's you note they never get even loaded.  Either
>       you need
>         it for proper functioning or not, i do not understand. 
>       But
>         granted the patch was much worse than what you are doing
>       now!
>
>        |Would be nice if you could check that on ulinux and
>       libressl :)
>
>       Works much better now, great!  Thank you.  I hope he gets
>       it done,
>       ulinux could be a really easy VM server thing for me.
>       (Unfortunately he removed a shell confirmation prompt()
>       function
>       that was really neat; at least that function was in a
>       pasteboard
>       thing i have seen.)
>
>       --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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel