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]
Other format: [Raw text]

Re: PATCH RFC: Remove fork from collect2


On Mar 19, 2004, at 1:40 PM, Andrew Pinski wrote:
On Mar 19, 2004, at 1:30 PM, Caroline Tice wrote:

Actually this is an issue with Apple versus FSF libgcc and the name of the
function which saves/restores the FP so to resolve this issue either
the FSF's gcc has to have the functions in Darwin's libgcc or have libiberty
be built like the rest of the compiler, in each stage.

OK, let me see if I understand this:


1) libiberty.a is built with the installed system compiler. That generates some undefined
references, which the system compiler expects to be resolved by (shared, in this case)
libraries that it knows about and knows to link in.


2) This libiberty.a is used by subsequent passes, that don't use the system compiler
to link and don't know about its libraries. Link failure.


This must have come up before; HP, for example, has a lot of magic library routines.
What's the expected resolution? Just don't put things in libiberty that do that?


(Because Apple's system compiler is a version of gcc, this particular problem could be
solved by making the system compiler and the FSF compiler agree, as Andrew says,
but clearly that's not a general solution.)



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