Linking module symbols on mac

[chasmotron]

I have a user trying to compile my code using ifort on a mac. He has sent me the entire output of the build, and everything up to the linking stage looks fine. The code has a library of 50 module files, and the linker complains about undefined symbols from about 15 of those files. For each of those 15 module files, the linker complains about every variable in it. I see no pattern, rhyme, or reason to the particular 15 files that were spurned compared to the 35 that seem to be fine.

I've had the user grep for one of the missing variables in the library using nm, and it has an entry with the same name mangling as the undefined symbol complaint.

I've successfully compiled on other macs using this same makefile and g95 and gfortran, but I do not have ifort for macintosh.

I'm shooting in the dark here. Can anyone improve my aim?

[Kevin_D_Intel]

You could consider obtaining an evaluation copy of the Intel Fortran compiler for Mac OS X to help you diagnose the error.Click "Evaluate" at the page (here).

The user could produce a link map to see if that sheds any light on what the linker is including.

Can you offer the exact unresolved symbol error and the corresponding nm entry you discussed with the user to us here?

Are the corresponding module's object files included in the final link step or are they gathered into some intermediate static archive or shared library that's used in the final link step?

[chasmotron]

Quoting - Kevin Davis (Intel)

You could consider obtaining an evaluation copy of the Intel Fortran compiler for Mac OS X to help you diagnose the error.Click "Evaluate" at the page (here).

The user could produce a link map to see if that sheds any light on what the linker is including.

Can you offer the exact unresolved symbol error and the corresponding nm entry you discussed with the user to us here?

Are the corresponding module's object files included in the final link step or are they gathered into some intermediate static archive or shared library that's used in the final link step?

I will consider the evaluation copy, and I will ask the user about the link map. Thank you for those suggestions.

The module object files are first gathered into libmods.a, using:

ar rvs modsobj/libmods.a modsobj/sf_variables_mod.o


Here's the symbol he first reported to me.

Undefined symbols:
[snip other symbols]
"_sf_variables_mod_mp_proj_", referenced from:
_sf_1dsphexpl_ in libepic.a(SF_1DSPHEXPL.o)
[snip other unresolved references]

