[Top][All Lists]

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

Re: [Tinycc-devel] x86_64, musl: generation of mixed C/C++ fails: undefi

From: Steffen Nurpmeso
Subject: Re: [Tinycc-devel] x86_64, musl: generation of mixed C/C++ fails: undefined reference to `__va_start'
Date: Thu, 03 Jan 2019 20:55:41 +0100
User-agent: s-nail v14.9.11-123-g49d1a5c2

Good evening Michael, everybody.

Michael Matz wrote in <address@hidden>:
 |On Thu, 3 Jan 2019, Steffen Nurpmeso wrote:
 |> Regardless of whether i use the AlpineLinux default tcc package,
 |> or my version with the little path-resistancy patch, i cannot
 |> create a binary from several C files which become compiled with
 |> tcc -static and linked to an -ar chive, and some C++ files:
 |>  /home/steffen/src/nail.git/src/su/core-code.c:233: undefined reference \
 |>  to `__va_start'
 |> The reason is of course that this symbol resides in
 |> /usr/lib/tcc/libtcc1.a, but that is unknown to the linker.

 |Well, you have to add the TCC support library into the link process. 
 |Either by using TCC as linker instead of clang or by explicitely listing 
 |That's not different from other compilers, e.g. when compiled by GCC you 
 |need to link with libgcc.a (or libgcc_s.so), either by using gcc as link 
 |editor or by listing it explicitely.  I.e. compilers always come with a 

Ok i see the similarity in that gcc_s.so is in /usr/lib/ (like
tcc.a is), whereas gcc.a is in a path very long
(/usr/lib/gcc/x86_64-alpine-linux-musl/8.2.0) and just as "hidden"
to a generic build process like /usr/lib/tcc/libtcc1.a is.

 |You seem to be under the impression that -ar somehow could deal with this: 

Nice.  It was a picture, yes.

 |it can't.  ar does nothing more than essentially packing all object files 
 |you listed into one .a file.  In particular no symbol resolution or 
 |linking steps are involved, and so the reference to __va_start is left 
 |untouched.  In this case even listing libtcc.a wouldn't help as ar 
 |leaves other archives alone.  You would have to unpack libtcc.a and 
 |include its individual object files in the tcc -ar command.  (But then you 
 |can just as well just mention that library in the link editing step 
 |I hope this clarifies the problem a bit.  In short: you have to list 
 |libtcc.a explicitely.

Outstanding!  Blindly assuming tcc1.a is everywhere i presume "tcc
-vv|grep tcc1.a" is the way to deal with that (on x86_64).  Ok.
Well, in fact i brought this on the table because i thought maybe
it would be easier if the va stuff would be in tcc.a not tcc1.a,
but looking around for libgcc.a was very helpful.

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

reply via email to

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