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

[Simon Clubley]

On 2022-09-30, hb <end.of at inter.net> wrote:
> On 9/30/22 19:24, Simon Clubley wrote:
>> On 2022-09-30, Johnny Billquist <bqt at softjar.se> wrote:
>>>
>>> Maybe I wasn't paying attention. I don't think I've seen a previous
>>> suggested solution that applies to VMS. And the solution for Unix from
>>> which this started is questionable how well it actually works (not
>>> entirely clear *which* symbol would in the end be the one your
>>> application would resolve to).
>>>
>> 
>> _IF_ I understand what is being asked for here (two different source code
>> modules both defining the same global symbol name), then it doesn't matter
>> in Unix provided both symbols are the same size, and of the same type, as
>> the code in both modules will end up referencing the same memory area.
>
> Did you actually try this? On Linux with gcc and binutils I get
> /usr/bin/ld: two.o:(.bss+0x0): multiple definition of `same'; 
> one.o:(.bss+0x0): first defined here
> collect2: error: ld returned 1 exit status
>

one.c:

/* Compile with: "gcc -Wall -o one one.c two.c" */

#include <stdio.h>

int gbl_val;

void two();

int main(int argc, char *argv[])
        {
        gbl_val = 1;
        two();
        printf("one: gbl_val = %d\n", gbl_val);
        return 0;
        }

two.c:

#include <stdio.h>

int gbl_val;

void two()
        {
        printf("two: gbl_val = %d\n", gbl_val);
        gbl_val = 2;
        }

That works just fine for me on Linux (unfortunately :-().

[deleted at deleted ~]$ ./one
two: gbl_val = 1
one: gbl_val = 2

If it's not working for you, then it's a recent change in one of Linux,
binutils, or gcc that's likely to break at least some code, because while
I would never write something so hideous, I have seen it present in other
code.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.