Problem with Linker Options file on Alpha

[John McL]

I am writing a software tool to enable logical names to be deassigned using a wildcard specification for the logical. Let me assure you this will only apply to user, super and exec logicals. The aim is to gather all the names before starting the deassign phase because trying to remove non-existent logicals is better than accidentally deleting new logicals.

The "proof of concept" is working fine and all logicals, both private and shared, can be listed. I have a problem though with accessing address LNM$AL_HASHTBL.

It's no problem with linking /SYSEXE on our Alpha, but our automated "build" procedures use a linker options file and this method fails.

When the linker options file contains
ALPHA$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE/SHARE I get about 50 multiply defined symbols (but no problem with LNM$AL_HASHTBL). If I append /SELECTIVE to the above line LNM$AL_HASHTBL is undefined. (The attached doc has more details.)

Why can't I get a clean link with the options file? What am I doing wrong? How do I correct it?

[John Gillings]

John,

I think the problem is a clash between entry points in the "real" DECC$SHR shareable image, and the kernel mode hacked down CRTL in SYS$BASE_IMAGE. Without seeing your full LINK command, I don't know which version your code will call - but I'm guessing it's the SYS$BASE_IMAGE ones because the DECC$SHR symbols are the MULDEF. See the linker map for proof.

Your options file works fine from a MACRO32 program, presumably because it doesn't link against DECC$SHR, and therefore doesn't see any duplicates. If I add DECC$SHR to the link, I get your MULDEF errors.

/SELECTIVE doesn't help because you're linking against a shareable image. You get all or none of the symbols. I'm guessing the reference to LNM$AL_HASHTBL is processed after SYS$BASE_IMAGE, so /SELECTIVE causes it to be skipped entirely (no references), hence UDFSYM.

Simple test, try options files:

test1
SYS$LOADABLE_IMAGES:SYS$BASE_IMAGE/SHARE
SYS$SHARE:DECC$SHR/SHARE

test2
SYS$SHARE:DECC$SHR/SHARE
SYS$LOADABLE_IMAGES:SYS$BASE_IMAGE/SHARE

test1 is equivalent to what you're doing now, since DECC$SHR is picked up at the end of the list, by default from IMAGELIB. MULDEFs are reported against DECC$SHR.

test2 processes DECC$SHR first, so the MULDEFs are reported against SYS$BASE_IMAGE.

Since the shareable images are monolithic there's no way around the warnings if you link against both images. There is a clash in symbol names, so you will get MULDEF. Linking against DECC$SHR first will give you a correct image because you'll be calling the "real" DECC$SHR routines, not the kernel ones.

Changing languages will eliminate DECC$SHR, but if that's not feasible another option is to get the address dynamically, at run time, rather than linked via the options file:

stat=LIB$FIND_IMAGE_SYMBOL('SYS$BASE_IMAGE','LNM$AL_HASHTBL',lnm$al_hashtbl,'SYS$LOADABLE_IMAGES:')

So now you won't need the options file at all.

Note you'll get the same behaviour on Itanium, and the same fix.

[Hoff]

Some reading on duplicate symbols with C kernel-mode code:

http://labs.hoffmanlabs.com/node/769
http://labs.hoffmanlabs.com/node/273

[John McL]

John G, I'm following up your comments. Flipping the order of those lines in the linker option file generated the multiply defined symbol messages and as you say, the image mentioned in the messages swapped around.

I'm currently working on getting LIB$FIND_IMAGE_SYMBOL to work. It's giving me ILLSYMLEN errors at the moment but it's got to be my fault somewhere. I'll award points when I get things working.

In the bigger picture this problem looks likely to occur whenever C code wants to link against SYS$BASE_IMAGE.EXE and the user doesn't want to use LINK/SYSEXE. Doesn't this deserve a mention in the Linker manual?

[John McL]

When I use LIB$FIND_IMAGE symbol in SYS$BASE_IMAGE.EXE in directory SYS$LOADABLE_IMAGES I get the error message:

