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 m...@codesourcery.com (650) 331-3385 x713
