* Re: ld and common symbols
@ 1999-12-21 14:06 Nick Clifton
0 siblings, 0 replies; 5+ messages in thread
From: Nick Clifton @ 1999-12-21 14:06 UTC (permalink / raw)
To: Philip.Blundell; +Cc: binutils
Hi Philip,
: OK, thanks. Unfortunately the GNU C library seems to rely on the old
: behaviour. I will discuss it with the libc folks.
Can you keep me in the loop for this please ? If it turns out that
too many object ti the patch then I guess I am the guy that is going
to have to change it.
Cheers
Nick
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ld and common symbols
1999-12-21 13:50 Nick Clifton
1999-12-21 14:04 ` Philip Blundell
@ 1999-12-21 15:44 ` Roland McGrath
1 sibling, 0 replies; 5+ messages in thread
From: Roland McGrath @ 1999-12-21 15:44 UTC (permalink / raw)
To: Nick Clifton; +Cc: Philip.Blundell, binutils
> I think we would all agree that if t2.c had contained this line:
>
> int bar = 2;
>
> then the linker would have been justified in issueing the error about
> a multiply defined symbol. I am not sure however, what the concessus
> will be for the correct behaviour in the case you outline above.
> Persoanlly I think the linker is doing the right thing in complaining,
> since bar ought to only be defined and initlaised in one palce, and
> the other files ought to just contain references to it.
Sorry, you are just completely wrong. This is what common definitions
(i.e. uninitialized C variables) have always done. Didn't we just cover this?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ld and common symbols
1999-12-21 13:50 Nick Clifton
@ 1999-12-21 14:04 ` Philip Blundell
1999-12-21 15:44 ` Roland McGrath
1 sibling, 0 replies; 5+ messages in thread
From: Philip Blundell @ 1999-12-21 14:04 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
>It is intentional.
>
>This change is in order to match the behaviour of the native linkers
>for Solaris and HP-UX (and possibly others, we haven't tested), and is
>also necessary in order to allow libraries of FORTRAN generates
>objects to be correctly linked together.
OK, thanks. Unfortunately the GNU C library seems to rely on the old
behaviour. I will discuss it with the libc folks.
p.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ld and common symbols
@ 1999-12-21 13:50 Nick Clifton
1999-12-21 14:04 ` Philip Blundell
1999-12-21 15:44 ` Roland McGrath
0 siblings, 2 replies; 5+ messages in thread
From: Nick Clifton @ 1999-12-21 13:50 UTC (permalink / raw)
To: Philip.Blundell; +Cc: binutils
Hi Phillip,
: Using the latest binutils from CVS I am seeing what seems to be a change in
: behaviour relating to ld and common symbols.
:
: With a test like this:
:
: $ cat >t1.c
: int foo; /* common */
: int bar = 1; /* initialised */
: ^D
: $ cat >t2.c
: int foo = 1; /* initialised */
: int bar = 1; /* initialised */
: ^D
: $ gcc -c t1.c
: $ gcc -c t2.c
: $ ar cq t.a t2.o
: $ ld t1.o t.a
:
: older versions of the linker seemed to be content with the common declaration
: of `foo' in t1.o. The current linker instead favours pulling in the archive
: member in order to get an initialised definition of `foo'. In this case that
: causes `bar' to be multiply defined and so you get a link error.
:
: This patch seems a likely candidate for having caused the change, though I
: haven't verified that this is the case.
:
: 1999-12-10 Nick Clifton <nickc@cygnus.com>
:
: * elflink.h (elf_link_is_defined_archive_symbol): New
: function: Decide if a symbol, in an archive map is there
: because it is defined in the archive element, or because it is
: just another common declaration of it.
: (elf_link_add_archive_symbols): Use
: elf_link_is_defined_archive_symbol to decide if an archive
: element contain a reference to a common symbol should be
: linked in or not.
:
: Can anybody explain whether the "new" behaviour is intentional or accidental?
It is intentional.
This change is in order to match the behaviour of the native linkers
for Solaris and HP-UX (and possibly others, we haven't tested), and is
also necessary in order to allow libraries of FORTRAN generates
objects to be correctly linked together.
I think we would all agree that if t2.c had contained this line:
int bar = 2;
then the linker would have been justified in issueing the error about
a multiply defined symbol. I am not sure however, what the concessus
will be for the correct behaviour in the case you outline above.
Persoanlly I think the linker is doing the right thing in complaining,
since bar ought to only be defined and initlaised in one palce, and
the other files ought to just contain references to it.
Cheers
Nick
^ permalink raw reply [flat|nested] 5+ messages in thread
* ld and common symbols
@ 1999-12-21 13:20 Philip Blundell
0 siblings, 0 replies; 5+ messages in thread
From: Philip Blundell @ 1999-12-21 13:20 UTC (permalink / raw)
To: binutils
Using the latest binutils from CVS I am seeing what seems to be a change in
behaviour relating to ld and common symbols.
With a test like this:
$ cat >t1.c
int foo; /* common */
int bar = 1; /* initialised */
^D
$ cat >t2.c
int foo = 1; /* initialised */
int bar = 1; /* initialised */
^D
$ gcc -c t1.c
$ gcc -c t2.c
$ ar cq t.a t2.o
$ ld t1.o t.a
older versions of the linker seemed to be content with the common declaration
of `foo' in t1.o. The current linker instead favours pulling in the archive
member in order to get an initialised definition of `foo'. In this case that
causes `bar' to be multiply defined and so you get a link error.
This patch seems a likely candidate for having caused the change, though I
haven't verified that this is the case.
1999-12-10 Nick Clifton <nickc@cygnus.com>
* elflink.h (elf_link_is_defined_archive_symbol): New
function: Decide if a symbol, in an archive map is there
because it is defined in the archive element, or because it is
just another common declaration of it.
(elf_link_add_archive_symbols): Use
elf_link_is_defined_archive_symbol to decide if an archive
element contain a reference to a common symbol should be
linked in or not.
Can anybody explain whether the "new" behaviour is intentional or accidental?
Thanks
p.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-12-21 15:44 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-12-21 14:06 ld and common symbols Nick Clifton
-- strict thread matches above, loose matches on Subject: below --
1999-12-21 13:50 Nick Clifton
1999-12-21 14:04 ` Philip Blundell
1999-12-21 15:44 ` Roland McGrath
1999-12-21 13:20 Philip Blundell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).