I think the LSF part of this may be a red herring. Do you really need to add "-lbat -llsf" to the command line to make it work?
The error message *sounds* like y.tab.o was compiled differently than others...? It's hard to know without seeing the output of mpicc --showme. On Oct 17, 2014, at 7:51 AM, Ralph Castain <r...@open-mpi.org> wrote: > Forwarding this for Paul until his email address gets updated on the User > list: > >> Begin forwarded message: >> >> Date: October 17, 2014 at 6:35:31 AM PDT >> From: Paul Kapinos <kapi...@itc.rwth-aachen.de> >> To: Open MPI Users <us...@open-mpi.org> >> Cc: "Kapinos, Paul" <kapi...@itc.rwth-aachen.de>, >> <fri...@cats.rwth-aachen.de> >> Subject: Open MPI 1.8: link problem when Fortran+C+Platform LSF >> >> Dear Open MPI developer, >> >> we have both Open MPI 1.6(.5) and 1.8(.3) in our cluster, configured to be >> used with Platform LSF. >> >> One of our users run into an issue when trying to link his code (combination >> of lex/C and Fortran) with v.1.8, whereby with OpenMPI/1.6er the code can be >> linked OK. >> >>> $ 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' >>> ....... >> >> looking into "mpif90 --show-me" let us see that the link line and possibly >> the philosophy behind it has been changed, there is also a note on it: >> >> # Note that per https://svn.open-mpi.org/trac/ompi/ticket/3422, we >> # intentionally only link in the MPI libraries (ORTE, OPAL, etc. are >> # pulled in implicitly) because we intend MPI applications to only use >> # the MPI API. >> >> >> >> >> Well, by now we know two workarounds: >> a) add "-lbat -llsf" to the link line >> b) add " -Wl,--as-needed" to the link line >> >> What would be better? Maybe one of this should be added to linker_flags=..." >> in the .../share/openmpi/mpif90-wrapper-data.txt file? As of the note above, >> (b) would be better? >> >> Best >> >> Paul Kapinos >> >> P.S. $ mpif90 --show-me >> >> 1.6.5 >> ifort -nofor-main -I/opt/MPI/openmpi-1.6.5/linux/intel/include -fexceptions >> -I/opt/MPI/openmpi-1.6.5/linux/intel/lib >> -L/opt/lsf/9.1/linux2.6-glibc2.3-x86_64/lib >> -L/opt/MPI/openmpi-1.6.5/linux/intel/lib -lmpi_f90 -lmpi_f77 -lmpi -losmcomp >> -lrdmacm -libverbs -lrt -lnsl -lutil -lpsm_infinipath -lbat -llsf -ldl -lm >> -lnuma -lrt -lnsl -lutil >> >> 1.8.3 >> ifort -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 >> >> P.S.2 $ man ld >> .... >> --as-needed >> --no-as-needed >> This option affects ELF DT_NEEDED tags for dynamic libraries >> mentioned on the command line after the --as-needed option. >> Normally the linker will add a DT_NEEDED tag for each dynamic >> library mentioned on the command line, regardless of whether the >> library is actually needed or not. --as-needed causes a DT_NEEDED >> tag to only be emitted for a library that satisfies an undefined >> symbol reference from a regular object file or, if the library is >> not found in the DT_NEEDED lists of other libraries linked up to >> that point, an undefined symbol reference from another dynamic >> library. --no-as-needed restores the default behaviour. >> >> .... >> >> -- >> Dipl.-Inform. Paul Kapinos - High Performance Computing, >> RWTH Aachen University, IT Center >> Seffenter Weg 23, D 52074 Aachen (Germany) >> Tel: +49 241/80-24915 >> > > <lexyacc.zip> -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
