Re: [Tinycc-devel] macos problems

[Michael Matz]

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.