Whenever I use array ops in multi-module projects, I always seem to run into "Previous definition different" linker errors.  This seems to occur when I call the same array op using library function from multiple modules in the same project.  Moving things around to different modules and recompiling always seems to solve them at the expense of uglifying my code. Unfortunately, this is one of those frustrating bugs that only seems to occur on real-world code, i.e. code that has multiple modules, lots of indirection, libraries, etc.  I can't for the life of me come up with a reduced test case.

Has anyone else been experiencing similar issues?  Alternatively, can someone with a better mental model of how things work at the binary level please suggest how this bug might be reproduced in a test case that's less than 20 thousand lines of code?  (I find linker bugs very difficult to isolate and file bug reports on because I have no mental model of how things work at that low a level.  My mental model basically only goes down to assembly language, not the process of turning a pile of assembly language files into a working executable or shared library.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110215/34671523/attachment.html>

The complete linker error with mangled symbol name and the candidate code generating the symbol in the first place is probably enough. At one point, I posted an error message, and Don was able to infer everything else without seeing a line of my code. That might not be the case here, but it's probably the bulk of the needed info.

Sent from my iPhone

On Feb 15, 2011, at 11:33 AM, David Simcha <dsimcha at gmail.com> wrote:

> Whenever I use array ops in multi-module projects, I always seem to run into "Previous definition different" linker errors.  This seems to occur when I call the same array op using library function from multiple modules in the same project.  Moving things around to different modules and recompiling always seems to solve them at the expense of uglifying my code.  Unfortunately, this is one of those frustrating bugs that only seems to occur on real-world code, i.e. code that has multiple modules, lots of indirection, libraries, etc.  I can't for the life of me come up with a reduced test case.
> 
> Has anyone else been experiencing similar issues?  Alternatively, can someone with a better mental model of how things work at the binary level please suggest how this bug might be reproduced in a test case that's less than 20 thousand lines of code?  (I find linker bugs very difficult to isolate and file bug reports on because I have no mental model of how things work at that low a level.  My mental model basically only goes down to assembly language, not the process of turning a pile of assembly language files into a working executable or shared library.)
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Never mind, I got it.  http://d.puremagic.com/issues/show_bug.cgi?id=5592
The thing that made it hard to reproduce was that I was using the wrong
array op.  What the heck is the difference between
__arrayExpSliceMulSliceAddass_d and
__arraySliceExpMulSliceAddass_d anyhow?  From what I can tell, which one
gets called depends on the order you write your array op in.  arr1[] += num
* arr2[] calls __arrayExpSliceMulSliceAddass_d and arr1[] += arr2[] * num
calls __arraySliceExpMulSliceAddass_d .  Isn't multiplication commutative
even in inexact floating point arithmetic?  Why two functions?

On Tue, Feb 15, 2011 at 12:07 PM, Jason House <jason.james.house at gmail.com>wrote:

> The complete linker error with mangled symbol name and the candidate code generating the symbol in the first place is probably enough. At one point, I posted an error message, and Don was able to infer everything else without seeing a line of my code. That might not be the case here, but it's probably the bulk of the needed info.
>
> Sent from my iPhone
>
> On Feb 15, 2011, at 11:33 AM, David Simcha <dsimcha at gmail.com> wrote:
>
> > Whenever I use array ops in multi-module projects, I always seem to run
> into "Previous definition different" linker errors.  This seems to occur
> when I call the same array op using library function from multiple modules
> in the same project.  Moving things around to different modules and
> recompiling always seems to solve them at the expense of uglifying my code.
>  Unfortunately, this is one of those frustrating bugs that only seems to
> occur on real-world code, i.e. code that has multiple modules, lots of
> indirection, libraries, etc.  I can't for the life of me come up with a
> reduced test case.
> >
> > Has anyone else been experiencing similar issues?  Alternatively, can
> someone with a better mental model of how things work at the binary level please suggest how this bug might be reproduced in a test case that's less than 20 thousand lines of code?  (I find linker bugs very difficult to isolate and file bug reports on because I have no mental model of how things work at that low a level.  My mental model basically only goes down to assembly language, not the process of turning a pile of assembly language files into a working executable or shared library.)
> > _______________________________________________
> > dmd-internals mailing list
> > dmd-internals at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/dmd-internals
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110215/259f31d3/attachment.html>

BTW, to deal with annoying errors like this, how hard would it be to compare implementations when a symbol is defined multiple times and, if the implementations are identical, just pick one and use it?  Of course I know in the short term this is hard b/c OPTLINK isn't translated to C yet, but let's assume longer term that we will have a sane linker codebase.

On Tue, Feb 15, 2011 at 12:33 PM, David Simcha <dsimcha at gmail.com> wrote:

> Never mind, I got it.  http://d.puremagic.com/issues/show_bug.cgi?id=5592
> The thing that made it hard to reproduce was that I was using the wrong
> array op.  What the heck is the difference between
> __arrayExpSliceMulSliceAddass_d and
> __arraySliceExpMulSliceAddass_d anyhow?  From what I can tell, which one
> gets called depends on the order you write your array op in.  arr1[] += num
> * arr2[] calls __arrayExpSliceMulSliceAddass_d and arr1[] += arr2[] * num
> calls __arraySliceExpMulSliceAddass_d .  Isn't multiplication commutative
> even in inexact floating point arithmetic?  Why two functions?
>
>
> On Tue, Feb 15, 2011 at 12:07 PM, Jason House <jason.james.house at gmail.com
> > wrote:
>
>> The complete linker error with mangled symbol name and the candidate code generating the symbol in the first place is probably enough. At one point, I posted an error message, and Don was able to infer everything else without seeing a line of my code. That might not be the case here, but it's probably the bulk of the needed info.
>>
>> Sent from my iPhone
>>
>> On Feb 15, 2011, at 11:33 AM, David Simcha <dsimcha at gmail.com> wrote:
>>
>> > Whenever I use array ops in multi-module projects, I always seem to run
>> into "Previous definition different" linker errors.  This seems to occur
>> when I call the same array op using library function from multiple modules
>> in the same project.  Moving things around to different modules and
>> recompiling always seems to solve them at the expense of uglifying my code.
>>  Unfortunately, this is one of those frustrating bugs that only seems to
>> occur on real-world code, i.e. code that has multiple modules, lots of
>> indirection, libraries, etc.  I can't for the life of me come up with a
>> reduced test case.
>> >
>> > Has anyone else been experiencing similar issues?  Alternatively, can
>> someone with a better mental model of how things work at the binary level please suggest how this bug might be reproduced in a test case that's less than 20 thousand lines of code?  (I find linker bugs very difficult to isolate and file bug reports on because I have no mental model of how things work at that low a level.  My mental model basically only goes down to assembly language, not the process of turning a pile of assembly language files into a working executable or shared library.)
>> > _______________________________________________
>> > dmd-internals mailing list
>> > dmd-internals at puremagic.com
>> > http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110215/1a3a233d/attachment-0001.html>

On Tuesday, February 15, 2011 09:38:48 David Simcha wrote:
> BTW, to deal with annoying errors like this, how hard would it be to compare implementations when a symbol is defined multiple times and, if the implementations are identical, just pick one and use it?  Of course I know in the short term this is hard b/c OPTLINK isn't translated to C yet, but let's assume longer term that we will have a sane linker codebase.

C linkers don't normally work that way. If they did, you wouldn't generally get multiple definition errors and the like. So, while it might be theoretically reasonable, it might be too much of a change from how linking normally works. And since it would ultimately just be optlink which would work that way, would it really be a good idea anyway? As soon as you tried your code with another linker - e.g. by compiling on Liunx - it would fail.

- Jonathan M Davis

This isn't specific to optlink or windows.  The same occurs with posix linkers as well.  If the symbols were identical, then there wouldn't be a size mismatch warning.  That the size differs means that they aren't.  The key questions are, what's different and why?

On 2/15/2011 9:38 AM, David Simcha wrote:
> BTW, to deal with annoying errors like this, how hard would it be to compare implementations when a symbol is defined multiple times and, if the implementations are identical, just pick one and use it?  Of course I know in the short term this is hard b/c OPTLINK isn't translated to C yet, but let's assume longer term that we will have a sane linker codebase.
> 
> On Tue, Feb 15, 2011 at 12:33 PM, David Simcha <dsimcha at gmail.com <mailto:dsimcha at gmail.com>> wrote:
> 
>     Never mind, I got it.  http://d.puremagic.com/issues/show_bug.cgi?id=5592  The thing that made it hard to reproduce
>     was that I was using the wrong array op.  What the heck is the difference between __arrayExpSliceMulSliceAddass_d and
>     __arraySliceExpMulSliceAddass_d anyhow?  From what I can tell, which one gets called depends on the order you write
>     your array op in.  arr1[] += num * arr2[] calls __arrayExpSliceMulSliceAddass_d and arr1[] += arr2[] * num calls
>     __arraySliceExpMulSliceAddass_d .  Isn't multiplication commutative even in inexact floating point arithmetic?  Why
>     two functions?
> 
> 
>     On Tue, Feb 15, 2011 at 12:07 PM, Jason House <jason.james.house at gmail.com <mailto:jason.james.house at gmail.com>> wrote:
> 
>         The complete linker error with mangled symbol name and the candidate code generating the symbol in the first
>         place is probably enough. At one point, I posted an error message, and Don was able to infer everything else
>         without seeing a line of my code. That might not be the case here, but it's probably the bulk of the needed info.
> 
>         Sent from my iPhone
> 
>         On Feb 15, 2011, at 11:33 AM, David Simcha <dsimcha at gmail.com <mailto:dsimcha at gmail.com>> wrote:
> 
>         > Whenever I use array ops in multi-module projects, I always seem to run into "Previous definition different"
>         linker errors.  This seems to occur when I call the same array op using library function from multiple modules
>         in the same project.  Moving things around to different modules and recompiling always seems to solve them at
>         the expense of uglifying my code.  Unfortunately, this is one of those frustrating bugs that only seems to occur
>         on real-world code, i.e. code that has multiple modules, lots of indirection, libraries, etc.  I can't for the
>         life of me come up with a reduced test case.
>         >
>         > Has anyone else been experiencing similar issues?  Alternatively, can someone with a better mental model of
>         how things work at the binary level please suggest how this bug might be reproduced in a test case that's less
>         than 20 thousand lines of code?  (I find linker bugs very difficult to isolate and file bug reports on because I
>         have no mental model of how things work at that low a level.  My mental model basically only goes down to
>         assembly language, not the process of turning a pile of assembly language files into a working executable or
>         shared library.)

David Simcha wrote:
> BTW, to deal with annoying errors like this, how hard would it be to compare implementations when a symbol is defined multiple times and, if the implementations are identical, just pick one and use it?

That happens already if the symbol is defined as a COMDAT.