Here are his reported greps (I'm re-typing them):

$ nm ./modsobj/libmods.a | grep -i sf_variables_mod_mp_proj
0000000000000010 C _sf_variables_mod_mp_proj_
$nm ./epicobj/libepic.a | grep -i sf_variables_mod_mp_proj
U _sf_variables_mod_mp_proj_
U _sf_variables_mod_mp_proj_
U _sf_variables_mod_mp_proj_
U _sf_variables_mod_mp_proj_
[etc]

[Kevin_D_Intel]

A colleague suggests ranlib may be the likely missing step after the building your static archives. So, once the static archive is built, run ranlib, something like this:

ranlib modsobj/libmods.a
ranlib libepic.a

[chasmotron]

Quoting - Kevin Davis (Intel)

A colleague suggests ranlib may be the likely missing step after the building your static archives. So, once the static archive is built, run ranlib, something like this:

ranlib modsobj/libmods.a
ranlib libepic.a

I'm resurrecting this thread now that I have a mac of my own (running 10.5.8), a trial copy of ifort (11.1.076), and the same problem.

I have the 'rvs' options on ar in the makefile (which runs ranlib), and I can also run ranlib on the static libraries directly, and still the linker cannot find symbols from a small percentage of the module files in the static library of module file objects.

I will cut and paste a bit from linking:

ifort post1psobj/ACCUM.o post1psobj/ADJCNT.o post1psobj/ARROW.o post1psobj/AUTOS.o post1psobj/AXIES.o post1psobj/BAD.o post1psobj/BKOUT.o post1psobj/BKUP.o post1psobj/BTGD.o post1psobj/CFILL.o post1psobj/CMPARL.o post1psobj/CMPARP.o post1psobj/COMPV0.o post1psobj/CONT3.o post1psobj/CONTOR.o post1psobj/DECOMP.o post1psobj/DRWLNE.o post1psobj/EDGE.o post1psobj/ELEAL.o post1psobj/EXGEOM.o post1psobj/FACEL.o post1psobj/FIL2DQ.o post1psobj/FIL2DT.o post1psobj/FIL3D.o post1psobj/FILLXY.o post1psobj/FILLZY.o post1psobj/FORGE.o post1psobj/GEOM2.o post1psobj/GEOM3.o post1psobj/GEOMNB.o post1psobj/GEOMP.o post1psobj/GREG.o post1psobj/HCHECK.o post1psobj/HIDEL.o post1psobj/INSIDE.o post1psobj/JETUP.o post1psobj/LINFIT.o post1psobj/MAPC.o post1psobj/MAPCRZ.o post1psobj/MAP.o post1psobj/MAPLN.o post1psobj/MAPNOD.o post1psobj/MAPRZ.o post1psobj/MODAL.o post1psobj/NEWCOL.o post1psobj/NODAL.o post1psobj/NUMBER.o post1psobj/NUMBGC.o post1psobj/ONGRAF.o post1psobj/ORDER.o post1psobj/OVRLAY.o post1psobj/PERHDR.o post1psobj/PERLGD.o post1psobj/PERS.o post1psobj/PLINE.o post1psobj/PLTNB.o post1psobj/PLYFIT.o post1psobj/POPL.o post1psobj/POPP.o post1psobj/POST1.o post1psobj/PST1.o post1psobj/PUSH3D.o post1psobj/PUSHL.o post1psobj/PUSHP.o post1psobj/RPECALL.o post1psobj/RPREAD.o post1psobj/RPREV62.o post1psobj/RPREV63.o post1psobj/SETORG.o post1psobj/SETUP.o post1psobj/SFTDNL.o post1psobj/SFTDNP.o post1psobj/SFTUPL.o post1psobj/SFTUPP.o post1psobj/SHELL.o post1psobj/SIDES.o post1psobj/SLP.o post1psobj/STRIP.o post1psobj/SOLIEQ.o post1psobj/SOLVE.o post1psobj/SWAP.o post1psobj/TOP.o post1psobj/TTRIM.o post1psobj/VEIL.o post1psobj/VEL.o post1psobj/VS.o post1psobj/VSP2.o post1psobj/WINDOE.o post1psobj/WRITET.o post1psobj/XOVER.o post1psobj/ZOVER.o post1psobj/most.o postpsobj/CENTSYMB.o postpsobj/LINEX.o postpsobj/PLTERR.o postpsobj/SKALE.o subsobj/libsubs.a modsobj/libmods.a psplotobj/libpsplot.a -o bin/Post1ps -lm
Undefined symbols:
"_pencurv_mod_mp_nyreg_", referenced from:
_contor_ in CONTOR.o
[.... more undefined symbols and references follow, but only from 3 of the 30 some modules. ]

$ nm ./post1psobj/CONTOR.o | grep nyreg
U _pencurv_mod_mp_nyreg_
$ nm ./modsobj/libmods.a | grep nyreg
0000000000000010 C _pencurv_mod_mp_nyreg_


I have successfully compiled the same code using gfortran.

Any ideas?

[Ron_Green]

Quoting - chasmotron

I'm resurrecting this thread now that I have a mac of my own (running 10.5.8), a trial copy of ifort (11.1.076), and the same problem.

I have the 'rvs' options on ar in the makefile (which runs ranlib), and I can also run ranlib on the static libraries directly, and still the linker cannot find symbols from a small percentage of the module files in the static library of module file objects.

I will cut and paste a bit from linking:

ifort post1psobj/ACCUM.o post1psobj/ADJCNT.o post1psobj/ARROW.o post1psobj/AUTOS.o post1psobj/AXIES.o post1psobj/BAD.o post1psobj/BKOUT.o post1psobj/BKUP.o post1psobj/BTGD.o post1psobj/CFILL.o post1psobj/CMPARL.o post1psobj/CMPARP.o post1psobj/COMPV0.o post1psobj/CONT3.o post1psobj/CONTOR.o post1psobj/DECOMP.o post1psobj/DRWLNE.o post1psobj/EDGE.o post1psobj/ELEAL.o post1psobj/EXGEOM.o post1psobj/FACEL.o post1psobj/FIL2DQ.o post1psobj/FIL2DT.o post1psobj/FIL3D.o post1psobj/FILLXY.o post1psobj/FILLZY.o post1psobj/FORGE.o post1psobj/GEOM2.o post1psobj/GEOM3.o post1psobj/GEOMNB.o post1psobj/GEOMP.o post1psobj/GREG.o post1psobj/HCHECK.o post1psobj/HIDEL.o post1psobj/INSIDE.o post1psobj/JETUP.o post1psobj/LINFIT.o post1psobj/MAPC.o post1psobj/MAPCRZ.o post1psobj/MAP.o post1psobj/MAPLN.o post1psobj/MAPNOD.o post1psobj/MAPRZ.o post1psobj/MODAL.o post1psobj/NEWCOL.o post1psobj/NODAL.o post1psobj/NUMBER.o post1psobj/NUMBGC.o post1psobj/ONGRAF.o post1psobj/ORDER.o post1psobj/OVRLAY.o post1psobj/PERHDR.o post1psobj/PERLGD.o post1psobj/PERS.o post1psobj/PLINE.o post1psobj/PLTNB.o post1psobj/PLYFIT.o post1psobj/POPL.o post1psobj/POPP.o post1psobj/POST1.o post1psobj/PST1.o post1psobj/PUSH3D.o post1psobj/PUSHL.o post1psobj/PUSHP.o post1psobj/RPECALL.o post1psobj/RPREAD.o post1psobj/RPREV62.o post1psobj/RPREV63.o post1psobj/SETORG.o post1psobj/SETUP.o post1psobj/SFTDNL.o post1psobj/SFTDNP.o post1psobj/SFTUPL.o post1psobj/SFTUPP.o post1psobj/SHELL.o post1psobj/SIDES.o post1psobj/SLP.o post1psobj/STRIP.o post1psobj/SOLIEQ.o post1psobj/SOLVE.o post1psobj/SWAP.o post1psobj/TOP.o post1psobj/TTRIM.o post1psobj/VEIL.o post1psobj/VEL.o post1psobj/VS.o post1psobj/VSP2.o post1psobj/WINDOE.o post1psobj/WRITET.o post1psobj/XOVER.o post1psobj/ZOVER.o post1psobj/most.o postpsobj/CENTSYMB.o postpsobj/LINEX.o postpsobj/PLTERR.o postpsobj/SKALE.o subsobj/libsubs.a modsobj/libmods.a psplotobj/libpsplot.a -o bin/Post1ps -lm
Undefined symbols:
"_pencurv_mod_mp_nyreg_", referenced from:
_contor_ in CONTOR.o
[.... more undefined symbols and references follow, but only from 3 of the 30 some modules. ]

$ nm ./post1psobj/CONTOR.o | grep nyreg
U _pencurv_mod_mp_nyreg_
$ nm ./modsobj/libmods.a | grep nyreg
0000000000000010 C _pencurv_mod_mp_nyreg_


I have successfully compiled the same code using gfortran.

Any ideas?

Odd, the "C _pencurv_mod_mp_nyreg_" tells us something. The "C" says this is a Mach-o Common symbol - which is an unallocated structure. I would expect this to be "T" for Target - if it were a target we wouldn't have the undefined reference.

In the source files that go into libmods.a, there is (somewhere in your code) MODULE PENCURV, and within that is the declaration of NYREG, if I read the name mangling correctly. I need to see how NYREG is declared within MODULE PENCURV.

And conversely, CONTOR.f90 is referenciing NYREG, and probably has a USE PENCURV statement. Can I see the reference to NYREG within CONTOR?

I'll have to research more on what this "C" or Mach-o common symbol means for Fortran - a cursory search in Google is only showing why these are used in C/C++.

ron

[chasmotron]

Quoting - Ronald W. Green (Intel)

Odd, the "C _pencurv_mod_mp_nyreg_" tells us something. The "C" says this is a Mach-o Common symbol - which is an unallocated structure. I would expect this to be "T" for Target - if it were a target we wouldn't have the undefined reference.

In the source files that go into libmods.a, there is (somewhere in your code) MODULE PENCURV, and within that is the declaration of NYREG, if I read the name mangling correctly. I need to see how NYREG is declared within MODULE PENCURV.

And conversely, CONTOR.f90 is referenciing NYREG, and probably has a USE PENCURV statement. Can I see the reference to NYREG within CONTOR?

I'll have to research more on what this "C" or Mach-o common symbol means for Fortran - a cursory search in Google is only showing why these are used in C/C++.

ron

Here are the relevant lines in PENCURV:

MODULE PENCURV_MOD

IMPLICIT NONE

INTEGER,PARAMETER::MXLAY=50,MXLSRF=50,MXREG=50,MXSEC=5,NJSMAX=10
INTEGER,SAVE::NTSURF(MXSEC ,MXLAY ), &
& ITYDAT(MXREG ),NLAY (MXSEC ), &
& IFFSEL,NODECL,NTXS ,NYREG ,PNOSEN,PTAILN,SLIN

Here are the relevant lines in CONTOR:

SUBROUTINE CONTOR([args deleted])

USE PENCURV_MOD, ONLY: ITYDAT, NLAY, NTSURF,XSURF, ZSURF, NYREG, RTYDAT


Since you seem concerned about the C designation on the symbol, I went and found a different symbol CONTOR uses supplied by the module library with the same designation. The linker does not complain about this symbol, or any other symbol in postplot_mod.

$ nm ./post1psobj/CONTOR.o | grep acf
U _postplot_mod_mp_acf_
$ nm ./modsobj/libmods.a | grep acf
0000000000000010 C _postplot_mod_mp_acf_


Also, as another experiment, since it only complains about symbols from three modules, I copied the link line, explicitly added those three object files to the link line, and I now have an executable. So, I guess I have a work-around, but this is still really annoying. (I also went back and ar -rvs those object files into the library again, and ran ranlib on the library. The link with just the library still fails.)

-Charles

[Ron_Green]

I am glad you found a workaround, but unnerved that some bug may be lurking.
What version of Xcode, and more to the point, what version of ld is on your system?
$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1

I have Xcode 3.1.3.

[chasmotron]

Quoting - Ronald W. Green (Intel)

I am glad you found a workaround, but unnerved that some bug may be lurking.
What version of Xcode, and more to the point, what version of ld is on your system?
$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1

I have Xcode 3.1.3.

$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1

I have Xcode 3.1.2

To be clear, I am not compiling inside an Xcode project. I am using a gmake Makefile that I wrote myself, but has worked on many different platforms: Linux, IBM, Cray-X1, Cray-XT3, IRIX, and works with gfortran on this mac.

-Charles

[Ron_Green]

Quoting - chasmotron

$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1

I have Xcode 3.1.2

To be clear, I am not compiling inside an Xcode project. I am using a gmake Makefile that I wrote myself, but has worked on many different platforms: Linux, IBM, Cray-X1, Cray-XT3, IRIX, and works with gfortran on this mac.

-Charles

The reason I asked for your Xcode and ld versions is that ifort uses gcc libraries and ld. these are supplied by Xcode on a Mac. So I really don't care if you use command line or Xcode, I merely want to try to reproduce this on a sandbox witht the same gcc libs and ld versions, same OS version, and same version of ifort.

I'll see if I have enough information to create my own reproducer.

ron

[chasmotron]

Quoting - Ronald W. Green (Intel)

The reason I asked for your Xcode and ld versions is that ifort uses gcc libraries and ld. these are supplied by Xcode on a Mac. So I really don't care if you use command line or Xcode, I merely want to try to reproduce this on a sandbox witht the same gcc libs and ld versions, same OS version, and same version of ifort.

I'll see if I have enough information to create my own reproducer.

ron

I'm not sure if this is helpful information or just piling on, but here goes. My code is strictly fortran, but we use a couple third party libraries written mostly in C (netcdf, OpenMPI), so I downloaded the intel C compiler as well. In the middle of both builds, the c compiler complained of missing objects when linking. Netcdf had already completed building the libraries, and just failed to link a test case, so those libraries are usable. OpenMPI isn't usable. I can supply more information if that will be helpful. If not, ignore this post.

-Charles