std library hooks

Manu turkeyman at gmail.com
Sun Apr 15 02:18:30 PDT 2012


On 15 April 2012 07:09, Walter Bright <newshound2 at digitalmars.com> wrote:

> I just tried it, and I got the error I expected:
>>
>> LIBCMTD.lib(atox.obj) : error LNK2005: _atoi already defined in Unit.obj
>>
>> In C, I would always explicitly declare weak linkage to do this... what's
>> the
>> point of the weak attribute if not for this?
>>
>
> First you need to find out why you have multiple definitions of the same
> symbol being linked together. For example, do not specify libcmtd.lib to
> the linker, then link, then see what your unresolved symbols are.
>

I have multiple definitions because I defined a function from the lib in
one of my own objects, and then they get linked together.
If I were to not specify libcmtd, every CRT call would be unresolved,
except atoi in this case which I implemented in one of my objects. The
point is, if I implement a function from a library, I get the behaviour I
expect, which is the linker complains about multiply defined symbols. Your
saying though, that I should be able to implement a library function in my
own code, and that will somehow be found prior to searching the libs, and
since the symbol is resolved, the lib search will not take place.
How is the linker supposed to know which instance (my one in a loose .o
file, or the one in the lib) is actually 'my' one? What if it was contained
in 2 different libs, rather than one in a lib, and the other in a bundle of
loose object files?

When and how can I expect the behaviour you propose? I don't follow the
requirements... or the logic the linker could follow. At link time, it no
longer know's what's mine from what's in any given libs...
As far as I was aware, I thought it DID just link every single thing given
together in one huge blob, and then strips the unreferenced stuff as a post
process.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120415/ca82f29b/attachment.html>


More information about the Digitalmars-d mailing list