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

[chris]

On 9/29/22 23:21, hb wrote:
> On 9/29/22 5:09 PM, chris wrote:
>> On 9/28/22 08:33, Richard Levitte wrote:
>>> Hi all!
>>>
>>> I have this problem, that I want to build an app or a shareable image,
>>> which is linked with another shared library, but which also implements
>>> its own variant of symbols that are defined in that other shared library.
>>> ...
>> Can you use the "weak" keyword with one of the sets of symbols, which
>> automatically gets over ridden at link time in favour of another
>> conventionally defined same ident symbol at link time ?
> The short answer is no.
> 
> The VMS linker manual has some paragraphs about weak symbols. There it
> is said: "In general, a symbol can have only one strong or one VMS-style
> weak definition but it can have multiple UNIX-style weak definitions."
> 
> Yes, there is one exception for VMS-style weak definitions, but that
> does not apply here.
> 
> Here you want to have multiple definitions - in the shareable image and
> in the object module. So you would need to have UNIX-style weak
> definitions. These weak definitions are IA64 and x86 specific. They are
> created by the C++ compiler. If the OP's code were C++ code resulting in
> UNIX-style weak definitions then the linker would not report a
> %ILINK-W-MULDEF. Also, the IA64 shareable image's GST only contains
> strong definitions. So the object module's definition would be
> discarded. On x86 this can be different. So the source code is either
> not C++ or the language constructs used, do not result in UNIX-style
> weak definitions.
> 
> Creating a UNIX-style weak definition in other languages than C++ is not
> possible. Converting any strong (or VMS-style weak) definition into a
> UNIX-style weak definition is not possible (except you use the patch
> utility).

I guess you mean vms toolchain specific, as i've  used the weak keyword
in C in several different projects and architectures. It's a toolchain
function, compiler and linker and not normally processor specific.

Dunno, seems like the op needs to refactor the codebase so that the
linker only ever sees a single instance of a given symbol, which may
or may not include the weak keyword, if the toolchain allows it.
Serious design error though, multiple definitions for the same symbol
are bound to lead to difficulties...

Chris