Libstdc++ configuration assumes that libgcc and libgomp have been configured and built before libstdc++ configure is run. This is wrong, and pessimizes configure tests for parallel mode and symbol versioning. In particular, on AIX libgomp is built but libstdc++'s parallel mode is disabled because of this.
Let's add in CC a couple of build machinery maintainers, maybe we can get some help...
(In reply to comment #0) > Libstdc++ configuration assumes that libgcc and libgomp have been configured > and built before libstdc++ configure is run. > > This is wrong, What do you mean with "this is wrong"? Is it wrong for libstdc++ configuration to depend on libgcc and libgomp? Or it is that the toplevel Makefile doesn't have the proper dependencies in place to ensure that libgcc and libgomp really are built before libstdc++ configure is started. The latter ought to be fairly easy to fix. In fact, toplevel Makefile.def already has dependencies = { module=configure-target-libstdc++-v3; on=configure-target-libgomp; }; so changing that to depend on all-target-libgomp and adding a similar statement for libgcc ought to fix that then.
That idea of yours Ralf makes perfect sense to me, actually, I was wondering whether a fix wasn't something like that. Are you willing to go ahead that way?
Yes, sure. But I would like to know a couple of things first: Does that mean, when libstdc++ is built in early bootstrap stages (e.g., for --enable-build-with-cxx), it is not necessary to have libgomp first? Then, please show how the failure manifests itself/how I can confirm/reproduce it. Even if the patch is simple then having a way to ensure it works helps. Thanks.
Ralf, make sure the submitter of 42813 pays attention to your comments, maybe add to that audit trail, instead of this one.
The configuration test can be replaced with some configure / makefile hackery, but this doesn't help: he compilation of libstdc++-v3 also depends on the header file: /bin/sh ../libtool --tag CXX --mode=compile /user/inria/fsf/bld-gcc-cxx13/./gcc/xgcc -shared-libgcc -B/user/inria/fsf/bld-gcc-cxx13/./gcc -nostdinc++ -L/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/src -L/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/user/inria/cxx/i686-pc-linux-gnu/bin/ -B/user/inria/cxx/i686-pc-linux-gnu/lib/ -isystem /user/inria/cxx/i686-pc-linux-gnu/include -isystem /user/inria/cxx/i686-pc-linux-gnu/sys-include -I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include -I/user/inria/fsf/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -fopenmp -D_GLIBCXX_PARALLEL -I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/../libgomp -c ../../../../gcc/libstdc++-v3/src/parallel_list.cc libtool: compile: /user/inria/fsf/bld-gcc-cxx13/./gcc/xgcc -shared-libgcc -B/user/inria/fsf/bld-gcc-cxx13/./gcc -nostdinc++ -L/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/src -L/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/user/inria/cxx/i686-pc-linux-gnu/bin/ -B/user/inria/cxx/i686-pc-linux-gnu/lib/ -isystem /user/inria/cxx/i686-pc-linux-gnu/include -isystem /user/inria/cxx/i686-pc-linux-gnu/sys-include -I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include -I/user/inria/fsf/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -fopenmp -D_GLIBCXX_PARALLEL -I/user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/../libgomp -c ../../../../gcc/libstdc++-v3/src/parallel_list.cc -fPIC -DPIC -o .libs/parallel_list.o In file included from /user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/parallel/algobase.h:40:0, from /user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:1155, from /user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/list:61, from ../../../../gcc/libstdc++-v3/src/list.cc:51, from ../../../../gcc/libstdc++-v3/src/parallel_list.cc:25: /user/inria/fsf/bld-gcc-cxx13/i686-pc-linux-gnu/libstdc++-v3/include/parallel/base.h:37:17: fatal error: omp.h: No such file or directory
At this time I don't know --enable-build-with-cxx enough to contribute much to the solution of the specific issue having to to with that configure option, just wanted to point out that normal uses of the library don't need the parallel mode facilities, thus anything having to do with it could be left out, in particular src/parallel_list.cc. I'm assuming of course that even when that option is used eventually a normal C++ library is built and installed. Anyway, the issue here, in this specific PR, seems different, is about building libgomp before libstdc++-v3 in normal GCC builds and I'm not sure that this makes sense also with --enable-build-with-cxx...
I've looked at 42813 now. It indicates that configure-target-libstdc++-v3 depends upon configure-target-libgomp (which creates libgomp/omp.h), but I don't see why it should depend upon all-target-libgomp. The former dependency however is already recorded in the current Makefile.def. So I'm not sure what is happening here.
Created attachment 19674 [details] experimental patch to remove dependency of configure-target-libstdc++-v3 on configure-target-libgomp As the dependency of the parallel*.cc files on omp.h was not immediately apparent - I looked at a few levels, but gave up as following all the loose ends would have been more work than just trying it - I made a patch to remove the configure dependency. And, as stated before, I had a manifest build failure then.
(In reply to comment #7) > At this time I don't know --enable-build-with-cxx enough to contribute much to > the solution of the specific issue having to to with that configure option, > just wanted to point out that normal uses of the library don't need the > parallel mode facilities, thus anything having to do with it could be left out, > in particular src/parallel_list.cc. I'm assuming of course that even when that > option is used eventually a normal C++ library is built and installed. This is actually a very good case in point for 'recursive make considered harmful' . We have individual files in libiberty depending on an individual header file from another library. If instead of all these sub-makes, we had one big make with a makefile that includes all the sub-makefiles so that it can see the dependencies at once, it would be straightforward to specify the exact dependency. I also suspect that the original ordering problem from pr42813 stems from --enable-build-with-cxx introducing some dependency of libgomp on libstdc++-v3, and then make drops one edge from the circular dependency.
So, sorry if I'm missing some steps in the reasoning, do I understand correctly that with your experimental patch the problems would be solved?
(In reply to comment #11) > So, sorry if I'm missing some steps in the reasoning, do I understand correctly > that with your experimental patch the problems would be solved? No, it removes the dependency of configure-libgomp, but then the build of libgomp fails because the header file is needed there.
I see... But then, would not be a libstdc++-v3 problem anymore, right?
(In reply to comment #13) > I see... But then, would not be a libstdc++-v3 problem anymore, right? Wrong. You just worsen the race condition with parallel builds. I can look into this in more detail, but only this weekend at the earliest.
Wrong submitter's proposal, you mean.
> Wrong submitter's proposal, you mean. Yes. What I don't understand is, why is anything else than this needed: -target_modules = { module= libgomp; lib_path=.libs; }; +target_modules = { module= libgomp; + bootstrap= true; + lib_path=.libs; }; ... +dependencies = { module=all-target-libstdc++-v3; on=all-target-libgomp; }; +dependencies = { module=all-target-libstdc++-v3; on=all-target-libgcc; }; ?
(In reply to comment #16) > > Wrong submitter's proposal, you mean. > > Yes. What I don't understand is, why is anything else than this needed: > > -target_modules = { module= libgomp; lib_path=.libs; }; > +target_modules = { module= libgomp; > + bootstrap= true; > + lib_path=.libs; }; Will this make the libgomp->libstdc++-v3 dependencies work? I'm testing this now... > +dependencies = { module=all-target-libstdc++-v3; on=all-target-libgomp; }; omp.h is created by the libgomp configure script, so configuring libgomp should be enough. I.e.: dependencies = { module=all-target-libstdc++-v3; on=configure-target-libgomp; }; In fact, I tried this before, but the dependency was ignored. I just tried that with your change above at the top, and the dependency is still ignored. Or are dependencies on all-target-* treated differently that dependencies on configure-target-* ? > +dependencies = { module=all-target-libstdc++-v3; on=all-target-libgcc; }; I can't find a current dependency on libgcc, but I don't see any breakage from the lack of one. Do you know why?
Subject: Re: deps on other host libraries incorrect On 01/21/2010 04:29 PM, amylaar at gcc dot gnu dot org wrote: > dependencies = { module=all-target-libstdc++-v3; > on=configure-target-libgomp; }; > > In fact, I tried this before, but the > dependency was ignored. I just tried that with your change above at > the top, and the dependency is still ignored. Yes, marking libgomp as bootstrappable should make a difference. I suggest looking at Makefile.in differences from my patches (in the dependencies section). > Or are dependencies on all-target-* treated differently that > dependencies on configure-target-* ? >>> +dependencies = { module=all-target-libstdc++-v3; >>> on=all-target-libgcc; }; > I can't find a current dependency on libgcc, but I don't see any > breakage from the lack of one. Do you know why? Dependencies on all-target-libgcc are automatic, so it's not needed. Paolo
(In reply to comment #18) > Yes, marking libgomp as bootstrappable should make a difference. I > suggest looking at Makefile.in differences from my patches (in the > dependencies section). The libgomp bootstrap rules are conditional on: @if target-libgomp-bootstrap and this is decided in configure without regard to the contents of Makefile.def . I have a patch to hack the dependency of libstdc++-v3 on libgomp into configure.ac . configure(.ac) uses language fragments, but these are not really appropriate for dependencies: libgomp belongs to the C language, but it needs to be bootstrapped when libstdc++-v3 is boostrapped - which may or may not be the case when the C++ language is enabled. If someone has some spare time, (s)he can rewrite that bit of configure machinery to use Makefile.def .
(In reply to comment #19) > I have a patch to hack the dependency of libstdc++-v3 on libgomp into > configure.ac . I have posted this patch together with the other Makefile* / configure* patches for PR libstdc++/42813: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01168.html
Subject: Bug 36101 Author: amylaar Date: Fri Jan 22 13:35:38 2010 New Revision: 156172 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156172 Log: PR libstdc++/36101, PR libstdc++/42813 [toplevel]: * configure.ac (target_configdirs): Substitute. * Makefile.def: Bootstrap target module libgomp. Add dependency of all-target-libstdc++-v3 on configure-target-libgomp. * Makefile.tpl (TARGET_CONFIGDIRS): New makefile variable. (BASE_TARGET_EXPORTS): Export TARGET_CONFIGDIRS. * configure, Makefile.in: Regenerate. libstdc++-v3: * acinclude.m4: (enable_parallel): Test ${TARGET_CONFIGDIRS} instead of loking for omp.h . * configure: Regenerate. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/Makefile.tpl trunk/configure trunk/configure.ac trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
I see that the patch is in. Excellent. I understand the other PR is completely fixed by now, thus I would suggest closing it as fixed. I would also suggest writing a oouple of sentences in the audit trail here, clarifying why the fix is partial, and what is still missing.
(In reply to comment #22) > I see that the patch is in. Excellent. I understand the other PR is completely > fixed by now, thus I would suggest closing it as fixed. No, it isn't. In fact, --enable-build-with-cxx won't bootstrap now, it fails with: /bin/sh ../libtool --tag CXX --mode=compile /user/inria/fsf/bld-gcc-cxx21/./gcc/xgcc -shared-libgcc -B/user/inria/fsf/bld-gcc-cxx21/./gcc -nostdinc++ -L/user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/src -L/user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/user/inria/cxx/i686-pc-linux-gnu/bin/ -B/user/inria/cxx/i686-pc-linux-gnu/lib/ -isystem /user/inria/cxx/i686-pc-linux-gnu/include -isystem /user/inria/cxx/i686-pc-linux-gnu/sys-include -I/user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/include -I/user/inria/fsf/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -fopenmp -D_GLIBCXX_PARALLEL -I/user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/../libgomp -c ../../../../gcc/libstdc++-v3/src/parallel_list.cc libtool: compile: /user/inria/fsf/bld-gcc-cxx21/./gcc/xgcc -shared-libgcc -B/user/inria/fsf/bld-gcc-cxx21/./gcc -nostdinc++ -L/user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/src -L/user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/user/inria/cxx/i686-pc-linux-gnu/bin/ -B/user/inria/cxx/i686-pc-linux-gnu/lib/ -isystem /user/inria/cxx/i686-pc-linux-gnu/include -isystem /user/inria/cxx/i686-pc-linux-gnu/sys-include -I/user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/include -I/user/inria/fsf/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -fopenmp -D_GLIBCXX_PARALLEL -I/user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/../libgomp -c ../../../../gcc/libstdc++-v3/src/parallel_list.cc -fPIC -DPIC -o .libs/parallel_list.o In file included from /user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/include/parallel/algobase.h:40:0, from /user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:1155, from /user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/include/list:61, from ../../../../gcc/libstdc++-v3/src/list.cc:51, from ../../../../gcc/libstdc++-v3/src/parallel_list.cc:25: /user/inria/fsf/bld-gcc-cxx21/i686-pc-linux-gnu/libstdc++-v3/include/parallel/base.h:37:17: fatal error: omp.h: No such file or directory
So I misinterpreted your ChangeLog, the adjective <partial> is referred to both ;) Still, some sort of summary together with the partial commit could be useful.
Created attachment 19696 [details] patch to make --enable-build-with-cxx bootstrap work I am currently using this patch in addition to the patch for PR42798 in order to make --enable-build-with-cxx bootstrap work.
(In reply to comment #24) > So I misinterpreted your ChangeLog, the adjective <partial> is referred to both > ;) The 'partial' was in my patch submission to gcc-patches, and that patch completely fixed pr42813, while it was only a partial fix for pr36101. However, you asked me not to include the change to configure.ac that made sure that the libgomp bootstrap rules would be emitted; you said that you would take care of always bootstrap libgomp, but so far you didn't.
Subject: Re: deps on other host libraries incorrect On 01/22/2010 08:17 PM, amylaar at gcc dot gnu dot org wrote: > ------- Comment #25 from amylaar at gcc dot gnu dot org 2010-01-22 19:17 ------- > Created an attachment (id=19696) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19696&action=view) > patch to make --enable-build-with-cxx bootstrap work > > I am currently using this patch in addition to the patch for PR42798 in order > to make --enable-build-with-cxx bootstrap work. The patch is exactly what I had planned to test and checkin. Please go ahead and commit it to both gcc and src. > However, you asked me not to include the change to configure.ac that made > sure that the libgomp bootstrap rules would be emitted; you said that you > would take care of always bootstrap libgomp, but so far you didn't. You were talking to the wrong Paolo. :-) Carlini is the libstdc++-v3 maintainer, Bonzini (me) is the build maintainer. Paolo
Subject: Bug 36101 Author: amylaar Date: Sat Jan 23 11:17:30 2010 New Revision: 156189 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156189 Log: PR libstdc++/36101, PR libstdc++/42813 * configure.ac (bootstrap_target_libs): Include target-libgomp. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
Subject: Bug 36101 Author: amylaar Date: Mon Jan 25 18:01:29 2010 New Revision: 156218 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156218 Log: PR libstdc++/36101, PR libstdc++/42813 * configure.ac (bootstrap_target_libs): Make inclusion of target-libgomp conditional on libgomb being in target_configdirs. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
I'm looking for an update on its status: how do we stand? What is still missing? Thanks in advance.
I think it's fixed?
Yes, that was also my guess. If somebody disagrees please explain and re-open, thanks a lot.