This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux


Paolo Carlini wrote:

>> Subject to fixing the bug I think is present with static-only libgcc 
>> functions and C++ shared libraries (so that being able to link an 
>> executable with the functions means it is also possible to link libstdc++ 
>> and have the symbols resolved in that link), it would make sense to test 
>> linking if possible, failing that the .s file.
>>   
> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
> case conservative to have a link type test identical to the one used in
> libgomp and libgfortran and a fall back to the .s file (as currently used).

I think this is a reasonable strategy.  It's critical to avoid run-time
tests, as they don't work in cross configurations, but link-time tests
are not inherently problematic in the same way.  I think that link-time
tests are a reasonable approach.

If I recall correctly, the strongest objection to link-time tests comes
from people who do a "one-tree" build of an entire cross-toolchain.  I
think that if you can't link a C program (including using functions from
the C library) by the time you get to the point of building libstdc++,
that's a bug in the one-tree build procedure, but that's probably not a
fight worth having.

There's a secondary issue with link-time tests because you then up
determining things about the C library that may not be true if you use a
different C library, or a different version of the same C library, or
whatever.  I think some of those concerns are reasonable, but I think
the right way to deal with them is probably explicit configure options
for the benefit of people who want to make the C++ run-time use (or not
use) some feature of the C library that is different from what would be
determined by the link-time probe.  So, I think that this is an
orthogonal issue to the question of how we should probe.

FWIW,

-- 
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]