DJ Delorie wrote: >> Well, that sounds like an autoconf bug. If it refuses to work when >> presented with a pile of compiler options, that just sounds bad. > > No, I think it's our bug - we do this: > > GCC_NO_EXECUTABLES > GLIBCXX_ENABLE_SYMVERS([yes]) > > You can't logically expect that to work, no matter how many compiler > options we give it - we've told autoconf to not produce any > executables, then asked it to test something that requires them.
I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that when we've failed to link things? In general, when libstdc++ isn't working for me in a cross configuration, it's usually because some early libstdc++ autoconf test has failed to link something, and therefore activated GNU_NO_EXECUTABLES, and then everything breaks. Usually, I've botched something in my environment so that the compiler can't link. In your case, you've not botched anything, but you know that your compiler can't link, so this goes back to the basic point that the environment that the libstdc++ configure script is seeing doesn't allow linking. As I've said earlier, inconvenient though I can see it might be in some situations, my preference is that we make it an invariant that (roughly speaking) $CC $CFLAGS *must* be able to link programs when we're configuring libstdc++. >> 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 suppose a small case statement could make reasonable guesses about > defaults, too. *-linux* yes, *-elf no, etc. Yes -- so long as whatever procedure we use is unaffected by cross/native/Canadian. (The case statement is what I meant by "hard-coded" answers.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
