Re: libstdc++ in a combined tree
Benjamin Kosnik wrote: I apologize; I didn't realize that. In that case, you're right; the current approach is just busted. It should become an --enable option, or a hard-coded case statement, or an autoconf test that doesn't require linking stuff. Really? Like --enable-symvers[=style]? http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html DJ said that libstdc++ was doing something inconsistent: forbidding link tests for cross-compilation, and then doing a link test anyways. Daniel says that's not what actually happens, which means that my just busted comment is incorrect; that was a description of the situation as it would have been had DJ been correct. My comments about how to fix the hypothetical problem were meant to be general comments, not specific comments about symbol versions. If there's already an option, then we've already got one of the solutions I was suggesting. In general, I just want to make sure we don't do things that make cross or Canadian-cross builds behave differently from native compilation. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: libstdc++ in a combined tree
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
Re: libstdc++ in a combined tree
The key problem is that we have two ways And then he lists *three* ;-) * Hard-coded information about the target I seem to recall a long time ago, talk of a global target capabilities database. It proved too unwieldy to implement. However, a toplevel configury snippet (aka config.gcc) might (1) prove useful, and (2) speed up configure. To me, it ought to be a fundamental invariant that the same features are enabled for cross and native compilation. That would be a good goal. To accomplish that, we need to avoid autoconf tests for features that require running target programs; The problem I'm running into is that I can't even *link* a target program at that point. The C library (including crt0 and linker scripts) have not yet been installed. 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. Such as --enable-libfoo-a ? 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++. We normally pass the newlib -I/-L, but in my case, I also need to point into libgloss for a few things. That gets nasty as there's no consistency there.
Re: libstdc++ in a combined tree
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. Personally, I'd just not do a one-tree build. :-) But, I know that's popular with lots of folks, for various reasons, including not having to build the compiler twice. Right, our internal trees are *all* one-tree builds. It's vastly simpler to just do ./configure; make; make install than all the nastiness needed to bootstrap a cross compiler. It still won't fix the libstdc++ bug, nor does it catch the libgloss bits. (One big-hammer solution there is to revive the staged install proposal, where you would do something like make install DESTDIR=$objdir/install after building each component, so that Newlib, libgloss, etc., would already be in this staging area, before building libstdc++. I think that would simplify a lot of our Makefiles -- but, of course, necessitate a fair bit of change.) DJGPP builds this way. The actual Makefile targets *are* in the local install tree, so they get built-in-place. Then you just cp -rp the bits you need (or in djgpp's case, zip them together for distribution).
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 [EMAIL PROTECTED] (650) 331-3385 x713
Re: libstdc++ in a combined tree
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. 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.
Re: libstdc++ in a combined tree
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
Re: libstdc++ in a combined tree
I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that when we've failed to link things? No, it's explicit: if test $build != $host; then # We are being configured with some form of cross compiler. GLIBCXX_IS_NATIVE=false case $host,$target in *-*-darwin*,*-*-darwin*) . . . ;; *) GCC_NO_EXECUTABLES ;; esac else GLIBCXX_IS_NATIVE=true fi (remember that $host here is the toplevel $target)
Re: libstdc++ in a combined tree
DJ Delorie wrote: I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that when we've failed to link things? No, it's explicit: I apologize; I didn't realize that. In that case, you're right; the current approach is just busted. It should become an --enable option, or a hard-coded case statement, or an autoconf test that doesn't require linking stuff. In my ideal world, we wouldn't set GCC_NO_EXECUTABLES because we'd be able to link by this point, but I guess it must be there to support exactly the kind of environment you're in. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: libstdc++ in a combined tree
On Fri, 28 Apr 2006, DJ Delorie wrote: I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that when we've failed to link things? No, it's explicit: if test $build != $host; then # We are being configured with some form of cross compiler. GLIBCXX_IS_NATIVE=false case $host,$target in *-*-darwin*,*-*-darwin*) . . . ;; *) GCC_NO_EXECUTABLES I hadn't realised there was such configuration separate from crossconfig.m4. This setting of GCC_NO_EXECUTABLES is out of date in that we do now expect to be able to do link tests for glibc and uClibc targets and there's been no sign of complaints about problems arising from this. (I don't think you can ever build a correct shared libstdc++ on a glibc system without the shared glibc already being there to link the shared libstdc++ against. And the functions present in uClibc depend on how it was configured, making link checks essential.) -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: libstdc++ in a combined tree
On Fri, Apr 28, 2006 at 08:36:50PM -0400, 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. Incorrect. Take a look at the implementation of GCC_NO_EXECUTABLES, please: AS_IF([AC_TRY_EVAL(ac_link)], [gcc_no_link=no], [gcc_no_link=yes]) It sets gcc_no_link based on a link test. If the link test succeeds, then future link tests are allowed. If the link test fails, then future link tests are a fatal error (instead of just reporting the feature being tested for as missing). So if you really have enough to link, then it ought to work fine. What are you building here? A combined tree including newlib? If so, I bet you aren't specifying --with-newlib; that turns off a bunch of link tests. Newlib is special because we arrange to build libstdc++-v3 before building newlib. That we require the configure option is somewhat lame. -- Daniel Jacobowitz CodeSourcery
Re: libstdc++ in a combined tree
What are you building here? A combined tree including newlib? If so, I bet you aren't specifying --with-newlib; that turns off a bunch The toplevel configure automatically adds that in a combined tree (or at least it should), if newlib is being built. The two targets I'm currently working with are m32c-elf and sh-elf. For m32c-elf I added the -I/-L options, thinking it was unique. When sh-elf did similar things I realized otherwise. I'm currently working through a canadian and discovering other problems. We really need to test these things more often :-P
Re: libstdc++ in a combined tree
I apologize; I didn't realize that. In that case, you're right; the current approach is just busted. It should become an --enable option, or a hard-coded case statement, or an autoconf test that doesn't require linking stuff. Really? Like --enable-symvers[=style]? http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html Of course, the issue of the C library remains. -benjamin
Re: libstdc++ in a combined tree
On Fri, Apr 28, 2006 at 11:21:18PM -0400, DJ Delorie wrote: What are you building here? A combined tree including newlib? If so, I bet you aren't specifying --with-newlib; that turns off a bunch The toplevel configure automatically adds that in a combined tree (or at least it should), if newlib is being built. Can you verify that this really happened? I know I've had to specify it manually recently. The two targets I'm currently working with are m32c-elf and sh-elf. For m32c-elf I added the -I/-L options, thinking it was unique. When sh-elf did similar things I realized otherwise. I'm currently working through a canadian and discovering other problems. We really need to test these things more often :-P Frankly, people who are interested in using the combined tree build process need to test it - just like you're doing. There's just too many possible configurations. -- Daniel Jacobowitz CodeSourcery