%LIB-W-ILLSYMLEN, symbol SPARSZ(Ã EXE$C_SYSPARSZ(p ....

PFM$C_BUFCNT has illegal length (89.) in module SYS$BASE_IMAGE

%TRACE-W-TRACEBACK, symbolic stack dump follows (etc.)

When I modified my code to point to other .EXEs in other directories it worked fine.

What's going on?

[x2084]

(All typos and poor formatting are mine: I wrote the answer in a real editor and tried to cut and paste it here. So, no points or negative ones, please.)


>>> 1. With Linker options file containing
ALPHA$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE/SHARE (which is the documented
equivalent to /SYSEXE).

Where is this documented? The equivalent would be a
ALPHA$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE/SHARE/SELECTIVE


>>> %LINK-W-MULDEF, symbol DECC$_WMEMSET64 multiply defined
in module DECC$SHR_EV56 file SYS$COMMON:[SYSLIB]DECC$SHR_EV56.EXE;1

The map shows
SYS$BASE_IMAGE ALPHA X9ZK-O2L 0 [SYS$LDR]SYS$BASE_IMAGE.EXE;1
F V1.0 100 SYS$SYSDEVICE:[HARTMUT.L]F.OBJ;2
DECC$SHR_EV56 V7.3-2-00 0 [SYSLIB]DECC$SHR_EV56.EXE;1

The base image exports DECC$_WMEMSET64 and DECC$SHR exports it as well, here
you got you code linked with the one from SYS$BASE_IMAGE.



>>> 2. with Linker options file containing

ALPHA$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE/SHARE/SELECTIVE (in an attempt to
prevent the above)


%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, LNM$AL_HASHTBL
%LINK-W-USEUNDEF, undefined symbol LNM$AL_HASHTBL referenced
in psect $LINK$ offset %X00000148

That's a problem of the order how the you told the linker to process the input
files. With /SELECTIVE you must ensure that that sharable image is processed
AFTER the input file which references LNM$AL_HASHTBL.


>>> Changing languages will eliminate DECC$SHR, but if that's not feasible
another option is to get the address dynamically, at run time, rather than
linked via the options file:

stat=LIB$FIND_IMAGE_SYMBOL('SYS$BASE_IMAGE','LNM$AL_HASHTBL',lnm$
al_hashtbl,'SYS$LOADABLE_IMAGES:')

If that works ("LNM$AL_HASHTBL" is a Double Valued Global Symbol/Version Mask)
then there is another disadvantage: lib$fis doesn't do any checking of GSMATCH
nor the system version array. I recommend to statically link against the base
image.


>>> John G, I'm following up your comments. Flipping the order of those lines in
the linker option file generated the multiply defined symbol messages and as
you say, the image mentioned in the messages swapped around.

$ ty f.c
#include
extern void *LNM$AL_HASHTBL;
void foo(){printf ("%p",LNM$AL_HASHTBL);}
$
$ cc f/stand=rel
$ link tt:/opt/exe=f/map=f/full/cross
sys$share:decc$shr/share
cluster=f,,,sys$disk:[]f
alpha$loadable_images:sys$base_image.exe/share/selective
$


>>> In the bigger picture this problem looks likely to occur whenever C code wa
to link against SYS$BASE_IMAGE.EXE and the user doesn't want to use
LINK/SYSEXE. Doesn't this deserve a mention in the Linker manual?

Looks like a very specific request to me. The recommended way to link against
the base image is to use /SYSEXE. The recommendation is to add this qualifier.

What you need/want to know is sequence of the input file processing by the
linker. There is a section in the manul about this. The sequence is reflected
in the Object Module Synopsis of the map.


>>> When I use LIB$FIND_IMAGE symbol in SYS$BASE_IMAGE.EXE in directory
SYS$LOADABLE_IMAGES I get the error message:

%LIB-W-ILLSYMLEN, symbol SPARSZ(Ã ? EXE$C_SYSPARSZ(p ....

PFM$C_BUFCNT has illegal length (89.) in module SYS$BASE_IMAGE

%TRACE-W-TRACEBACK, symbolic stack dump follows (etc.)

When I modified my code to point to other .EXEs in other directories it worked
fine.

What's going on?

It looks like lib$fis can't handle the "Double Valued Global Symbol/Version
Mask". Which looks OK to me, lib$fis was not designed for that

[Wim Van den Wyngaert]

Nothing to do with your problem but why don't you put your logical names into a logical name table ?

We put all logicals of application X in table X$LOGICAL_NAMES and add that table to the logical search path. When we stop the application we remove the table and remove it from the search path.

Wim

[Hoff]

If we're going to look at the design, then this could be solved in about twenty or thirty minutes with some mildly ugly DCL. SHOW LOGICAL [whatever] /OUTPUT=file.txt or such, and you're off to the races. And the DCL will usually survive upgrades, and usually won't crash the process or the system if something goes "worng".

As for some folks that have already solved this basic sequence, see the LN$SDA widget at

http://eisner.encompasserve.org/~miller/

And see LNMLOOKUP over at

ftp://ftp.process.com/vms-freeware/fileserv/lnmlookup.zip

[John McL]

Harmut, thanks for your detailed response. Here's my reply.

1 - The Linker manual says that the equivalent to /SYSEXE when using a Linker options file is ALPHA$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE/SHARE and doesn't mention /SELECTIVE.

2 - Sure linking order seems to be important but if I say $ LINK A, B.OPT/OPT mean that A.OBJ gets processed first and then the contents of linker options file B.OPT? This would mean that there should be no problem. (It is possible that the automated procedures that we use here are merging a number of options files and might be re-ordering things - I'll investigate.)

3 - When you discuss using LIB$FIND_IMAGE_SYMBOL and again near the end of your response you talk about 'LNM$AL_HASHTBL' being Double Valued Global Symbol/Version Mask". What do you mean by this? I understand the last part - which just means global address - but are you saying that there's two addresses of the same name (presumably one in my initial address space and another because of the activation of SYS$BASE_IMAGE.EXE?

[John McL]

To Wim and Hoff...

Wim, nice idea but we're talking about software that has experienced ameobic growth for over 10 years, has about 150 CMS libraries and runs to several million lines of code. The code is very modular but to find and modify the references to certain logicals would be a big effort and every piece of code that accessed these logicals would need to be tested, and when that's done we'd have to move every modified executable into a production evironment that runs 24 * 7. I'm taking the easy approach!

Hoff, yes SHOW LOG/OUTPUT=... and parsing the output file is doable is possible. I've been on VMS for 30 years and seen big improvements in speed but this would still be far slower than accessing the data directly. If the data is present and available then why not use it?. Sure it changed at about 4.7 but these structures sem to have been stable since then. Better yet, SYS$TRNLNM should accept wildcards and return the data that I need, although it might have to forget the normal cycling return and just return a pointer to data block.

[Hoff]

>I've been on VMS for 30 years and seen big improvements in speed but this would still be far slower than accessing the data directly.

Don't solve yesterday's problem. This application is in maintenance, so it's not something I'd expect to see much time spent with updates; in these cases, simple and functional and a little slower always wins out over clever and fast and more difficult to support.

[John Gillings]

John,

> Better yet, SYS$TRNLNM should accept wildcards

True, it's been asked for many times. It won't ever happen :-(

> still be far slower than accessing the data directly

Also true, but unless you're doing this thousands of times a day do you really care if it takes 0.1 second or 0.01 second?

Attached is a first cut DCL procedure which will deassign wildcard logical names. I've done some minimal testing. I think it covers all tables and modes.

$ @DEASSIGN_WILD *YOURSTRING*

or

$ @DEASSIGN_WILD *YOURSTRING* /TABLE=SOME_TABLE

The debugging part expects a program called "ECHO" in SYS$LOGIN

[John Gillings]

attached is ECHO.MAR

Pity VMS doesn't have an ECHO command. It's very useful for debugging...

(and note it does something quite different from WRITE SYS$OUTPUT).

$ MACRO ECHO
$ LINK ECHO
$ echo="$SYS$LOGIN:ECHO"

[John McL]

Thanks John. I'd dismissed the idea of piping because the parsing of the output wasn't going to be simple but what you've given me is an elegant and self-contained solution.

It also wouldn't be difficult to create a similar command procedure that just counted the logical names that match a certain wildcard pattern, and that's something we might find useful in our software.

I'll fire this up today and see how it goes.

[John McL]

I've just been reminded that we've had a problem with logical names being created with non-printable characters. These didn't get noticed during testing and the code hit the production systems in this form. (Sorry, I should have mentioned this problem in my initial post.)

These can only be removed by either a SYS$DELLNM with a name that's manually matched to the hex values found by examining the process's tables or by rebooting the machine, and if these are clusterwide logicals the problem is even greater.

Sure the problem was a programmer error when using $CRELNM, but catching the problem relies on testers who will examine each logical name. Checking the output of $SHOW LOGICALS might not reveal this problem unless weird characters appear in names and the tester notices them.

(I suppose $CRELLNM could reject names with non-printing chars except by a flag reserved to HP, but would DCL symbol substitution been an alternative.)

This puts us back to the "never happen" change to $TRNLNM or the more likely wildcard deassign once I resolve the problem with processing order when linking.

[John McL]

Here's something odd ... Halmut mentioned it and I've just seen it for myself.

When linking with SYS$BASE_IMAGE/SHARE in the options file it appears first in the .MAP file, where the modules are listed, i.e. ...
Module name
-----------
SYS$BASE_IMAGE
(my function)
DECC$SHR_EV56
LIBRTL
LIBOTS
SYS$PUBLIC_VECTORS
...but at the end of the .MAP file the Link command is displayed and shows my function prior to SYS$BASE_IMAGE.EXE. Is SYS$BASE_IMAGE being processed by the Linker before my code?

I seem to have two alternatives, a Linker option file entry or the call to LIB$FIND_IMAGE_SYMBOL. The first has multiply defined symbols (or an undefined symbol) and the latter has the ILLSYMLEN problem when accessing SYS$BASE_IMAGE.EXE.

[John Gillings]

John,

Apologies! I didn't realise my LIB$FIS example code was executing on Itanium. I've just tried it on Alpha and I get a very ugly stackdump with non-printable characters. So scratch that plan!

Yet another (even uglier?) possibility, build youself a little shareable image in MACRO32 (or any other language that isn't C) linked against the base image, which exports a routine which returns the address of LNM$AL_HASHTBL.

That isolates the reference to the base image so the additional symbols don't clash with DECC$SHR.

LMN_AL_HASHTBL.MAR
.TITLE LNM_AL_HASHTBL
.EXTERNAL LNM$AL_HASHTBL
.ENTRY LNM_AL_HASHTBL,^M<>
MOVAL LNM$AL_HASHTBL,R0
RET
.END

$ MACRO LMN_AL_HASHTBL
$ LINK/SHARE LMN_AL_HASHTBL+SYS$INPUT/OPTIONS
GSMATCH=LEQUAL,100,100
SYS$LOADABLE_IMAGES:SYS$BASE_IMAGES/SHARE
SYMBOL_VECTOR=(LMN_AL_HASHTBL=PROCEDURE)
$
$ LINK yourimage+SYS$INPUT/OPTIONS
LNM_AL_HASHTBL/SHARE


It ain't pretty, but it will work, and should be the same on both Alpha and Itanium.

An example of an application of Hext's Law: - "Adding a further level of indirection solves all problems" :-)

[John McL]

John G, I took your idea and modified it. I created a C function whose only task is to return the address of LNM$AL_HASHTBL and I put the name of this file into a named linker cluster in a Linker options file so that it is processed before SYS$BASE_IMAGE.EXE/SHARE/SELECTIVE, which in turn is processed before my main code.

It all probably would have worked fine if our automated functions didn't also put the name of my new file in the Linker options, which meant it was linked twice. That would be bearable for a one-off build but we rebuild this code every day and we use LIB$FIND_IMAGE_SYMBOL to access it, and L$FIS dumps a traceback every time because of compilation warnings.

I'm about to wrestle with our automated procedures to see what can be done.

[John McL]

Question: Changing our automated procedures is not my first choice because it will involve a lot of testing.

Can I create a shareable image library from SYS$BASE_IMAGE.EXE and more importantly will the library contain the symbol LNM$AL_HASHTBL? If I can link against a shareable image library I won't need to use a cluster specification to get the Linker processing in the correct order because the shareable image libraries are accessed last.

I've created sucha library by I'm worried because a LIB/LIST/NAMES doesn't list my symbol and when I try to link the linker is looking for SYS$COMMON:[SYSLIB]SYS$BASE_IMAGE.EXE (not SYS$LOADABLE_IMAGES). I vaguely recall a logical being required to point to the correct directory but was it /exec/system?

[H.Becker]

(OK, I give up on my first name. Again, I apologize for the layout.)

>>> 1 - The Linker manual says that the equivalent to /SYSEXE when using a Linker options file is
ALPHA$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE/SHARE and doesn't mention /SELECTIVE.

Please have a look at the 8.3 linker manual

2.4 Resolving Symbols Defined in the OpenVMS Executive
For I64 linking, you link against the OpenVMS executive by specifying the
/SYSEXE qualifier. When this qualifier is specified, the linker selectively
^^^^^^^^^^^
processes the system shareable image, SYS$BASE_IMAGE.EXE, located in the
directory pointed to by the logical name IA64$LOADABLE_IMAGES. The linker
does not process SYS$BASE_IMAGE.EXE by default. Note that, because the
linker is processing a shareable image, references to symbols in the OpenVMS
executive are fixed up at image activation.

OK, the Alpha and VAX part of the manual wasn't updated, but it still has

6.4 Resolving Symbols Defined in the OpenVMS Executive
...
For Alpha linking, you link against the OpenVMS executive by specifying
the /SYSEXE qualifier. When this qualifier is specified, the linker selectively
^^^^^^^^^^^
processes the system shareable image, SYS$BASE_IMAGE.EXE, located in the
directory pointed to by the logical name ALPHA$LOADABLE_IMAGES. The
linker does not process SYS$BASE_IMAGE.EXE by default.

>>> 2 - Sure linking order seems to be important but if I say $ LINK A, B.OPT/OPT mean that A.OBJ gets processed first and then the
contents of linker options file B.OPT? This would mean that there should be no problem. (It is possible that the automated
procedures that we use here are merging a number of options files and might be re-ordering things - I'll investigate.)

Please have a look at the 8.3 linker manual, starting with paragraph 2.3

2.3 Ensuring Correct Symbol Resolution
For many link operations, the order in which the input files are specified in
the LINK command is not important. However, in complex link operations that
specify multiple library files or process input files selectively, correct symbol
resolution may become problematic.

>>> 3 - When you discuss using LIB$FIND_IMAGE_SYMBOL and again near the end of your response you talk about 'LNM$AL_HASHTBL' being
Double Valued Global Symbol/Version Mask". What do you mean by this? I understand the last part - which just means global address -
but are you saying that there's two addresses of the same name (presumably one in my initial address space and another because of
the activation of SYS$BASE_IMAGE.EXE?

Use analyze/image and find the symbol. Get a pre-8.3 manual, all the bits shown by analyze are described in appendix B.

>>> Module name
-----------
SYS$BASE_IMAGE
(my function)
DECC$SHR_EV56
LIBRTL
LIBOTS
SYS$PUBLIC_VECTORS
...but at the end of the .MAP file the Link command is displayed and shows my function prior to SYS$BASE_IMAGE.EXE. Is
SYS$BASE_IMAGE being processed by the Linker before my code?

Yes, an effect of /SHARE. Again, check the 8.3 manual and read 2.3.1 Understanding Cluster Creation.
The linker groups input files into clusters and processed the clusters. Without a CLUSTER= your function ends in the
DEFAULT_CLUSTER which comes after any named cluster. SYS$BASE_IMAGE/SHARE makes SYS$BASE_IMAGE a named cluster. So it is processed
before the DEFAULT_CLUSTER. DECC$SHR_EV56 and friends come from imagelib which is processed after the DEFAULT_CLUSTER. That's all
explained in the manual. And that's why I had a CLUSTER= in my example. That changes the order of input file processing!

>>> Apologies! I didn't realise my LIB$FIS example code was executing on Itanium. I've just tried it on Alpha and I get a very ugly
stackdump with non-printable characters. So scratch that plan!

Yes, scratch it, for several reasons. On the difference, there are no more double valued symbols on I64, that is in ELF.

>>> Yet another (even uglier?) possibility, build youself a little shareable image in MACRO32 (or any other language that isn't C)
linked against the base image, which exports a routine which returns the address of LNM$AL_HASHTBL.

Why? You just can figure out the right linker options file and it will work. The basics were already shown in my example.

>>> John G, I took your idea and modified it. I created a C function whose only task is to return the address of LNM$AL_HASHTBL and
put the name of this file into a named linker cluster in a Linker options file so that it is processed before
SYS$BASE_IMAGE.EXE/SHARE/SELECTIVE, which in turn is processed before my main code.

>>> It all probably would have worked fine if our automated functions didn't also put the name of my new file in the Linker options,
which meant it was linked twice. That would be bearable for a one-off build but we rebuild this code every day and we use
LIB$FIND_IMAGE_SYMBOL to access it, and L$FIS dumps a traceback every time because of compilation warnings.

So the problem is that you can't control the linker options file.

>>> Can I create a shareable image library from SYS$BASE_IMAGE.EXE and more importantly will the library contain the symbol
LNM$AL_HASHTBL? If I can link against a shareable image library I won't need to use a cluster specification to get the Linker
processing in the correct order because the shareable image libraries are accessed last.

>>> I've created sucha library by I'm worried because a LIB/LIST/NAMES doesn't list my symbol and when I try to link the linker is
looking for SYS$COMMON:[SYSLIB]SYS$BASE_IMAGE.EXE (not SYS$LOADABLE_IMAGES). I vaguely recall a logical being required to point to
the correct directory but was it /exec/system?

Von hinten durch die Brust ins Auge? The base image is a special shareable image. I would not expect this to work. And if
LNM$AL_HASHTBL is not listed by librarian, then the linker will not find it.

It would be sooo easy to just add "/SYSEXE".

[John McL]

Entschuldigen Sie bitte Hartmut aber ... your name was not displayed when I replied to your message. Und vielen Dank for your comments about Linker clusters. With your comments (and others here), the manual and some experiments I've figured out what's happening and learned a lot.

The obstacle now is the automated procedures that we use. I can't put /SYSEXE on a $ LINK command because our procedures build a composite options file for a a number of modules. Unfortunately that options file lists each of the modules before it also includes any module-specific linker options files, which in my case which means that my routine is listed at the start of the file and again in the cluster=... statement.

One solution would be to force SYS$BASE_IMAGE (with /SELECTIVE) to be in the last cluster for the Linker, or at least after the default cluster. Shared libraries are in a later cluster, so if SYS$BASE_IMAGE was seen as a shared library the problem would be solved, which is why I tried it.

Another solution would be to modify our procedures so that they did not list the modules that are already mentioned in a cluster=... statement, but those changes will require some work (check all the module-specific options files and flag any modules that should not be listed at the start of the .OPT, then create the composite options file).

Do you (or anyone else) know a means of forcing SYS$BASE_IMAGE to be processed by the Linker after the default cluster? If not I'll have to try the more complex alternative.

[Hein van den Heuvel]

>>> The obstacle now is the automated procedures that we use. I can't put /SYSEXE on a $ LINK command because our procedures build a composite options file for a a number of modules.

That doesn't compute. The /SYSEXE goes on the command line as you well know. So why worry about how option files are created? Focus on the command line. Surely there is already an option to request /DEBUG right? Can that method/principle be expanded to allow for /SYSEXE?

In a worst case, can a special module name be used to recognize the need?
Like:
$sysexe = ""
$if 1.eq.f$loc("SYSEXE_",module_name) then sysexe = "/sysexe"
:
$link 'sysexe'

Not pretty but possibly effective and sufficiently controlled?



>>> If not I'll have to try the more complex alternative

Or more simplistic solutions like hard-coding the value and checking the version.
:-) :-)

$ cc/obj=tmp sys$input:
#include< stdio>
extern LNM$AL_HASHTBL;
main() {
printf ("%X\n", LNM$AL_HASHTBL);
}
$ link/sysexe tmp

$ run tmp
8E816690


btw.... I notice a 'bonus' blank line to sys$out when using /SYSEXE ?!

td183 testdrive OpenVMS V8.3 IA64
"IA64_LINK" id "I02-31" build "XBC3-BL2-0000" 29-JUN-2006 23:20:30.12


fwiw,
Hein.

[John McL]

Hein,

You said "That doesn't compute."

I'll put it more simply.

1. The automated procedures mean that I can't just have a LINk command with the /SYSEXE.

2. The automated procedures list all modules to be linked and then append any link options files that it can find for those modules. This means that if I try to use Linker clusters my module will be listed twice (once at the start and once under the "cluster=" command).

As I asked in my posting of 10 April, does anyone know a means of forcing SYS$BASE_IMAGE.EXE to be processed by the Linker AFTER it has processed the default cluster?

[Hoff]

The build procedure here doesn't do what you need to do your job, which means you either need an exception or a modification. If you're trapped in this particular mess, then please ask your manager for guidance here, and for help draining this.

Your manager got you into this mess. Your manager can get you out. That's what your manager gets paid to do, after all.

BTW, you also likely need /NOSYSLIB with your /SYSEXE.

[H.Becker · Accepted solution]

You should ask for a change to allow the /SYSEXE in your build environment. Until you get it, you may work around the problem with temporary hacks.

For example, you can have almost nothing in your command line object (just compile a source with "static int unused;"). Then in its options file you can create a cluster for the real object. That may not work if your build environment also controls what is compiled and that all the compiled modules are included on the link command line. But that may work if you are allowed to have an OLB and if you put your real object into an OLB and create the named cluster with /include. For that you can use any options file in your link operation.

As already said, you need a reference to LNM$AL_HASHTBL before the base image is selectively searched. So you may want to create a MACRO32 object module with a reference to LNM$AL_HASHTBL in an OVR PSECT and in its options file you can include the module a second time with a cluster= option. This should not result in MULDEFs and you have the reference early enough.

There may be another hack to do what you want. The hack makes use of something which is verboten, so I don't want to discuss it here. You may want to send me an email. You can easily guess my email address at HP.