[Nix-dev] Re: Bootstrapping from a gcc with "--enable-shared"

[Lluís Batlle]

Adding a bit on this... questions and more clarifications.

I succesfully bootstrapped stdenvLinux on arm, but I used manually
created bootstrap-files made from fedora's binaries (and its glibc,
not dietlibc). I plan to use make-bootstrap-files.nix, but I've
problems building dietlibc meanwhile. Maybe I'll get on with glibc.

Although I could build eglibc 2.10, and it seemed to work, I kept with
glibc2.9 in the arm stdenvLinux, which also worked.

Still worried on the gcc of bootstrap-files and its libgcc_s.so, I
think I won't put in the bootstrap-files the stdenvLinux gcc, but I'll
build a new gcc with "--disable-shared".

Afaik, libgcc_s.so in some architectures has functions for usual gcc
patterns on generated code. I guess it has more 'usual' functions in
RISC architectures (for example, memcpy and alike, used on compiled
code), than on CISC like x86_32 or x86_64, and therefore I get
libgcc_s always linked in in arm. I'm not against having a libgcc_s in
the bootstrap_files - I'm against linking the stdenvLinux glibc with
-shared-libgcc (although I done this in this workign stdenvLinux, it
works a bit by chance, considering what's linked with what).

What do you think? I'll try how the make-bootstrap-files works on that
gcc-disable-shared, and test in on x86. And what do you think on
taking out dietlibc from there?

Regards,
Lluís.

2009/8/31 Lluís Batlle <viriketo at gmail.com>:
> Hello,
>
> in nixpkgs we bootstrap from a gcc with "--enable-shared"; afaik, this
> means that it will create ELF programs linked with libgcc_s (if
> needed: the gcc spec uses for ld --as-needed -lgcc_s --no-as-needed),
> if using the default "-shared-libgcc" in gcc. The libgcc_s.so in our
> bootstrap files is dynamically linked with libc, as all the
> libgcc_s.so files I've seen)
>
> When we use the bootstrap files to build a new libc, the programs
> coming with that libc will be linked with the libgcc_s, which was
> built to use the bootstrap-files libc, not the new libc.
>
> In i686 and x86_64, rarely the programs are linked with libgcc_s.
> Specially as the glibc nptl pthreads try to dlopen that library at
> runtime, if needed.
>
> But in ARM (I still don't know why for sure), all shared ELF programs
> compiled with gcc are linked with libgcc_s. At least all the simple
> programs I've tried to compile.
>
> Thus, having a gcc built with --enable-shared in the bootstrap files,
> or having glibc programs built with the default -shared-libgcc may
> lead to a libgcc_s egg-or-chicken problem specially in store paths.
>
> libgcc_s uses very few common symbols from glibc, so maybe I should
> not worry much, if we take the glibc, and remove any rpath reference
> to the bootstrap-files libraries, and set it to use only those of the
> latest gcc. But this would mean changing files in a store path after
> it has been built. Otherwise the glibc programs and libs would
> reference by rpath the libgcc_s in the bootstrap files.
>
> What do you think of this? I'll try to make glibc build all the
> programs with -static-libgcc, and I'll see if that is enough for
> removing any libgcc_s reference in it.
>