Operating System - OpenVMS
1748252 Members
3797 Online
108760 Solutions
New Discussion юеВ

Re: Problem with Linker Options file on Alpha

 
SOLVED
Go to solution
John McL
Trusted Contributor

Re: Problem with Linker Options file on Alpha

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
Honored Contributor

Re: Problem with Linker Options file on Alpha

>>> 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
Trusted Contributor

Re: Problem with Linker Options file on Alpha

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
Honored Contributor

Re: Problem with Linker Options file on Alpha

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
Honored Contributor
Solution

Re: Problem with Linker Options file on Alpha

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.
John McL
Trusted Contributor

Re: Problem with Linker Options file on Alpha

Thanks Hartmut but the automated procedures assume that all modules should be listed and while I can create a program-specific Linker options files that gets merged with any other options files (and with a generic options file), using "cluster=" is of no value. I also can't set up an independent .OLB because all code gets processed by this automated procedure.

I've had the okay to modify the automated procedures to allow a Linker options to be specified in an associated file. We already do this for compiler options so I'm just extending that to the Linker. This will rarely be used but at least what it does will be supported rather than a hack. (I must admit though that I like the intellectual challenge of a hack!)

If there's no more postings here that warrant a response I'll close this thread in about 24 hours time.
John McL
Trusted Contributor

Re: Problem with Linker Options file on Alpha

I've now resolved this problem by modifying our command procedures to accept Linker qualifiers so that /SYSEXE can be added.

I've learnt a lot from this thread. My thanks to all, especially H, H, J & J.

The very brief summary for anyone reading this in the hope that it solves their own problem is ... read the Linker manual very closely, particularly the sections about ensuring correct symbol resolution and how to resolve symbols defined in the system executive.

As at the Linker manual for v8.3, these are section 6.3 and 6.4 if you are dealing with Alpha.

And with reference to the root cause of all this, the problem of logical names that contain non-printable characters, we'll send HP a formal request to cater for these situations.
John McL
Trusted Contributor

Re: Problem with Linker Options file on Alpha

Closed.