This is the mail archive of the gcc-patches@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: A new libgcc symbol patch


> >It won't work if we have more than one copies. I only make those libgcc
> >functions which I know can be safely made local in the shared library.
> 
> Fine, then the frame functions can't be in libgcc at all.
> 
> I think you still don't see the bug, or why it's a critical bug.  No
> shared library can export ANY libgcc function, otherwise there is
> binary incompatibility between the same shared library compiled by
> different versions of gcc.  This is only acceptable for shared
> libraries which are closely tied to the compiler, such as libstdc++.

That is a different bug. Please try my crtstuff.c patch.

> 
> >BTW, glibc 2.1 doesn't have any problem with it. Neither does the
> >current glibc 2.0 in CVS.
> 
> You are mistaken.
> 
> Exercise:
> 
> - compile glibc (any version) with egcs (any version)
> - compile it again with gcc 2.8
> - compile a program with egcs and link it with the egcs-compiled libc
> - attempt to run that program with dynamic linkage to the
> gcc-2.8-compiled library.
> 
> This is *NOT* a hypothetical situation: it's what happens when you
> compile a binary on (certain snapshots of a) Debian system, and try to
> run it on a Redhat system.

Please do

1. Get the latest glibc 2.0 from CVS.
2. Applied my crtstuff.c patch to egcs.

Then tell me what you get.

> 
> Debian has dealt with the problem by reverting to gcc 2.7 for
> glibc 2.0, but this will not work for 2.1, and they (sensibly) won't
> touch gcc 2.8.

Me either, for different reasons :-).

> 
> Ulrich's fix for the problem involves forcibly exporting the frame
> functions from libc.  That works only as long as egcs is used to
> compile libc (2.1) and the list of frame functions does not change.
> We can't count on either.

I don't see it is a problem.

> >That is essentially the end result of my patch. I left out ALL
> >C++ specific support functions from libgcc.map.
> 
> No, your patch means that C++ support functions will be in libstdc++,
> and libc, and libm, and libX11, and everywhere else.  That is the same
> 

Please show me that. Again, you need my crtstuff.c patch as well
as the latest glibc 2.0 from CVS or glibc 2.1. Please get back to
me with your result when you have done what I suggested.


-- 
H.J. Lu (hjl@gnu.org)


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