This is the mail archive of the libc-alpha@cygnus.com mailing list for the glibc project.


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

Re: glibc update problems



  In message <Pine.LNX.3.96.980615131637.3423A-100000@panic.can.seawood.org>you write:
  > I ran into this problem as well.  It seems that egcs/gcc-2.8 have the
  > additional functions (de)register_frame_info as part of libgcc.a.  Any
  > shared library compiled will have these symbols.  Any shared lib
  > compiled with gcc-2.7 (redhat's glibc rpms) will not have these symbols.
  > 
  > There was one point that's still a bit cloudy to me.  In which of the
  > following situations will one need to worry about (de)register_frame_info
  > and will the symbols be defined in the shared lib or the executable?
  > 
  > egcs-compiled libc with egcs-compiled program?
The symbols will be in libc and you will only run into problems if
you later remove libc and replace it with one compiled by gcc-2.7.

  > egcs-compiled libc with gcc-2.7-compiled program?
Same as previous example, except that you don't have the problems
if you remove libc and replace it with one compiled by gcc-2.7
(since the program itself shouldn't have any references to the
problem symbols).

  > gcc-2.7-compiled libc with egcs-compiled program?
The symbols will be defined by the main program and you should
be able to change your libc at-will without causing problems.

Basically problems arise when replacing a shared library with
a version compiled by an older compiler.

jeff


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