[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] macos problems

From: Michael Matz
Subject: Re: [Tinycc-devel] macos problems
Date: Wed, 15 Apr 2020 04:58:25 +0200 (CEST)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)


On Wed, 15 Apr 2020, Robert Hölzl wrote:


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
* 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>
#error define ORDER to 1 or 2

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);

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]