Re: compiling musl on x86_64 linux with pcc

[u-igbb@aetey.se]

Hello Rich,

On Mon, Aug 25, 2014 at 11:46:17AM -0400, Rich Felker wrote:
> I have pcc 1.1.0.DEVEL 20130227 with pcc-libs-20130721 and it seems to
> still work fine with current musl. Note that some fixes are needed for
> pcc-libs:
> 
> - You need to remove the broken csu files and replace them with
>   symlinks to the musl files.

I do not even generate crt[01in].o in pcclibs and of course use
the musl ones.

> - You need to add __attribute__((__visibility__("hidden"))) to all
>   external functions in libpcc.

This does not seem to make any difference (and probably would not 
be noticeable with simple tests anyway?).

> - You need to add -fPIC to the CFLAGS for building libpcc or you get a
>   broken libpcc (containing textrels) that can't be used for building
>   libc.so and that's harmful for use with any other shared libs.

I do.

Anyway, the brokenness is present with both static and dynamic linking.

(testing on i486-pc-linux-gnu)

I narrowed down what looks broken:
*printf() with "%something" seems to pick wrong arguments,
iow it looks like malfunctioning variadic args. (?)

> I just ran libc-test with libc.so built by pcc and confirmed that
> there are no non-math regressions versus gcc-built libc.so. (I did not
> check math in detail because there are lots of known math failures
> that are not serious.)
> 
> Let me know if you have any further questions about my setup.

Is it possible to try pcc from 2014-08-24 in your environment?

If it is hard, I can test the old versions instead (when I can, right now
my time slice is over).

Regards,
Rune

PS
(this variadic business reminds me again that stdarg.h should be provided
by the compiler who knows what it can do to the generated functions and
what it must do with the public ones - not by the library which can be
used with different compilers and should not boldly assume the level of
their intelligence)