This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: glibc2 & (de)register_frame_info




  In message <Pine.LNX.3.96.980602111212.6020A-100000@panic.can.seawood.org>you write:
  > When I compile glibc 2.0.{6,7} with egcs, glibc ends up defining
  > the symbols __register_frame_info & __deregister_frame_info. I noticed
  > that these are also defined in egcs' libgcc.a  Should this be happening? 
If glibc is built as a shared library, yes.

  > The real problem happens when I upgrade to a glibc that was not built with
  > egcs.  Some of the programs I compiled with egcs under a egcs built glibc
  > also have a dependency on these symbols.  If it wasn't /bin/login, I might
  > not have cared so much. :-/
Presumably the upgraded glibc was built with gcc-2.7?

If so, there's really no good solution to this problem at this time.


  > I have a box at home running RedHat's glibc 2.0.7-7 rpm and one at work
  > running glibc 2.0.6 compiled with egcs 1.0.1 (maybe 1.0.2).  Both boxes
  > have egcs 1.0.3a installed.  I recompiled the util-linux 2.7-15 srpm on
  > both boxes.  At work, __register_frame_info turns up when I strings
  > /bin/login.  At home, it does not. 
Right.  It gets sucked into the version at work because the link editor
couldn't find one in any of the shared libraries you're linking against,
so it has to put a copy in /bin/login.

At home, the symbol is satisfied from your libc and thus doesn't need to
be included in /bin/login.


jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]