Thread overview | |||||
---|---|---|---|---|---|
|
January 21, 2004 executables or "macro-objects" as input to OPLINK? Highly controlled library search? | ||||
---|---|---|---|---|
| ||||
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 |
January 21, 2004 Re: executables or "macro-objects" as input to OPLINK? Highly controlled library search? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Richard Haney | 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.
|
January 22, 2004 Re: executables or "macro-objects" as input to OPLINK? Highly controlled library search? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Scott Michel | "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. |
Copyright © 1999-2021 by the D Language Foundation