Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bywater!arnor!arnor!marc From: marc@arnor.uucp Newsgroups: comp.unix.aix Subject: Re: Problem when linking fairly large FORTRAN object files Message-ID: Date: 16 Nov 90 16:31:30 GMT References: <11256@ccncsu.ColoState.EDU> Sender: news@arnor.uucp (NNTP News Poster) Organization: IBM T.J. Watson Research Center, Hawthorne, New York Lines: 32 In-Reply-To: flatau@handel.CS.ColoState.Edu's message of 16 Nov 90 05:43:02 GMT 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.