Re: Fortran libraries on the Blue Gene with mpi
* Ralf Wildenhues wrote on Sun, Apr 19, 2009 at 09:11:27AM CEST: > Initial port for BlueGene BG/L. > > * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC, _LT_LINKER_SHLIBS) > (_LT_LANG_CXX_CONFIG) [linux]: Detect bgxl*, bgf*, mpixl* > compilers. > * NEWS: Update. > * THANKS: Update. > Report, feedback and testing by John R. Cary and Christian > Rössel. I've pushed this patch now, as it is a strict improvement, even if there are still a couple of unsolved issues. Cheers, Ralf
Re: Fortran libraries on the Blue Gene with mpi
Ralf Wildenhues wrote:
> * Christian Rössel wrote on Mon, Apr 27, 2009 at 05:33:33PM CEST:
>> Ralf Wildenhues wrote:
> # XL, BG
> cd build-bgxl
> ../configure CC=bgxlc CXX=bgxlC F77=bgfort FC=bgxlf95 GCJ=no \
>LDFLAGS=-qnostaticlink
> make
> make -k check VERBOSE=yes 2>&1 | tee checklog-bgxl-1
> cd ..
>>> This is where things start to get interesting.
>> With the bg* compilers we build programs that are supposed to be run on
>> the compute nodes. They may also run on the login-nodes, but you can't
>> take that for granted (AFAIR the error "Illegal instruction" appears if
>> you try to run a compute node program on a login node).
>
> Ah! I completely misunderstood that. That means that all those builds
> should run with cross-compiling enabled. Cross compilation mode is
> enabled when --host is passed (and differs from either the passed
> --build flag, or whatever configure computes as the build name);
> you can also force cross compilation mode through the hack of passing
> cross_compiling=yes
>
> to configure. The --host argument will also cause configure to look for
> all tool chain programs with a $host- prefix, in this case, with
> --host=powerpc-bgp-linux that would be powerpc-bgp-linux-gcc etc.
>
>> As all tests run
>> on the login-nodes, we should expect failures. Also, a test that
>> succeeds on the login node may not succeed on the compute node. IMHO all
>> test programs build with bg* and mpi* compilers should be run on the
>> compute nodes, not on the login nodes.
>
> Well, in this case they should not be run at all, at least not those
> that are run as part of the configure script.
>
>> To run a program on the compute nodes you write a batch script and
>> submit it to a queue. This process unfortunately differs from machine to
>> machine. It is also not sensible to submit many small jobs to the queue
>> as one job allocates at least 128 nodes.
>
> :-)
>
>> Maybe there is a way of calling
>> all tests from a single batch script so that one has to submit only one job.
>
> Not really. For those that failed on the login nodes, you can try to
> submit one or two to the queue; if they then pass, I'd be pretty
> confident that the others will work, too.
Hi Ralf, hi John,
I configured build-bgxl for cross compiling, reran the tests and found
two illegal instruction in the checklog:
f77demo-exec.test: === Running f77demo-exec.test
f77demo-exec.test: === Executing uninstalled programs in build-bgxl3
tests/defs: line 1132: 10739 Illegal instruction tests/f77demo/fprogram
f77demo-exec.test: ../tests/f77demo-exec.test: cannot execute
tests/f77demo/fprogram
f77demo-exec.test: === This may be ok since you seem to be cross-compiling.
fcdemo-exec.test: === Running fcdemo-exec.test
fcdemo-exec.test: === Executing uninstalled programs in build-bgxl3
tests/defs: line 1132: 20901 Illegal instruction tests/fcdemo/fprogram
fcdemo-exec.test: ../tests/fcdemo-exec.test: cannot execute
tests/fcdemo/fprogram
fcdemo-exec.test: === This may be ok since you seem to be cross-compiling.
I wanted to run these two on the compute nodes, but after finishing the
tests, the programs were gone.
>>> Test failures:
>>>
>>> - f77demo-* in the old testsuite
>>> This is because the bgfort command does not exist.
>>> It was a typo, should have been F77=bgfort77 or F77=bgf77 or F77=bgxlf
>>> I guess. If you have energy left, here's how you can rerun those
>>> tests:
>>>
>>>cd build-bgxl
>>>../configure CC=bgxlc CXX=bgxlC F77=bgfort77 FC=bgxlf95 GCJ=no \
>>> LDFLAGS=-qnostaticlink
>>>gmake
>>>gmake -k check VERBOSE=yes TESTSUITEFLAGS='-k F77' TESTS="\
>>> tests/f77demo-static.test \
>>> tests/f77demo-make.test \
>>> tests/f77demo-exec.test \
>>> tests/f77demo-conf.test \
>>> tests/f77demo-make.test \
>>> tests/f77demo-exec.test \
>>> tests/f77demo-shared.test \
>>> tests/f77demo-make.test \
>>> tests/f77demo-exec.test"
>> Please find the results attached (checklog-bgxl-2).
>
> Thanks. f77demo-exec.test fails after f77demo-static.test, and
> f77demo-make.test fails after f77demo-{conf,shared}.test. The first
> failure is an "Illegal instruction" again, for which we have an
> explanation now; the other two are again:
>
> /bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux/bin/ld: attempted
> static link of dynamic object `./.libs/libfoo.so'
>
> I still don't know the cause for this; but at least the F77 cases look
> just like the FC cases.
>
> Can you post the output of the following?
>
> cd build-bgxl/tests/fcdemo
> /bin/sh ./libtool --mode=link bgxlf95 -Wc,-v -g -qnostaticlink -o
> fprogram fprogram.o libfoo.la libfoo3.la -ldl
libtool: link:
LD_RUN_PATH="/u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/build-bgxl3/_inst/lib:"
bgxlf95 -Wl,-v -g -qnostaticlink -o .libs/fprogram fprogram.o
./.libs/lib
Re: Fortran libraries on the Blue Gene with mpi
* Christian Rössel wrote on Mon, Apr 27, 2009 at 05:33:33PM CEST:
> Ralf Wildenhues wrote:
> > However, as a minor note, the logs all show:
> >
> > | checking dependency style of xlc... none
> > [...]
> > | checking dependency style of xlC... none
> >
> > which is kind of weird. IIRC the XL compilers have working dependency
> > extraction mechanisms, which are detected by the Automake code. There
> > has been one bug fix in Automake's depcomp script, but it was limited to
> > the --disable-static case. It would be worthwhile to investigate this.
> to create dependency output use the option -M or -qmakedep. Here the
> relevant relevant part of the man page:
>
> -M Creates an output file that contains information to be
> included in a "make" description file. This is
> equivalent to specifying -qmakedep without a suboption.
>
> -qmakedep[=gcc]
> Creates an output file that contains targets suitable
> for inclusion in a description file for the make command
> that describes the dependencies of the main source file
> in the compilation.
> Specifying 'gcc' changes the format of the generated
> dependency file.
> Specifying -qmakedep without 'gcc' is equivalent to
> specifying -M.
Thanks. I will address this issue in a separate message, later.
Let's finish the Libtool bits first.
> >>> # XL, BG
> >>> cd build-bgxl
> >>> ../configure CC=bgxlc CXX=bgxlC F77=bgfort FC=bgxlf95 GCJ=no \
> >>>LDFLAGS=-qnostaticlink
> >>> make
> >>> make -k check VERBOSE=yes 2>&1 | tee checklog-bgxl-1
> >>> cd ..
> >
> > This is where things start to get interesting.
>
> With the bg* compilers we build programs that are supposed to be run on
> the compute nodes. They may also run on the login-nodes, but you can't
> take that for granted (AFAIR the error "Illegal instruction" appears if
> you try to run a compute node program on a login node).
Ah! I completely misunderstood that. That means that all those builds
should run with cross-compiling enabled. Cross compilation mode is
enabled when --host is passed (and differs from either the passed
--build flag, or whatever configure computes as the build name);
you can also force cross compilation mode through the hack of passing
cross_compiling=yes
to configure. The --host argument will also cause configure to look for
all tool chain programs with a $host- prefix, in this case, with
--host=powerpc-bgp-linux that would be powerpc-bgp-linux-gcc etc.
> As all tests run
> on the login-nodes, we should expect failures. Also, a test that
> succeeds on the login node may not succeed on the compute node. IMHO all
> test programs build with bg* and mpi* compilers should be run on the
> compute nodes, not on the login nodes.
Well, in this case they should not be run at all, at least not those
that are run as part of the configure script.
> To run a program on the compute nodes you write a batch script and
> submit it to a queue. This process unfortunately differs from machine to
> machine. It is also not sensible to submit many small jobs to the queue
> as one job allocates at least 128 nodes.
:-)
> Maybe there is a way of calling
> all tests from a single batch script so that one has to submit only one job.
Not really. For those that failed on the login nodes, you can try to
submit one or two to the queue; if they then pass, I'd be pretty
confident that the others will work, too.
> > Test failures:
> >
> > - f77demo-* in the old testsuite
> > This is because the bgfort command does not exist.
> > It was a typo, should have been F77=bgfort77 or F77=bgf77 or F77=bgxlf
> > I guess. If you have energy left, here's how you can rerun those
> > tests:
> >
> >cd build-bgxl
> >../configure CC=bgxlc CXX=bgxlC F77=bgfort77 FC=bgxlf95 GCJ=no \
> > LDFLAGS=-qnostaticlink
> >gmake
> >gmake -k check VERBOSE=yes TESTSUITEFLAGS='-k F77' TESTS="\
> > tests/f77demo-static.test \
> > tests/f77demo-make.test \
> > tests/f77demo-exec.test \
> > tests/f77demo-conf.test \
> > tests/f77demo-make.test \
> > tests/f77demo-exec.test \
> > tests/f77demo-shared.test \
> > tests/f77demo-make.test \
> > tests/f77demo-exec.test"
>
> Please find the results attached (checklog-bgxl-2).
Thanks. f77demo-exec.test fails after f77demo-static.test, and
f77demo-make.test fails after f77demo-{conf,shared}.test. The first
failure is an "Illegal instruction" again, for which we have an
explanation now; the other two are again:
/bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux/bin/ld: attempted static
link of dynamic object `./.libs/libfoo.so'
I still don't know the cause for this; but at least the F77 cases look
just like the FC cases.
Can you post the output of the following?
cd
Re: Fortran libraries on the Blue Gene with mpi
Hello Christian, John, >Ralf Wildenhues wrote: >> Create six build trees and build and run the Libtool test suites >> with each of the compiler combinations (the following assumes >> Bourne-shell syntax): >> >> mkdir build-gcc build-xl build-bgcc build-bgxl build-mpigcc build-mpixl > please find attached the logs (logs.tar.gz) except for bgcc. Thank you both for all your efforts. The message from Christian which I am quoting, and one from John, didn't make it to the list due to the size of the logs; I am going to summarize them inline with this reply, going along with Christian's log files and noting where John's differ (when applicable). >> # GCC, non-BG >> cd build-gcc >> ../configure CC=gcc CXX=g++ F77=g77 FC=gfortran GCJ=no >> make >> make -k check VERBOSE=yes 2>&1 | tee checklog-gcc-1 >> cd .. With these, all F77 and FC tests in both testsuite failed, as neither g77 nor gfortran seem to be installed on this system. All other tests pass, which is pretty good already. Nothing left to do here (unless you want to install these compilers). >> # XL, non-BG >> cd build-xl >> ../configure CC=xlc CXX=xlC F77=xlf FC=xlf95 GCJ=no >> make >> make -k check VERBOSE=yes 2>&1 | tee checklog-xl-1 >> cd .. All tests passed, both testsuites. Yay! However, as a minor note, the logs all show: | checking dependency style of xlc... none [...] | checking dependency style of xlC... none which is kind of weird. IIRC the XL compilers have working dependency extraction mechanisms, which are detected by the Automake code. There has been one bug fix in Automake's depcomp script, but it was limited to the --disable-static case. It would be worthwhile to investigate this. xlc and xlC understand -qpic and -qstaticlink, good. xlf only -qpic, but not -qstaticlink, oh well. >> # GCC, BG >> cd build-bgcc >> ../configure CC=bgcc CXX=bgc++ F77=bgf77 FC=bgfortran GCJ=no \ >>LDFLAGS=-dynamic >> make >> make -k check VERBOSE=yes 2>&1 | tee checklog-bgcc-1 >> cd .. > >configure failed: >## ## >## Configuring libtool (Build:1.3089 2009-03-29) 2.2.7a ## >## ## > >checking for a BSD-compatible install... /usr/bin/install -c >checking whether build environment is sane... yes >checking for a thread-safe mkdir -p... /bin/mkdir -p >checking for gawk... gawk >checking whether make sets $(MAKE)... yes >checking whether subdir libobjs are useable... yes >checking for gcc... bgcc >checking for C compiler default output file name... >configure: error: in >`/u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/build-bgcc': >configure: error: C compiler cannot create executables >See `config.log' for more details. > > >bgcc and bgcc_r are wrappers for pre-ANSI C. Don't know if it's worth >the effort to support this. Ah, I didn't know this. You could look into the build-bgcc/config.log file to find out the specific reason why this failed. But if these compilers aren't important anyway, then I won't mind if we ignore them. >> # XL, BG >> cd build-bgxl >> ../configure CC=bgxlc CXX=bgxlC F77=bgfort FC=bgxlf95 GCJ=no \ >>LDFLAGS=-qnostaticlink >> make >> make -k check VERBOSE=yes 2>&1 | tee checklog-bgxl-1 >> cd .. This is where things start to get interesting. bgxlc and bgxlC understand -qpic and -qstaticlink, good. bgxlf95 understands -qpic but not -qstaticlink; it however accepts the -qnostaticlink flag. Test failures: - f77demo-* in the old testsuite This is because the bgfort command does not exist. It was a typo, should have been F77=bgfort77 or F77=bgf77 or F77=bgxlf I guess. If you have energy left, here's how you can rerun those tests: cd build-bgxl ../configure CC=bgxlc CXX=bgxlC F77=bgfort77 FC=bgxlf95 GCJ=no \ LDFLAGS=-qnostaticlink gmake gmake -k check VERBOSE=yes TESTSUITEFLAGS='-k F77' TESTS="\ tests/f77demo-static.test \ tests/f77demo-make.test \ tests/f77demo-exec.test \ tests/f77demo-conf.test \ tests/f77demo-make.test \ tests/f77demo-exec.test \ tests/f77demo-shared.test \ tests/f77demo-make.test \ tests/f77demo-exec.test" - fcdemo-exec fails after fcdemo-static: | bgxlf95 -g -c -o fprogram.o /u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/tests/fcdemo/fprogram.f90 | ** fprogram === End of Compilation 1 === | 1501-510 Compilation successful for file fprogram.f90. | /bin/sh ./libtool --mode=link bgxlf95 -g -qnostaticlink -o fprogram fprogram.o libfoo.la libfoo3.la -ldl | libtool: link: bgxlf95 -g -qnostaticlink -o fprogram fprogram.o ./.libs/libfoo.a /u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/build-bgxl/tests/fcdemo/.libs/libfoo2.a ./.libs/libfoo3.a -ldl [...] | PASS: tests/fcdemo-make.test | fcdemo-exec.test: === Running fcdemo-
Re: Fortran libraries on the Blue Gene with mpi
* Christian Rössel wrote on Wed, Apr 22, 2009 at 06:28:51PM CEST: > > re-boostrapping works now but the missing makeinfo causes new problems: > > > > /u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/libltdl/config/missing: > > line 54: makeinfo: command not found > > WARNING: `makeinfo' is missing on your system. You should only need it if > > you modified a `.texi' or `.texinfo' file, or any other file > > indirectly affecting the aspect of the manual. The spurious > > call might also be the consequence of using a buggy `make' (AIX, > > DU, IRIX). You might want to install the `Texinfo' package or > > the `GNU make' package. Grab either from any GNU archive site. > > make[2]: *** [../doc/libtool.info] Error 1 > > > > I will install makeinfo to avoid further problems. > I installed makeinfo (texinfo-4.13) and re-bootstrapped ... Yeah, sorry about that, I should have known that you would also need to use make MAKEINFO=true > ... and ran into the next error: > > /u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/libltdl/config/missing: > line 54: help2man: command not found > WARNING: `help2man' is missing on your system. You should only need it if > you modified a dependency of a manual page. You may need the > `Help2man' package in order for those modifications to take > effect. You can get `Help2man' from any GNU archive site. > gmake[2]: *** [../doc/libtoolize.1] Error 1 > > After installing help2man I was able to run the tests. This, OTOH, is a bug that will be fixed in the next Automake release. The need for help2man will then only arise for "make dist", even with version control checkouts which contain no pre-generated man pages. However, for others encountering this bug: you can also work around it by repeatedly running "make" for a few times. I've pushed the patch for bootstrap now. Cheers, and thanks for persevering, Ralf
Re: Fortran libraries on the Blue Gene with mpi
Hello Christian, * Christian Rössel wrote on Wed, Apr 22, 2009 at 11:21:27AM CEST: > Ralf Wildenhues wrote: > > > First, please ensure that you have Autoconf 2.63 and Automake 1.10.2 > > installed somewhere (below the same --prefix) and found early in $PATH. > why do I need to install them below the *same* prefix. Is this a general > requirement? What will happen if I use distinct prefixes but put both > bindirs into my PATH? You don't *have* to install all autotools below the same prefix. However, we generally recommend this, because that way we avoid the questions of what *exactly* can go wrong and how, and what to do in those cases. ;-) I'll try a more precise description: it is usually possible to install Autoconf, Automake, Libtool, and other packages that provide macro files, below different prefixes. If you do so, however, then you need to ensure that aclocal (which is part of the Automake package) finds those third-party macro files which can reside at LIBTOOL_PREFIX/share/aclocal OTHER_PACKAGES_PREFIXES/share/aclocal The way I usually solve this is by using a "dirlist" file: I add the lines LIBTOOL_PREFIX/share/aclocal OTHER_PACKAGE1_PREFIX/share/aclocal OTHER_PACKAGE2_PREFIX/share/aclocal to the AUTOMAKE_PREFIX/share/aclocal/dirlist file, all prefixes suitably expanded of course. Subtle problems can appear if there is more than one set of Libtool macro files among the directories that aclocal searches, and they came from different Libtool releases; so please avoid that situation. Likewise for other third-party packages that provide macro files. Hope that helps. Cheers, Ralf
Re: Fortran libraries on the Blue Gene with mpi
Christian Rössel wrote: > Ralf Wildenhues wrote: >> * Christian Rössel wrote on Tue, Apr 21, 2009 at 10:28:37AM CEST: >>> Ralf Wildenhues wrote: >>> If there are any problems or error messages, stop right here and report back with them. Otherwise, continue: >>> There was one error I assume is negligible: >>> cd ./doc && \ >>> makeinfo --no-headers -o notes.txt notes.texi >>> /bin/sh: makeinfo: command not found >> Yes, the error itself should be harmless, but it has the problem of >> causing some other files not to be built. Please re-bootstrap with >> MAKEINFO=true ./bootstrap >> >> then there should be a libtoolize.in file afterwards, and you should be >> able to go on with the previous list, unless there are further errors. > > Hi Ralf, > > re-boostrapping works now but the missing makeinfo causes new problems: > > /u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/libltdl/config/missing: > line 54: makeinfo: command not found > WARNING: `makeinfo' is missing on your system. You should only need it if > you modified a `.texi' or `.texinfo' file, or any other file > indirectly affecting the aspect of the manual. The spurious > call might also be the consequence of using a buggy `make' (AIX, > DU, IRIX). You might want to install the `Texinfo' package or > the `GNU make' package. Grab either from any GNU archive site. > make[2]: *** [../doc/libtool.info] Error 1 > > I will install makeinfo to avoid further problems. Hi Ralf, I installed makeinfo (texinfo-4.13) and re-bootstrapped ... > # GCC, non-BG > cd build-gcc > ../configure CC=gcc CXX=g++ F77=g77 FC=gfortran GCJ=no > make ... and ran into the next error: /u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/libltdl/config/missing: line 54: help2man: command not found WARNING: `help2man' is missing on your system. You should only need it if you modified a dependency of a manual page. You may need the `Help2man' package in order for those modifications to take effect. You can get `Help2man' from any GNU archive site. gmake[2]: *** [../doc/libtoolize.1] Error 1 After installing help2man I was able to run the tests. Cheers, Christian
Re: Fortran libraries on the Blue Gene with mpi
On Wed, 22 Apr 2009, Christian Rössel wrote: Ralf Wildenhues wrote: First, please ensure that you have Autoconf 2.63 and Automake 1.10.2 installed somewhere (below the same --prefix) and found early in $PATH. why do I need to install them below the *same* prefix. Is this a general requirement? What will happen if I use distinct prefixes but put both bindirs into my PATH? Installation under the same prefix is necessary because the installed m4 files from the various packages share a directory and that is where aclocal looks for them. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Fortran libraries on the Blue Gene with mpi
Ralf Wildenhues wrote: > * Christian Rössel wrote on Tue, Apr 21, 2009 at 10:28:37AM CEST: >> Ralf Wildenhues wrote: >> >>> If there are any problems or error messages, stop right here and report >>> back with them. Otherwise, continue: >> There was one error I assume is negligible: >> cd ./doc && \ >> makeinfo --no-headers -o notes.txt notes.texi >> /bin/sh: makeinfo: command not found > > Yes, the error itself should be harmless, but it has the problem of > causing some other files not to be built. Please re-bootstrap with > MAKEINFO=true ./bootstrap > > then there should be a libtoolize.in file afterwards, and you should be > able to go on with the previous list, unless there are further errors. Hi Ralf, re-boostrapping works now but the missing makeinfo causes new problems: /u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/libltdl/config/missing: line 54: makeinfo: command not found WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[2]: *** [../doc/libtool.info] Error 1 I will install makeinfo to avoid further problems. > I'll apply the patch below to let the impact of missing 'makeinfo' be > less of a problem, if you let me know which email address to add to > THANKS. Use christian.roes...@gmx.de Cheers, Christian
Re: Fortran libraries on the Blue Gene with mpi
Ralf Wildenhues wrote: > First, please ensure that you have Autoconf 2.63 and Automake 1.10.2 > installed somewhere (below the same --prefix) and found early in $PATH. Hi Ralf, why do I need to install them below the *same* prefix. Is this a general requirement? What will happen if I use distinct prefixes but put both bindirs into my PATH? Regards, Christian
Re: Fortran libraries on the Blue Gene with mpi
* Christian Rössel wrote on Tue, Apr 21, 2009 at 10:28:37AM CEST: > Ralf Wildenhues wrote: > > Then, grab either the git master branch of the Libtool tree, or a > > nightly snapshot; the Libtool homepage has a link. Extract the tarball. > > > > Apply the patch at the end of this message to the Libtool tree, then run > > ./bootstrap > > I used the git branch but couldn't apply the patch via > patch -p1 < patchfile. So I did it manually. > > > If there are any problems or error messages, stop right here and report > > back with them. Otherwise, continue: > > There was one error I assume is negligible: > cd ./doc && \ > makeinfo --no-headers -o notes.txt notes.texi > /bin/sh: makeinfo: command not found Yes, the error itself should be harmless, but it has the problem of causing some other files not to be built. Please re-bootstrap with MAKEINFO=true ./bootstrap then there should be a libtoolize.in file afterwards, and you should be able to go on with the previous list, unless there are further errors. I'll apply the patch below to let the impact of missing 'makeinfo' be less of a problem, if you let me know which email address to add to THANKS. > > cd build-gcc > > ../configure CC=gcc CXX=g++ F77=g77 FC=gfortran GCJ=no > > configure complains > > "configure: error: cannot find sources (libtoolize.in) in .. or .." > > There is a libtoolize.m4sh in .. but not a libtoolize.in. Cheers, Ralf Cope better with missing `makeinfo' in `bootstrap'. * bootstrap: Update `./doc/notes.txt' last so missing `makeinfo' does not cause a broken tree. * THANKS: Update. Report by Christian Rössel. diff --git a/bootstrap b/bootstrap index 0b3648f..d505c36 100755 --- a/bootstrap +++ b/bootstrap @@ -132,9 +132,9 @@ $SED '/^if /,/^endif$/d;/^else$/,/^endif$/d;/^include /d' $makes > Makefile # configure, and ltversion.m4 to generate configure in the first place: rm -f $auxdir/ltmain.sh $m4dir/ltversion.m4 -$MAKE ./$auxdir/ltmain.sh ./$m4dir/ltversion.m4 ./doc/notes.txt \ +$MAKE ./$auxdir/ltmain.sh ./$m4dir/ltversion.m4 \ ./libtoolize.in ./tests/defs.in ./tests/package.m4 \ -./tests/testsuite ./libltdl/Makefile.am \ +./tests/testsuite ./libltdl/Makefile.am ./doc/notes.txt \ srcdir=. top_srcdir=. PACKAGE="$2" VERSION="$3" \ PACKAGE_BUGREPORT="bug...@gnu.org" M4SH="$AUTOM4TE --language=m4sh" \ AUTOTEST="$AUTOM4TE --language=autotest" SED="$SED" MAKEINFO="$MAKEINFO" \
Re: Fortran libraries on the Blue Gene with mpi
Ralf Wildenhues wrote: > [ adding the libtool-patches list, moving libtool list to Bcc: so you > can omit it from followups ] > > Hello John, Christian, > > thanks to both of you for all your feedback so far. > > We have a pretty good idea of what is happening for the C compilers now, > but the C++ and the Fortran compilers still need research. Also, I'm > not sure yet how to integrate the -qnostaticlink flag automatically, so > for now let's do it manually. > > Below is a first cut at a patch to add support for BG to Libtool. > I would like you to test it for me. This is going to be a bit of work, > as it will involve several steps. Please try to follow them all. > > First, please ensure that you have Autoconf 2.63 and Automake 1.10.2 > installed somewhere (below the same --prefix) and found early in $PATH. Hi Ralf, in order to configure autoconf I needed to install GNU m4. Then everything went fine. > Then, grab either the git master branch of the Libtool tree, or a > nightly snapshot; the Libtool homepage has a link. Extract the tarball. > > Apply the patch at the end of this message to the Libtool tree, then run > ./bootstrap I used the git branch but couldn't apply the patch via patch -p1 < patchfile. So I did it manually. > If there are any problems or error messages, stop right here and report > back with them. Otherwise, continue: There was one error I assume is negligible: cd ./doc && \ makeinfo --no-headers -o notes.txt notes.texi /bin/sh: makeinfo: command not found > Create six build trees and build and run the Libtool test suites > with each of the compiler combinations (the following assumes > Bourne-shell syntax): > > mkdir build-gcc build-xl build-bgcc build-bgxl build-mpigcc build-mpixl > > # GCC, non-BG > cd build-gcc > ../configure CC=gcc CXX=g++ F77=g77 FC=gfortran GCJ=no configure complains "configure: error: cannot find sources (libtoolize.in) in .. or .." There is a libtoolize.m4sh in .. but not a libtoolize.in. What shall I do? Cheers, Christian --- --- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Prof. Dr. Sebastian M. Schmidt --- ---
Re: Fortran libraries on the Blue Gene with mpi
[ adding the libtool-patches list, moving libtool list to Bcc: so you can omit it from followups ] Hello John, Christian, thanks to both of you for all your feedback so far. We have a pretty good idea of what is happening for the C compilers now, but the C++ and the Fortran compilers still need research. Also, I'm not sure yet how to integrate the -qnostaticlink flag automatically, so for now let's do it manually. Below is a first cut at a patch to add support for BG to Libtool. I would like you to test it for me. This is going to be a bit of work, as it will involve several steps. Please try to follow them all. First, please ensure that you have Autoconf 2.63 and Automake 1.10.2 installed somewhere (below the same --prefix) and found early in $PATH. Then, grab either the git master branch of the Libtool tree, or a nightly snapshot; the Libtool homepage has a link. Extract the tarball. Apply the patch at the end of this message to the Libtool tree, then run ./bootstrap If there are any problems or error messages, stop right here and report back with them. Otherwise, continue: Create six build trees and build and run the Libtool test suites with each of the compiler combinations (the following assumes Bourne-shell syntax): mkdir build-gcc build-xl build-bgcc build-bgxl build-mpigcc build-mpixl # GCC, non-BG cd build-gcc ../configure CC=gcc CXX=g++ F77=g77 FC=gfortran GCJ=no make make -k check VERBOSE=yes 2>&1 | tee checklog-gcc-1 cd .. # XL, non-BG cd build-xl ../configure CC=xlc CXX=xlC F77=xlf FC=xlf95 GCJ=no make make -k check VERBOSE=yes 2>&1 | tee checklog-xl-1 cd .. # GCC, BG cd build-bgcc ../configure CC=bgcc CXX=bgc++ F77=bgf77 FC=bgfortran GCJ=no \ LDFLAGS=-dynamic make make -k check VERBOSE=yes 2>&1 | tee checklog-bgcc-1 cd .. # XL, BG cd build-bgxl ../configure CC=bgxlc CXX=bgxlC F77=bgfort FC=bgxlf95 GCJ=no \ LDFLAGS=-qnostaticlink make make -k check VERBOSE=yes 2>&1 | tee checklog-bgxl-1 cd .. # GCC, MPI cd build-mpigcc ../configure CC=mpicc CXX=mpicxx F77=mpif77 FC=mpif90 GCJ=no \ LDFLAGS=-dynamic make make -k check VERBOSE=yes 2>&1 | tee checklog-mpigcc-1 cd .. # XL, MPI cd build-mpixl ../configure CC=mpixlc CXX=mpixlC F77=mpixlf FC=mpixlf95 GCJ=no \ LDFLAGS=-qnostaticlink make make -k check VERBOSE=yes 2>&1 | tee checklog-mpixl-1 cd .. I might have added some typos above, so if you happen to see obvious errors, feel free to correct them (e.g., I'm not sure whether bgfort is an XL or GCC Fortran compiler). If any of the configure runs fail due to failure to guess the system type, then please try adding --host=powerpc-bgp-linux --build=powerpc-bgp-linux and if that still causes bogus run time test results, you can also try --host=powerpc-bgp-linux --build=powerpc-unknown-linux to force cross-compilation mode. For each directory, send the corresponding checklog-* file plus the tests/testsuite.log file, please. Best if you put these files in a tarball, gzip- or bzip2-compressed. Thanks, Ralf Initial port for BlueGene BG/L. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC, _LT_LINKER_SHLIBS) (_LT_LANG_CXX_CONFIG) [linux]: Detect bgxl*, bgf*, mpixl* compilers. * NEWS: Update. * THANKS: Update. Report, feedback and testing by John R. Cary and Christian Rössel. diff --git a/NEWS b/NEWS index 546766d..3fe8f14 100644 --- a/NEWS +++ b/NEWS @@ -21,6 +21,7 @@ New in 2.2.8 2009-??-??: git version 2.2.7a, Libtool team: - Improved support for 64bit Windows (mingw64). - Improved support for cegcc (Windows CE/PocketPC). - Support for GNU/kOpenSolaris (kopensolaris*-gnu). + - Initial support for compilers on BlueGene BG/L. * Bug fixes: diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 75675b8..c3cffa1 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -3680,8 +3680,8 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_pic, $1)= _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared' ;; - xlc* | xlC*) - # IBM XL 8.0 on PPC + xlc* | xlC* | bgxl[[cC]]* | mpixl[[cC]]*) + # IBM XL 8.0, 9.0 on PPC and BlueGene _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' _LT_TAGVAR(lt_prog_compiler_pic, $1)='-qpic' _LT_TAGVAR(lt_prog_compiler_static, $1)='-qstaticlink' @@ -3964,8 +3964,8 @@ m4_if([$1], [CXX], [ # All Alpha code is PIC. _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared' ;; - xl*) - # IBM XL C 8.0/Fortran 10.1 on PPC + xl* | bgxl* | bgf* | mpixl*) + # IBM XL C 8.0/Fortran 10.1, 11.1 on PPC and BlueGene _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' _LT_TAGVAR(lt_prog_compiler_pic, $1)='-qpic' _LT_TAGVAR(lt_prog_compiler_static, $1)='-qstaticlink' @@ -4343,7 +4343,7 @@ _LT_EOF lf95*)
