This is the mail archive of the
mailing list for the glibc project.
Re: Bug generating libc.so.lds
On Fri, Mar 28, 2003 at 10:27:15PM -0800, Roland McGrath wrote:
> > Here's what the generated libc.so.lds looks like. Search for ".dtor".
> For me the link command does not produce any of those undefined symbol
> errors at all. I'm sure the gcc installations differ, and I don't have a
> guess at the moment whether what your libgcc does is the norm.
Well, I have a version of libgcc that reproduces it and one that
doesn't. The difference is that the one which does contains:
00000270 g F .text 0000003d .hidden __register_frame_info
Then the -u __register_frame on the command line causes this file
to be pulled in, which references abort ().
The difference appears to be that one GCC is built with --enable-shared
(works; in 3.2 the unwind functions have moved to libgcc_eh.a in this
case) and the other is built with --disable-shared (because it's a
bootstrap compiler; we can't create shared libraries until after we've
Filtering out the -u __register_frame appears to solve the problem.
Does that sound right?
There appear to be two other problems in this area, by the way. We
search for -lgcc_eh in configure when trying to figure out the status
of dwarf2 unwind information. Of course, in bootstrap it isn't there
yet, so we guess wrong. Can we get around this? I really don't want
to end up iterating until a fixed point; it'll probably take three or
more GCC builds and two glibc builds.
And in configure.in right by "dnl No \ in command here because it ends
up inside ''." there's a duplicated check for
libc_cv_gcc_dwarf2_unwind_info. I assume the first should be removed.
MontaVista Software Debian GNU/Linux Developer