Markus, I based my suggestion on the presence of certain keywords in the error message, not on any mental model of the compiler or linker action on your input. I don't think there is any valid reason one should *expect* a need to compile or link with "mpif90 -fPIC". So, I am afraid I cannot answer as to why this fixes the problem.
-Paul On Sun, Oct 19, 2014 at 10:44 PM, Frings, Markus <fri...@cats.rwth-aachen.de > wrote: > Compiling the sources with -fPIC fixes the issue. But I wonder why I have > to add -fPIC when I want to compile with mpif90, but not when I use ifort > directly. With mpif90 I also use ifort with some additional flags and > libraries as mpif90 --show-me shows. > > -------------------------------- > Markus Frings, M.Sc. > > Chair for Computational Analysis of Technical Systems (CATS) > RWTH Aachen University > Schinkelstrasse 2, Room 222a > D-52062 Aachen > > Phone +49 (0)241 80 99932 > fri...@cats.rwth-aachen.de > http://www.cats.rwth-aachen.de > > On 18.10.2014, at 02:24, Paul Hargrove <phhargr...@lbl.gov> wrote: > > 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 > > > -- 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
