You can use the -( and -) arguments to parenthesize groups of .a
files which are then mutually resolved.
Using this option has a significant performance cost. It is best
In article
<87v9ayk...@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rwei...@talktalk.net> wrote:
That's the GNU binutils linker and changing the default behaviour would probably break backwards-compatibility.I don't see how. Modern machines have enough memory to put
definitions in a hash table by name and object file. If the
library name is repeated, a double indexing allows the previous
definitions to be deleted as the new object definitions are
loaded. I have no pity anyone using load order for such esoteric
reasons that that would still break.
I started unices in 1980. I appreciated at the time why ld had to
be stupid. I didn't expect people demand ld remain stupid when vm
broke the 65KB and then 4MB boundaries.
In article
<87mtwaw...@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rwei...@talktalk.net> wrote:
Siri Cruise <chine...@yahoo.com> writes:
Is linux ld sensitive to the file order the way macosx ld isn't?
That would be so 1970s.
I get a file list like -Llib -lgc -lcord ... -lm -liconv ... x.o
y.o z.o . Loads fine on macosx. On linux it whines about missing
symbols that I verify with nm are in libgc.a .
It is.I had two cc in the makefile. To test I changed the one not
called and missed the other. So changing the order didn't appear
to work. It wasn't until I changed the order in both places that
I realised linux is still using an ancient and archaic ld.
Now I get to fix new and exciting crap.
#define _GNU_SOURCE
#define __USE_GNU
If you've found a case where both of those are required, the glibc people will presumably take it as bug and request an example so they can fix it (...or explain how what you're doing is wrong...)
You're not suggesting, are you, that I can't write my own memcpy, put
it in memcpy.a, and link it into my C program, overriding the function defined in libc?
If it doesn't work that way, how is the linker supposed to choose
between two implementations of a function defined in two
libraries?
"error: multiply defined symbol foo", I would hope.
On Sun, 14 Feb 2021 20:35:06 -0000 (UTC)
Kaz Kylheku <563-365-8930@kylheku.com> wrote:
If it doesn't work that way, how is the linker supposed to choose
between two implementations of a function defined in two
libraries?
"error: multiply defined symbol foo", I would hope.
No, of course not. The One Definition Rule applies to data, not
functions.
You're not suggesting, are you, that I can't write my own memcpy, put
it in memcpy.a, and link it into my C program, overriding the function defined in libc?
On Sun, 14 Feb 2021 20:35:06 -0000 (UTC)
Kaz Kylheku <563-365-8930@kylheku.com> wrote:
If it doesn't work that way, how is the linker supposed to choose
between two implementations of a function defined in two
libraries?
"error: multiply defined symbol foo", I would hope.
No, of course not. The One Definition Rule applies to data, not
functions.
On Sun, 14 Feb 2021 20:35:06 -0000 (UTC)
Kaz Kylheku <563-365-8930@kylheku.com> wrote:
If it doesn't work that way, how is the linker supposed to choose
between two implementations of a function defined in two
libraries?
"error: multiply defined symbol foo", I would hope.
No, of course not. The One Definition Rule applies to data, not
functions.
You're not suggesting, are you, that I can't write my own memcpy, put
it in memcpy.a, and link it into my C program, overriding the function defined in libc?
One of us doesn't understand the other. I prepared for that person to
be me, but right now I'm baffled at the discussion.
It's quite common for implementations to define the behavior when
multiple definitions are available, in a way that's convenient.
You're not suggesting, are you, that I can't write my own memcpy,
put it in memcpy.a, and link it into my C program, overriding the
function defined in libc?
Since something like that could happen by accident, there is something
to be said for having it diagnosed if it literally occurs as above.
Yet, some sort of documented extension can exist for doing the
override.
It could just be the above, with the presence of the diagnostic.
do nl $F; done1 extern void foo(void);
I contend it's normal, and
useful, and traditional for the linker to resolve symbols from
libraries in the order in which the libraries are presented, full
stop. Perhaps that behavior was the product of limited resources in
the PDP/11 era, but it is also convenient, flexible, and
deterministic.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 292 |
Nodes: | 16 (2 / 14) |
Uptime: | 194:49:46 |
Calls: | 6,616 |
Files: | 12,166 |
Messages: | 5,315,463 |