www.digitalmars.com         C & C++   DMDScript  

c++.command-line - executables or "macro-objects" as input to OPLINK? Highly controlled library search?

reply Richard Haney <Richard_member pathlink.com> writes:
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
Jan 20 2004
parent reply Scott Michel <scottm cs.ucla.edu> writes:
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.
Jan 20 2004
parent "Walter" <walter digitalmars.com> writes:
"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.
Jan 22 2004