I know of two possibilities: 1) I cannot be certain but since the message concerns a PC-relative addressing mode, it is possible that something needs to be compiled with -fPIC to fix the issue. See if adding that option to any of the mpicc commands helps.
2) Try adding ONE of "-ll", "-lfl" or "-lfl_pic" to include the lex/flex support lib. This is PROBABLY the wrong solution because that lib defines its own "main()". -Paul On Fri, Oct 17, 2014 at 4:56 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com > wrote: > 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/ > > _______________________________________________ > 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/10/16071.php > -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
