On Linux, the following gives out a "multiple definition" error, as expected:

    c/test.c:
    void dotest(void) { printf("C\n"); }

    d/test.d:
    extern(C) void dotest() { writeln("D"); }

On OS X no error is flagged, and the C function is always called, irrespective of which order I specify the .o files to link. Yet, compiling and linking two .c files with a duplication symbol does give an error on the linking phase, as expected. So why the discrepancy? I'm guessing the cause is the section where the symbols appear:

On Ubuntu:

    $ nm d/test.o | grep dotest; echo "--"; nm c/test.o | grep dotest
    0000000000000000 T dotest
    --
    0000000000000000 T dotest

On OS X:

    $ nm d/test.o | grep dotest; echo "--"; nm c/test.o | grep dotest
    0000000000001490 S _dotest   <-- not in text section, as in Linux
    --
    0000000000000000 T _dotest
    0000000000000060 S _dotest.eh

As you might imagine, this situation can be highly disruptive (I'm progressively converting a C application to D). Do you know why the functions appear in the S section on OS X? Do you know of any workaround, to assure that duplicate symbols are correctly flagged?

On 2013-08-30 00:04, "Luís Marques" <luis@luismarques.eu>" wrote:
> On Linux, the following gives out a "multiple definition" error, as
> expected:
>
>      c/test.c:
>      void dotest(void) { printf("C\n"); }
>
>      d/test.d:
>      extern(C) void dotest() { writeln("D"); }
>
> On OS X no error is flagged, and the C function is always called,
> irrespective of which order I specify the .o files to link. Yet,
> compiling and linking two .c files with a duplication symbol does give
> an error on the linking phase, as expected. So why the discrepancy? I'm
> guessing the cause is the section where the symbols appear:
>
> On Ubuntu:
>
>      $ nm d/test.o | grep dotest; echo "--"; nm c/test.o | grep dotest
>      0000000000000000 T dotest
>      --
>      0000000000000000 T dotest
>
> On OS X:
>
>      $ nm d/test.o | grep dotest; echo "--"; nm c/test.o | grep dotest
>      0000000000001490 S _dotest   <-- not in text section, as in Linux
>      --
>      0000000000000000 T _dotest
>      0000000000000060 S _dotest.eh
>
> As you might imagine, this situation can be highly disruptive (I'm
> progressively converting a C application to D). Do you know why the
> functions appear in the S section on OS X? Do you know of any
> workaround, to assure that duplicate symbols are correctly flagged?

How does it behave on Mac OS X if you just use C?

-- 
/Jacob Carlborg

On Friday, 30 August 2013 at 06:37:07 UTC, Jacob Carlborg wrote:
> How does it behave on Mac OS X if you just use C?

That fails, as expected.

(I tried to explain that, I'm sorry if I wasn't clear: )
>> On OS X no error is flagged, and the C function is always called, irrespective of which order I specify the .o files to link. Yet, compiling and linking two .c files with a duplication symbol does give an error on the linking phase, as expected.

On 2013-08-30 16:10, "Luís Marques" <luis@luismarques.eu>" wrote:

> That fails, as expected.

So DMD and Clang uses different sections? Have you tried GDC or LDC?

-- 
/Jacob Carlborg

On Saturday, 31 August 2013 at 11:16:11 UTC, Jacob Carlborg wrote:
> So DMD and Clang uses different sections? Have you tried GDC or LDC?

Sorry for the delay.

Using LDC fails, as expected / desired:

    duplicate symbol _dotest in:
        d/test.o
        c/test.o
    ld: 1 duplicate symbol for architecture x86_64

The LDC .o sections are the same as the C version:

    $ nm d/test.o | grep dotest; echo "--"; nm c/test.o | grep dotest
    0000000000000000 T _dotest
    00000000000000b0 S _dotest.eh
    --
    0000000000000000 T _dotest
    0000000000000060 S _dotest.eh

I haven't tried GDC (I get the object.d not found error, even after installing the D .dmg package, instead of using brew, and I don't recall how I used to solve that), but I imagine it would also fail-work (detect the duplicate symbol, and fail compilation).

On 2013-09-04 00:36, "Luís Marques" <luis@luismarques.eu>" wrote:

> Sorry for the delay.
>
> Using LDC fails, as expected / desired:
>
>      duplicate symbol _dotest in:
>          d/test.o
>          c/test.o
>      ld: 1 duplicate symbol for architecture x86_64
>
> The LDC .o sections are the same as the C version:
>
>      $ nm d/test.o | grep dotest; echo "--"; nm c/test.o | grep dotest
>      0000000000000000 T _dotest
>      00000000000000b0 S _dotest.eh
>      --
>      0000000000000000 T _dotest
>      0000000000000060 S _dotest.eh
>
> I haven't tried GDC (I get the object.d not found error, even after
> installing the D .dmg package, instead of using brew, and I don't recall
> how I used to solve that), but I imagine it would also fail-work (detect
> the duplicate symbol, and fail compilation).

Perhaps time to file a bug report. I don't know if there's a reason to not use the same sections as C does.

http://d.puremagic.com/issues/

-- 
/Jacob Carlborg

On Wednesday, 4 September 2013 at 06:36:24 UTC, Jacob Carlborg wrote:
> Perhaps time to file a bug report. I don't know if there's a reason to not use the same sections as C does.

I posted it here hoping Walter might comment on this. Maybe he had a good reason to choose a different section. I'll wait a while, and if no feedback is given ("it really has to be a different section because X, Y, Z"), I'll post a bug report.

On Wednesday, 4 September 2013 at 12:41:52 UTC, Luís Marques wrote:
> I posted it here hoping Walter might comment on this. Maybe he had a good reason to choose a different section. I'll wait a while, and if no feedback is given ("it really has to be a different section because X, Y, Z"), I'll post a bug report.

Since Walter did not comment on this, I posted a bug: http://d.puremagic.com/issues/show_bug.cgi?id=11199

I didn't see DMD v2.063.2 in the list of DMD versions, so I chose D2 in the bug report.