I have been trying to find out whether OPLINK can accept partially linked executables as input or can combine object modules to make larger object modules with some of the linkages satisfied (with relevant symbolic link information removed so as not to confuse OPLINK on a subsequent link using the "macro-object" as input).

I recall that the old IBM 360 linker ("loader") could use executable modules as input where newly created object modules could replace the previous versions in the executable to create a new executable.  Typically this capability was used to replace an older version of a function with a newer version without the need for all the separate old object modules.  Moreover, the linker would accept the first definition of a public variable and ignore all subsequent ones, thus making such an updating process quite easy.

I am interested in this possibility because I would like to have more control over where OPLINK gets its definitions for otherwise undefined references.

Briefly, I would like to create a "macro-object" module or a partially-linked executable from compiler A and OPLINK A with their default directories and then create a similar "macro-object" module or a partially-linked executable using compiler B and OPLINK B likewise using their own default directories.  The result would be two "macro-object" modules or a partially-linked executables, A and B, which would have only a few unsatisfied public symbols and which I could then link in a highly controlled manner.

Compiler B and OPLINK B are later versions of Compiler A and OPLINK A. Hopefully, Compiler B and OPLINK B would know about the linkage conventions of the earlier versions and could be made to use compatible linkage conventions.

Do the Zortech/Symantec/Digital Mars sequence of compilers/linkers/headers/libraries/etc. satisfy this desired capability?

Richard Haney
rfhaney@yahoo.com

Richard Haney wrote:

> I recall that the old IBM 360 linker ("loader") could use executable
> modules as input where newly created object modules could replace the
> previous versions in
> the executable to create a new executable.  Typically this capability was
> used to replace an older version of a function with a newer version
> without the need
> for all the separate old object modules.  Moreover, the linker would
> accept the first definition of a public variable and ignore all subsequent
> ones, thus making such an updating process quite easy.

The gnu ld and many Unix linkers before it have a "-r" flag that does something similar:

-r
--relocateable
     Generate relocatable output---i.e., generate an  output  file  that
     can  in  turn  serve  as input to ld.  This is often called partial
     linking.  As a side effect, in environments that  support  standard
     Unix  magic  numbers, this option also sets the output file's magic
     number to "OMAGIC".  If this option is not specified,  an  absolute
     file  is produced.  When linking C++ programs, this option will not
     resolve references to constructors; to do that, use -Ur.

     When an input file does not have the  same  format  as  the  output
     file, partial linking is only supported if that input file does not
     contain any relocations.  Different output formats can have further
     restrictions; for example some "a.out"-based formats do not support
     partial linking with input files in other formats at all.

However, from my limited experience with OPTLINK so far, it does not look like it supports this feature. You either get an executable or DLL. You don't get partial products or relinkable objects.

"Scott Michel" <scottm@cs.ucla.edu> wrote in message news:bukpas$1q10$1@digitaldaemon.com...
> However, from my limited experience with OPTLINK so far, it does not look like it supports this feature. You either get an executable or DLL. You don't get partial products or relinkable objects.

That's correct. The issue came up before, but optlink is so fast it doesn't need to do partial links. To completely control what it links, list the .obj files explicitly.