More gcc/glibc weirdness

Greg Schafer gschafer at zip.com.au
Sat Feb 8 03:32:23 PST 2003


Hi

This is basically a follow up to the "Building Glibc Twice - Some Analysis"
post I made back in December.

Whilst looking at all this purity stuff I've managed to stumble upon the
answer for one of the unanswered questions in that post. In particular, the
HAVE_DWARF2_UNWIND_INFO define from config.h.

To recap some of that post:-


"-#define HAVE_DWARF2_UNWIND_INFO 1 <--- inside the blank chroot
+/* #undef HAVE_DWARF2_UNWIND_INFO */ <--- on a "normal" system

  This one looks a bit scary. Affected files are elf/sofini.c and
  elf/soinit.c. This is hard core ELF stuff which I have not much hope of
  understanding. But there seems no doubt that different code WILL be
  generated which is the worry."


I've now discovered the reason for this peculiarity:-

 - the glibc autoconf test that says:-

     "checking for DWARF2 unwind info support...

   contains a snippet of code that compiles a test program and links with
   "-lgcc_eh" and this fails because we don't have a "libgcc_eh.a" in
   /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1 where we should have.

 - the reason why we don't have "libgcc_eh.a" is because we are specifying
   "--disable-shared" in our Ch 5 gcc. NOTE! - this switch is only
   controlling whether the shared "libgcc_s.so.1" gets built or not. It
   does NOT control whether our final gcc binaries are linked statically as
   this is controlled by the "BOOT_LDFLAGS=-static" on the make command
   line. But it seems specifying "--enabled-shared" also allows creation of
   "libgcc_eh.a". This can also be proven by looking at the "mklibgcc.in"
   script.
   

All this "ELF, shared objects, Initializer modules, .ctors, .dtors, c++
exception handling interacting gcc and the C library" stuff is way beyond
most mere mortals and I certainly don't claim to understand any of it. All I
know is I have identified the cause of the anomaly. It may well be that no
harm is done and what we are seeing is just devlish detail. I just don't
know i.e. I have doubts (incidentally - the purity stuff is meant to get rid
of all these sorts of doubts).

Anyway, now that we are performing a recompile of glibc at the end of Ch 6,
the end result is the right one. But what about the rest of Ch 6? Argghh,
more doubts :-(

Howver, I think it safer to have it correct from the beginning. Therefore I
propose we change the "--disable-shared" in Ch 5 gcc to "--enable-shared".
This will also result in "libgcc_s.so.1" getting built in th Ch 5 gcc, but I
don't forsee any problem with this.

I have done some basic tests but I haven't built a full system yet with
this. Too busy working on the pure LFS stuff. I would be grateful if some
kind soul could test this out. Just use the switch as suggested, then watch
the 1st glibc build and make sure it says:-

checking for DWARF2 unwind info support... no_registry_needed

Thanks
Greg
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list