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: libstdc++ in a combined tree


DJ Delorie wrote:
>> Right, I understand.  Assuming that they exist at this point, you
>> could theoretically pass enough options to make it work -- although,
>> as you say, it's hard to know what those options ought to be.  If
>> everything is set up right, it's -I options (for libc headers), -L
>> options (for libc and libgloss), and a -T option (for appropriate
>> linker script).
> 
> I did that for m32c, the problem is that we're explicitly denying
> linking with a GCC_NO_EXECUTABLES, then we link anyway.  It will
> *always* break, regardless of -I/-L options, because autoconf itself
> is complaining.

Well, that sounds like an autoconf bug.  If it refuses to work when
presented with a pile of compiler options, that just sounds bad.

I know none of my suggestions have been particularly expedient. :-(

If you're looking for a short-term hack, the best I can think of is
--enable-libstdc++-symvers.  I think (but I'm not a libstdc++
maintainer!) that an --enable-libstdc++-symvers option might be
acceptable, and that wouldn't run afoul of my concern about using
autoconf only in native configurations, etc.

I think that problem (which we already have in some places) is truly
*awful*; whatever short-term win may come out of it for one party is
lost in the long-term loss for the whole project when a configuration
behaves differently depending on native/cross/Canadian.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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