[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
|it.
|
|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
|later).
|
|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.
Ciao,
--steffen
|
|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)