flatau@handel.CS.ColoState.Edu (flatau) (11/16/90)
I am having problems linking (fairly large, 30K lines) FORTRAN program on RISC6000/320 AIX3.1 + 3002 (September) update, 16Mb: I have a library, say "rams.a" made with "ar r" command. This library contains about 10 modules (approx 1000 lines each), and each module contains several FORTRAN subroutines (i.e. I am NOT fsplitting them). Next, I am linking several *.o files with xlf -o ramsexe *.o rams.a this results in unsatisfied external refs, even though, I am certain these externals are in the library. I have traced the problem a bit further: seems like removing one particular object file from *.o list makes the problem to go away. However, this particular object file is not unusual in any way. If I keep the library in the object form and link everything (model + library) as xlf -o ramsexe *.o (i.e. *.o contains all objects needed) the executable is created and no problem with unsatisfied externals appears. However, all objects have to be in ONE subdirectory. Clues: a) I tried the same procedure on SUN -- the library stuff works just as expected. b) I tried the same procedure on RISC600 but with small files and it works. c) If I fsplit files before making the library, the problem goes away. Questions: 1) Are there any problems on RISC6000 when linking many, fairly large, objects ? 2) Any suggestions ? Peter
johnson@ecovsh.eco.ncsu.edu (Amy Johnson) (11/16/90)
In article <11256@ccncsu.ColoState.EDU>, flatau@handel.CS.ColoState.Edu (flatau) writes: |>I am having problems linking (fairly large, 30K lines) FORTRAN program |>on RISC6000/320 AIX3.1 + 3002 (September) update, 16Mb: |> |> |>I have a library, say "rams.a" made with "ar r" command. |>This library contains about 10 modules (approx 1000 lines each), |>and each module contains several FORTRAN subroutines (i.e. I am |>NOT fsplitting them). |> |>Next, I am linking several *.o files with |> |>xlf -o ramsexe *.o rams.a |> |>this results in unsatisfied external refs, even though, I am |>certain these externals are in the library. I have traced the |>problem a bit further: seems like removing one particular |>object file from *.o list makes the problem to go away. |>However, this particular object file is not unusual in any way. |> I got bit by this problem myself a couple weeks ago. Try using the flag: -b nodelcsect on the link line. It worked for me. Amy <johnson@ecovsh.eco.ncsu.edu> Engineering Computer Operations North Carolina State University
marc@arnor.uucp (11/17/90)
In article <11256@ccncsu.ColoState.EDU> flatau@handel.CS.ColoState.Edu (flatau) writes: >I have a library, say "rams.a" made with "ar r" command. >Next, I am linking several *.o files with >xlf -o ramsexe *.o rams.a >this results in unsatisfied external refs, even though, I am >certain these externals are in the library. I have traced the >problem a bit further: seems like removing one particular >object file from *.o list makes the problem to go away. >However, this particular object file is not unusual in any way. >If I keep the library in the object form and link everything >(model + library) as >xlf -o ramsexe *.o >(i.e. *.o contains all objects needed) first, I would suggest using the -bloadmap:whatever option to get an ld history whenever mysteries occur. ("whatever" is the file for writing the loadmap - in your case ramsexe.map would be my choice). I would suspect that you have two programs with the same name, and that one defines the entry which is undefined in the first experiment. Using the ld defaults, the first occurance of a csect wins. Future occurances are deleted, including the additional symbols they may define. I suspect that when you ld *.o, the version from the "library" comes first.