I tried this on macOS 10.14.6 and both ORDER=1 and ORDER=2 compiled and ran
and produced the same result:
8: 8
7: 7
6: 6
5: 5
4: 4
3: 3
2: 2
1: 1
0: 0
i used TCC commit fb1fb8219ccf4813d63edf8c40fddc756e0c60cc.
i also learned that "The only compilation mode for TCC on MacOS is -run,
until someone provides an object file reader for Mach-O." which i wondered
about but never could find a definitive answer. i guess that means that
compiling TCC using TCC on macOS is not really possible for now as well,
right?
i appreciate the effort to make things work on macOS. i'm happy to test
other stuff.
thanks.
-- karl
On Tue, Apr 14, 2020 at 7:59 PM Michael Matz <matz....@frakked.de> wrote:
> Hi,
>
> On Wed, 15 Apr 2020, Robert Hölzl wrote:
>
> > Hello,
> >
> > I fixed the compilation problems of libtcc1.a on macOS (see commit ID
> > 1803762e3f86aff58d5cce78f7d4faf88e74cc6b).
>
> Uh, that breaks stdarg for everyone else on non-windows x86-64 and
> wouldn't work completely as is on MacOS either. We need to approach this
> in a more systematic way:
>
> a) find our which layout of va_list is used
> my bet is they're simply using GCC's definition as defacto standard,
> i.e. __builtin_va_list as provided by GCC. If so, then the current
> definition of the layout of __va_list_struct is correct.
> They most probably are not using your replacement void* type, as that
> can't work with the provided va_copy.
> b) find out why the MacOS headers are unhappy with this definition when
> compiled by TCC before including TCCs stdarg.h
>
> Also, have you read my answer to your mail from Saturday? I.e. would the
> reordering of the <stdarg.h> include in tcc.h have been enough?
>
> For the time being, I fixed the problem for non-windows x86-64 on mob,
> but also have tried to retain the meat and spirit of the changes you did,
> specifically (if I did that right you should be no worse off than with
> your patch):
>
> * not define _VA_LIST_T anymore in stdarg.h (which was for trying to work
> around the conflicting definition situation on MacOS, but obviously has
> bitrotten)
> * don't define _ANSI_SOURCE anymore in CFLAGS
> * define __builtin_va_list to void *
> * typedef va_list to __builtin_va_list
>
> The latter two points only conditional on __APPLE__ being defined. Note
> again that this definition of __builtin_va_list is _not_ going to work
> with the va_copy in our stdarg.h.
>
> I've reverted the changes in lib/va_list.c, though, as it was merely
> renaming variables after ignoring the dance with the type of the ap
> argument (not including "stdarg.h" makes this easier, the routines relied
> on the specific layout of it anyway, so we can just as well state the
> real type).
> (I've also moved the order of stdarg.h inclusion around in some files,
> maybe that helps as well)
>
> So, to get some progress on the two points above, do the following:
> given this small example:
> ------- stdarg1.c ---------
> #if ORDER == 1
> #include <stdarg.h>
> #include <stdio.h>
> #elif ORDER == 2
> #include <stdio.h>
> #include <stdarg.h>
> #else
> #error define ORDER to 1 or 2
> #endif
>
> void foo (int n, ...)
> {
> va_list ap;
> va_start(ap, n);
> while (n--) {
> int i = va_arg(ap, int);
> printf("%d: %d\n", n, i);
> }
> va_end(ap);
> }
>
> int main()
> {
> foo(9, 8, 7, 6, 5, 4, 3, 2, 1, 0);
> return 0;
> }
> ----------------------------
>
> compile and run this program with a just compiled TCC:
>
> % make
> % ./tcc -B. -run -DORDER=1 stdarg1.c
>
> does this fail already? Does it fail with -DORDER=2? If it fails, with
> which error? Capture the output of preprocessing in both cases (./tcc -B.
> -E -DORDER=1 stdarg1.c). Possibly add '-dD' to the preprocess options to
> see which macros are defined where. You can also send the two
> preprocessed files here.
>
> (My hope would be that it fails only with ORDER=2, and that we find some
> magic (macros or suchlike) that would make TCC find its own stdarg.h, even
> when system header are include)
>
> > But when creating a regular executable I get the following error
> > messages:
> >
> > tcc: error: unrecognized file type
> > tcc: error: file 'crt1.o' not found
> > tcc: error: file 'crti.o' not found
> > tcc: error: bad architecture
> > tcc: error: library 'c' not found
> > tcc: error: file 'crtn.o' not found
> >
> > It looks like tcc_load_ldscript() in tccelf.c failed when loading crt1.o
> > (ld_next() did not return LD_TOK_NAME).
> >
> > Again: older versions (i.e. commit id 944c) of tcc worked.
>
> Are you sure? Which C library and crt*.o files was it finding at the
> time? The thing is that TCC has no reader for Mach-O object files or
> libraries (and never had) so yes, it isn't able to load the runtime
> startup files or C library. The only compilation mode for TCC on MacOS is
> -run, until someone provides an object file reader for Mach-O.
>
>
> Ciao,
> Michael._______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
