DJ Delorie wrote: > Another one like libssp. > > In libstdc++-v3's configure.ac, we see this: > > # This depends on GLIBCXX CHECK_LINKER_FEATURES, but without it assumes no. > GLIBCXX_ENABLE_SYMVERS([yes]) > > The comment lies. If we haven't yet checked the linker features, it > will check them, and configure will fail in a combined build because > newlib/libgloss hasn't yet been installed. > > Since we already check for cross compiling, I've been using this > conditional instead: > > if test x"$gcc_no_link" = xyes; then true; else > # This will run GLIBCXX CHECK_LINKER_FEATURES, so we can't use it if we > can't > # build executables. > GLIBCXX_ENABLE_SYMVERS([yes]) > fi > > but of course this will drop support for cross compiled linux targets > having symbol versioning. Suggestions?
The key problem is that we have two ways of determining what features to enable and use: * Autoconf tests * Hard-coded information about the target * --enable-* flags to configure To me, it ought to be a fundamental invariant that the same features are enabled for cross and native compilation. To accomplish that, we need to avoid autoconf tests for features that require running target programs; we must hard-code those. We could hard-code everything, but that becomes difficult, because your target foo-*-bar system isn't quite the same as mine. Hence, my opinion is that we ought never to use autoconf tests to figure these things out, even for native compilation, relying instead on hard-coded target information of --enable-* flags. I think it makes sense to use autoconf for everything that doesn't require a runtime test, to the extent possible. To that end -- and I know this is going to be unpopular -- I think we should require that you have a C library available at libstdc++ build time, either by having one already installed, or by passing appropriate -I/-L options to libstdc++. IIUC, Cygwin has some complicated dependencies that make this difficult. (That's why I assume this suggestion isn't going to be popular.) Assuming people won't accept that restriction, then we ought to either (a) hard-code this choice, or (b) depend on a --enable-* flag. I think it should be considered bad policy to make things work differently for native/cross environments. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713