Re: [OMPI devel] Open MPI 1.8: link problem when Fortran+C+Platform LSF
Jeff and All, Belated Merry Christmas and a Happy New Year! And now we can be back to business :) I did some additional tests with versions installed on our cluster (1.8.3 ++ 1.8.4) and I *believe* I can confirm, that the problem seem to be not rooted on LSF support and yessir, adding "-lbat -llsf" is not a solution but a weird "workaround" which is not a real true workaround(*), as you wrote. Back to error description: a) the problem only arise in 1.8.x series when configured with these flags: > --disable-dlopen --disable-mca-dso We add these flags since early 2012 in order to minimise the NFS activity at start-up time. In the 1.6.x versions we *probably* do not see the error due to (*) - yessir, 'libbat.so' and 'liblsf.so' contain all the symbols missed and as these two libs are linked in by default prior 1.8.x, there is the mess you described below (symbols from libbat.so and liblsf.so *probably* used instead of symbols in the code). b) the problem vanish when > --as-needed command is passed to the linker: $ mpif90 -o example main.o y.tab.o mymain.o lex.yy.o -Wl,--as-needed c) yes it seem to be a general linkage issue: the behaviour of Intel compiler is the same as of GCC and studio compilers. a bit logs: version 1.8.3, configured with "--disable-dlopen --disable-mca-dso" $ mpif90 -o example main.o y.tab.o mymain.o lex.yy.o -showme ifort -o example main.o y.tab.o mymain.o lex.yy.o -I/opt/MPI/openmpi-1.8.3/linux/intel/include -fexceptions -I/opt/MPI/openmpi-1.8.3/linux/intel/lib -L/opt/lsf/9.1/linux2.6-glibc2.3-x86_64/lib -Wl,-rpath -Wl,/opt/lsf/9.1/linux2.6-glibc2.3-x86_64/lib -Wl,-rpath -Wl,/opt/MPI/openmpi-1.8.3/linux/intel/lib -Wl,--enable-new-dtags -L/opt/MPI/openmpi-1.8.3/linux/intel/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi (===> error) (===> add -Wl,--as-needed) $ mpif90 -o example main.o y.tab.o mymain.o lex.yy.o -Wl,--as-needed -showme ifort -o example main.o y.tab.o mymain.o lex.yy.o -Wl,--as-needed -I/opt/MPI/openmpi-1.8.3/linux/intel/include -fexceptions -I/opt/MPI/openmpi-1.8.3/linux/intel/lib -L/opt/lsf/9.1/linux2.6-glibc2.3-x86_64/lib -Wl,-rpath -Wl,/opt/lsf/9.1/linux2.6-glibc2.3-x86_64/lib -Wl,-rpath -Wl,/opt/MPI/openmpi-1.8.3/linux/intel/lib -Wl,--enable-new-dtags -L/opt/MPI/openmpi-1.8.3/linux/intel/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi (===> OK) (===> try to remove the LSF linking stuff at all:) ifort -o example main.o y.tab.o mymain.o lex.yy.o -Wl,--as-needed -I/opt/MPI/openmpi-1.8.3/linux/intel/include -fexceptions -I/opt/MPI/openmpi-1.8.3/linux/intel/lib -Wl,-rpath -Wl,/opt/MPI/openmpi-1.8.3/linux/intel/lib -Wl,--enable-new-dtags -L/opt/MPI/openmpi-1.8.3/linux/intel/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi (===> OK) (the same line as above but without -Wl,--as-needed ===> error). now the fun fact: omitting all the Open MPI part, > ifort -o example main.o y.tab.o mymain.o lex.yy.o lead to OK linking (the compiled app is not an MPI app). Recap: 1) - the error is related to configure with '--disable-dlopen --disable-mca-dso' 2) - the error vanishes when added '-Wl,--as-needed' to the link line 3) - the error is not special to any compiler or version 4) - the error is not related to LSF but linking with these libs just shut down it due to some symbols mess Well, I'm not really sure that (2) is the true workaround, or just starts some more library deep search and binds to LSF libs linked in somewhere in the bush. Could someone with moar xperience in linking libs and especially Open MPI take a look at this? (sorry for pushing this, but all this smells for me being an general linking problem rooted somewhere in Open MPI and '--disable-dlopen', see "fun fact" above) best Paul Kapinos P.S. Never used "-fPIC" here On 12/01/14 20:48, Jeff Squyres (jsquyres) wrote: Paul -- Sorry for the delay -- SC and the US Thanksgiving holiday last week got in the way of responding to this properly. I talked with Dave Goodell about this issue a bunch today. Going back to the original email in this thread (http://www.open-mpi.org/community/lists/devel/2014/10/16064.php), it seems like this is the original problem: $ make mpif90 -c main.f90 yacc -d example4.y mpicc -c y.tab.c mpicc -c mymain.c lex example4.l mpicc -c lex.yy.c mpif90 -o example main.o y.tab.o mymain.o lex.yy.o ld: y.tab.o(.text+0xd9): unresolvable R_X86_64_PC32 relocation against symbol `yylval' ld: y.tab.o(.text+0x16f): unresolvable R_X86_64_PC32 relocation against symbol `yyval' - You later confirmed that adding -fPIC to the compile/link lines make everything work without adding -lbat -llsf. Dave and I are sorta convinced (i.e., we could still be wrong, but we *think* this is right) that adding -lbat and -llsf to the link line is the Wrong solution. The issue seems to be that a correct/matching yylval symbol is not being found during your final link. Crucial point: the yylval sy
Re: [OMPI devel] ompi-master build error : make can require autotools
I just attempted to reproduce this issue and was unable to. I did this on a RHEL6 box with master hash ce2008a: ✂ $ touch config/opal_config_pthreads.m4 && ./autogen.pl && module unload cisco/autotools/ac269-am1133-lt242 && ./configure --prefix=$PWD/_prefix && make ✂ Which did exactly what I expected and only ran configure once, the time that I explicitly requested it to be run. I even ran it again to make sure that the timestamp on opal_config_ptrheads.m4 was the only source state difference between the two runs. So I don't know what is causing your problem, but it's not the rule you pointed out in the generated makefile. Perhaps you are building on NFS and this is causing you some timestamp headaches? -Dave On Dec 22, 2014, at 8:13 PM, Gilles Gouaillardet wrote: > Hi Dave, > > yes, i did experience this exact behaviour. > > "by accident" meant i ran autogen.pl with the required autotools versions. > then, i ran configure and make with the RHEL6 stock autotools (that are too > old for OMPI) > configure worked just fine, but make crashed because of outdated autotools > > if i ran make with the latest autotools, i would probably have not noticed > the issue. > > note the issue occurs only when make is invoked for the first time. > if make success, autoheader does touch mpif.h.in, so the next make do not > require autotools. > > if i read between the lines, it seems autoheader is not (correctly) invoked > by autogen.pl > > please let me know if you cannot reproduce this issue. > (and once again, this is a very minor annoyance, and since tarballs are > generated with make dist, tarballs are very likely unaffected, so bottom line, > only developers that update m4 files can be affected) > > > Cheers, > > Gilles > > On Tue, Dec 23, 2014 at 2:26 AM, Dave Goodell (dgoodell) > wrote: > On Dec 22, 2014, at 2:42 AM, Gilles Gouaillardet > wrote: > > > Jeff and all, > > > > i just found "by accident" that make can require autotools. > > > > for example: > > > > from (generated) ompi/include/Makefile : > > $(srcdir)/mpi.h.in: $(am__configure_deps) > >($(am__cd) $(top_srcdir) && $(AUTOHEADER)) > >rm -f stamp-h2 > >touch $@ > > > > and $(am__configure_deps) is a bunch (all?) of .m4 files. > > > > from a pragmatic point of view, it means that if update a m4 file, run > > autogen.pl and configure, > > then, the first invokation of make will run $(AUTOHEADER) > > Gilles, > > Have you actually experienced this exact behavior? The sequence you mention > above shouldn't cause autoheader to be invoked by make. Running autogen.pl > will invoke autoheader after the m4 files were touched, so the mpi.h.in file > will be newer than its m4 dependencies, which should mean that this make rule > won't be executed. > > -Dave > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/12/16713.php > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/12/16717.php
Re: [OMPI devel] ompi-master build error : make can require autotools
Dave, what if you do touch ompi/include/mpi.h.in && sleep 1 && touch config/opal_config_pthreads.m4 && ./autogen.pl && module unload cisco/autotools/ac269-am1133-lt242 && ./configure --prefix=$PWD/_prefix && make autogen.pl nor configure does not touch ompi/include/mpi.h.in, and as a consequence, config/opal_config_pthreads.m4 is newer than ompi/include/mpi.h when make is invoked. then from ompi/include/Makefile: $(srcdir)/mpi.h.in: $(am__configure_deps) ($(am__cd) $(top_srcdir) && $(AUTOHEADER)) rm -f stamp-h2 touch $@ this means $(AUTOHEADER) is invoked, and then ompi/include/mpi.h.in is touched. 1) in this scenario, $(AUTOHEADER) is invoked for nothing, but make has no way to know it ... 2) make will touch ompi/include/mpi.h.in so the next make invokation will not call $(AUTOHEADER) makes sense ? could this be seen as an autotools flaw ? (e.g. autogen.pl invokes autotools that should have touched ompi/include/mpi.h.in in order to avoid the issue discussed here) and/or could/should this be handled in autogen.pl ? (e.g. manually touch ompi/include/mpi.h.in and some other files) Cheers, Gilles On 2015/01/06 8:25, Dave Goodell (dgoodell) wrote: > I just attempted to reproduce this issue and was unable to. I did this on a > RHEL6 box with master hash ce2008a: > > ✂ > $ touch config/opal_config_pthreads.m4 && ./autogen.pl && module unload > cisco/autotools/ac269-am1133-lt242 && ./configure --prefix=$PWD/_prefix && > make > ✂ > > Which did exactly what I expected and only ran configure once, the time that > I explicitly requested it to be run. I even ran it again to make sure that > the timestamp on opal_config_ptrheads.m4 was the only source state difference > between the two runs. So I don't know what is causing your problem, but it's > not the rule you pointed out in the generated makefile. Perhaps you are > building on NFS and this is causing you some timestamp headaches? > > -Dave > > On Dec 22, 2014, at 8:13 PM, Gilles Gouaillardet > wrote: > >> Hi Dave, >> >> yes, i did experience this exact behaviour. >> >> "by accident" meant i ran autogen.pl with the required autotools versions. >> then, i ran configure and make with the RHEL6 stock autotools (that are too >> old for OMPI) >> configure worked just fine, but make crashed because of outdated autotools >> >> if i ran make with the latest autotools, i would probably have not noticed >> the issue. >> >> note the issue occurs only when make is invoked for the first time. >> if make success, autoheader does touch mpif.h.in, so the next make do not >> require autotools. >> >> if i read between the lines, it seems autoheader is not (correctly) invoked >> by autogen.pl >> >> please let me know if you cannot reproduce this issue. >> (and once again, this is a very minor annoyance, and since tarballs are >> generated with make dist, tarballs are very likely unaffected, so bottom >> line, >> only developers that update m4 files can be affected) >> >> >> Cheers, >> >> Gilles >> >> On Tue, Dec 23, 2014 at 2:26 AM, Dave Goodell (dgoodell) >> wrote: >> On Dec 22, 2014, at 2:42 AM, Gilles Gouaillardet >> wrote: >> >>> Jeff and all, >>> >>> i just found "by accident" that make can require autotools. >>> >>> for example: >>> >>> from (generated) ompi/include/Makefile : >>> $(srcdir)/mpi.h.in: $(am__configure_deps) >>>($(am__cd) $(top_srcdir) && $(AUTOHEADER)) >>>rm -f stamp-h2 >>>touch $@ >>> >>> and $(am__configure_deps) is a bunch (all?) of .m4 files. >>> >>> from a pragmatic point of view, it means that if update a m4 file, run >>> autogen.pl and configure, >>> then, the first invokation of make will run $(AUTOHEADER) >> Gilles, >> >> Have you actually experienced this exact behavior? The sequence you mention >> above shouldn't cause autoheader to be invoked by make. Running autogen.pl >> will invoke autoheader after the m4 files were touched, so the mpi.h.in file >> will be newer than its m4 dependencies, which should mean that this make >> rule won't be executed. >> >> -Dave >> >> ___ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/12/16713.php >> >> ___ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/12/16717.php > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/01/16734.php
