Re: [Tinycc-devel] macos problems

[Karl Yerkes]

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 <address@hidden> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel