Good morning! :) Michael Matz <matz....@frakked.de> wrote: |On Thu, 2 Jun 2016, Steffen Nurpmeso wrote: |> Well, have i yet asked this? I think no... |> It's like that for a long time, ever since i use tcc(1) (autumn |> last year): |> |> ?0[steffen@wales tmp]$ cat t.c |> #include <stdlib.h> |> int main(void){ |> char *x = realpath(".", NULL); |> |> return (x != NULL) ? 0 : 1; |>} |> ?0[steffen@wales tmp]$ for i in clang gcc tcc; do \ |> $i -o zt t.c && ./zt; echo $i: $?;\ |> done |> clang: 0 |> gcc: 0 |> tcc: 1 |> |> tcc(1) only gets realpath(3) with buffer argument right, i wonder |> what that can be? | |Wow. You've run into the result of an unimplemented feature of tcc, which |I never thought would matter in practice ;-) I'll explain, bear with me:
|accepting NULL as second argument. But glibc also has a strict no change |in interfaces policy, and this was a visible change, so symbol versioning |had to be used to provide the old behaviour for old applications (those |"when it supports symbol versions" is of course the crucial part: tcc as |ELF linker doesn't. So it leaves in an unversioned reference to |'realpath' in the executable and so the dynamic linker is free to choose |any. Now the usual ld.so uses a (normally) sensible heuristic for |choosing which one when there are several: for references from dlsym it |uses the newest available one, for references from applications that have |no symbol version information whatsoever it uses the oldest symbol |version, on the grounds that apps without any symversion info must have |been created before the ELF implementation provided them, i.e. they must |be very very old applications. | |This reasoning breaks down with an incomplete link editor like tcc. It |creates new applications that are regarded as very old by ld.so. So, what |you see is ld.so resolving to the old implementation of realpath, instead |of the current one. Thanks for your time and the whole picture! Hm, symbol versioning didn't really enter my world yet -- i know in FreeBSD you now even find linker scripts what should be some "beefy library", well. Terribly non-understandable choices regarding dlsym(3)/normal link! But now i see, this is the reason for dlvsym(3), a-ha. I never tried, but i assume it doesn't take a POSIX/xy version string (and what should that really be). Please excuse that i'm too lazy to find and look through the source code. |Short of implementing proper ELF symbol versioning in tcc there's only an |ugly work-around: you could use a different link editor. Perhaps there's |somewhen a rainy weekend when the former can be done. I'm even a little bit hooked to look somewhat deeper into ELF, i have the standards laying around for a loooong time: ?0[steffen@wales ]$ ll ~/arena/docs.coding/elf-* .. 525024 18 Apr 2012 /home/steffen/arena/docs.coding/elf-v1.2.pdf .. 630410 8 May 2012 /home/steffen/arena/docs.coding/elf-tls-abi.pdf That is unbelievable four years; maybe in the summer; would actually be nice to have it in tcc(1), too, since it is so much faster than clang/gcc! Ciao, --steffen _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel