[Info-vax] Linking problem with multiply defined symbols, how to resolve?

[hb]

On 9/30/22 16:30, Richard Levitte wrote:
> onsdag 28 september 2022 kl. 14:41:09 UTC+2 skrev hb:
>> $ link bar,tt:/opt/map=bar/cross/full
>> foo/share
>> ^Z
>> %LINK-W-MULDEF, symbol FOOBAR multiply defined
>> in module BAR file DSA3:[DECUSERVE_USER]BAR.OBJ;3
>> $
>>
>> then using a linker cluster and /selective will work for for you:
>>
>> $ link/exe=bar/map=bar/cross/full tt:/opt
>> cluster=a,,,bar
>> foo/share/sel
>> ^Z
>> $
> 
> So this is the part that's a mystery to me...  and I gotta confess, 'cluster' is magic to me, I haven't been able to wrap my brains around it and have never really used it other than as an incantation that someone else gave me.
> 
> See, I've actually tried /SELECTIVE before, believing the documentation that essentially says "... only those symbols that have been referenced by previously processed input files".  However, when I tried just adding it to the shareable image in my example, I ended up with a shitload of undefined symbol references instead, like this:
> 
> %ILINK-W-USEUNDEF, undefined symbol OSSL_PARAM_locate referenced
> 	section: $CODE$
> 	offset: %X0000000000000040  slot: 2
> 	module: digestcommon
> 	file: USR_DISK:[RICLE.TEST.openssl-3_1_0-dev.providers]LIBCOMMON.OLB;1
> 
> Looking at it all now, with your example in mind, I can only assume that my assumption that files given in the /OPT file are treated top to bottom as written is more like a delusion, and that CLUSTER helps getting things processed in the order I desire.

Please have a look at the linker manual, 2.2.4. Processing Input Files 
Selectively, and 2.3.1. Understanding Cluster Creation.

The linker processes input files in cluster order. With object modules 
on the command line or in the options file, the object module is 
collected into the "DEFAULT_CLUSTER". Any shareable image specified in 
the options file is put in its own cluster (it's shareable image name) 
in the order of the options file, no matter if it is selectively 
processed or not. All such "user defined" clusters are put into the 
cluster list before the default cluster.

So a
$ link/exe=bar/map=bar/cross/full bar,tt:/opt
foo/share/sel
^Z
will create the cluster FOO, which is processed before the 
DEFAULT_CLUSTER, that is before the object module bar. Obviously at the 
time processing the shareable foo, there is no undefined symbol which 
can be "selectively" resolved from it. After processing bar, there is. 
But the linker is done with cluster FOO, the shareable image, hence you 
get the W-USEUNDEF.

$ link/exe=bar/map=bar/cross/full tt:/opt
cluster=a,,,bar
foo/share/sel
^Z
lets the linker put bar into the cluster A before the cluster FOO of the 
shareable image. Now bar is processed before the shareable foo and the 
unresolved symbol can be "selectively" resolved from the shareable image.

FWIW,
$ link/exe=bar/map=bar/cross/full tt:/opt
foo/share/sel
cluster=a,,,bar
^Z
also results in an W-USEUNDEF as well as
$ link/exe=bar/map=bar/cross/full tt:/opt
bar
foo/share/sel
^Z

And this processing of input files in cluster order explains why you 
initially got a duplicate reported for the object module and not for the 
shareable image, and why the symbol is resolved from the shareable image 
and not from the object module.