[Info-vax] Linking problem with multiply defined symbols, how to resolve?
hb
end.of at inter.net
Mon Oct 3 04:18:38 EDT 2022
On 10/3/22 01:21, Simon Clubley wrote:
> 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" */
> ...
> 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.
$ gcc -v
...
gcc version 10.2.1 20210110 (Debian 10.2.1-6)
$ gcc -Wall -o one one.c two.c
/usr/bin/ld: /tmp/ccTDBf9g.o:(.bss+0x0): multiple definition of
`gbl_val'; /tmp/ccXuTT0f.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
$ gcc -Wall -fcommon -o one one.c two.c
$
They changed the default, which is now -fno-common.
More information about the Info-vax
mailing list