gary@cgdisis.cgd.ucar.edu (Gary Strand) (01/04/91)
FC: Sun FORTRAN f77. I'm bashing my brains in trying to figure out how to force 'f77' to load in *my* object modules from *my* object library. What I'm doing is replacing several software-package routines, and putting them all into my own .a file. But, when I link everything together, 'f77' uses the system modules, not mine. I can force it to use my own modules via the '-g $(LIBDIR)/object.o' command, but I've got more than a few of my own modules, and this is sloppy. What's the point of personal libraries when they don't work? 'f77' doesn't even tell you when modules are duplicated, either. On our Cray, 'cft77' tells you when modules are duplicated, and which ones it's using (and from which library they are). The best I can do is have 'f77' pass on the '-M' option to the linker, but all that tells me is the libraries I'm accessing and the '.o' files used. Anybody with any ideas? The manual stinks. -- Gary Strand There is only one success -- to be able Internet: strandwg@ncar.ucar.edu to spend your life in your own way. Voicenet: (303) 497-1336 - Christopher Morley
rcg@lpi.liant.com (Rick Gorton) (01/09/91)
In article <9767@ncar.ucar.edu> gary@cgdisis.cgd.ucar.edu (Gary Strand) writes: > > I'm bashing my brains in trying to figure out how to force 'f77' to load > in *my* object modules from *my* object library. > > What I'm doing is replacing several software-package routines, and putting > them all into my own .a file. But, when I link everything together, 'f77' > uses the system modules, not mine. This is fairly lengthly, since I don't know specifics here.... If you are trying to replace a specific system routine with your own copy and know what the entry point is, then you can force the linkage of your version by doing the following. Add a call to a dummy routine from some unused subroutine A, and put that dummy routine in the same compilation unit as your replacement module. Then, at link time, put your library (containing the new routine) on the command line before the 'f77' and system routines. This should solve the problem If you are having problems with your source code inadvertently colliding with system/f77 libraries, then you have a couple of options. One is to switch compilers for your sun, and pick one where the compiler libraries won't have entry point names which conflict with your [personal] library. Our libraries deal with this problem by having a special (and very unlikely) sequence in our entry point names (P$ALC31, and F$XWLR) which is not permitted by the language (in this case a '$'). We also have compile switches to permit or force case on external names. Enough on the advertisment :-) Another solution is to modify your source code and do something similar to the P$foo/F$foo trick we use. This solution is clearly unusable if the compiler/linker on other systems where this code must run only permits, say, six significant characters as external names. It is also not very reasonable if doing so would require many source modules and/or thousands of lines of source code to be modified.... Hope this helps, rick -- Richard Gorton rcg@lpi.liant.com (508) 626-0006 Language Processors, Inc. Framingham, MA 01760 Hey! This is MY opinion. Opinions have little to do with corporate policy.
gary@cgdisis.cgd.ucar.edu (Gary Strand) (01/09/91)
> Rick Gorton > Add a call to a dummy routine from some unused subroutine A, and put that > dummy routine in the same compilation unit as your replacement module. > Then, at link time, put your library (containing the new routine) on the > command line before the 'f77' and system routines. This should solve the > problem. It did. The problem was that the new routines were not being called by my program directly. Thus, they were not undefined references at link time, thus 'f77' didn't access them. So, I called each of them with dummy arguments from a dummy subroutine, and that worked. I still don't particularly like this solution, because as you pointed out, I may not know what the arguments may be, necessarily. Our Cray FORTRAN compiler manages to cross-check everything, and tells you which one is being used. I suppose that's the difference between a compiler written for a machine (Suns) that isn't used for FORTRAN very much, and one in which FORTRAN makes up most of the code written for it. I'd like to thank all respondees to my question. -- Gary Strand There is only one success -- to be able Internet: strandwg@ncar.ucar.edu to spend your life in your own way. Voicenet: (303) 497-1336 - Christopher Morley