Hello, I'm trying to use LDC (via LDMD2) to compile a "runnable" module.
When no static library is used it works fine but when I try a complex runnable, I get a huge amount of messages (about 1200!) related to "__dmd_personality_v0" (and "_d_throwdwarf") even if all the static libraries used by the runnable have been themselves recompiled with LDMD2.

system spec:
- Opensuse 13.2 x86_64
- LDC 1.0.0-beta2

Any idea of what's happening ?

example messages:
__________________
/usr/include/dmd/phobos/std/conv.d:(.text._D3std4conv15__T5parseTwTAaZ5parseFNaNfKAaZw+0xbf): référence indéfinie vers « _d_throwdwarf »
/home/basile/Dev/dproj/kheops/bin/kheops.a(conv_9d8_9ff.o):(.eh_frame+0x13): référence indéfinie vers « __dmd_personality_v0 »
/home/basile/Dev/dproj/kheops/bin/kheops.a(properties.o):(.eh_frame+0x13): référence indéfinie vers « __dmd_personality_v0 »
/home/basile/Dev/dproj/kheops/bin/kheops.a(rtti.o):(.eh_frame+0x13): référence indéfinie vers « __dmd_personality_v0 »
/home/basile/Dev/dproj/kheops/bin/kheops.a(serializer.o):(.eh_frame+0x13): référence indéfinie vers « __dmd_personality_v0 »
/home/basile/Dev/dproj/kheops/bin/kheops.a(types.o):(.eh_frame+0x13): référence indéfinie vers « __dmd_personality_v0 »
/home/basile/Dev/dproj/kheops/bin/kheops.a(canvas.o):(.eh_frame+0x13): encore plus de références indéfinies suivent vers « __dmd_personality_v0 »
__________________

It looks like the compilation is OK but that's the linking phase that fails. However the invalid symbol name comes from LDC.

Hi there,

On 1 Jun 2016, at 18:13, Basile B. via digitalmars-d-ldc wrote:
> It looks like the compilation is OK but that's the linking phase that fails. However the invalid symbol name comes from LDC.

It comes from some object file/static library compiled with DMD. You mentioned that you had recompiled all the libraries with LDC, but one must have slipped through the cracks. LDC does not emit those symbols.

 — David

On Wednesday, 1 June 2016 at 17:18:01 UTC, David Nadlinger wrote:
> [...] but one must have slipped through the cracks. LDC does not emit those symbols.
>
>  — David

Yes it was that. Libraries were well compiled with LDC but some previous objects made with DMD had to be removed.

However I've encountered two weird issues.

- Some invalid imports were not detected by DMD but they blocked LDC.
- The "__init" of a structure was undefined and I had to prevent initialization with "Stuff stuff = void;". I had no problem with this using DMD.

The first point is maybe more a problem with an old-fashioned/obsolete deimos library. The second is quite un-understandable.

"...src/kheops/canvas.d:(.text.std.typecons.Tuple!(double, double).Tuple kheops.canvas.Canvas.textSize(immutable(char)[])[std.typecons.Tuple!(double, double).Tuple kheops.canvas.Canvas.textSize(immutable(char)[])]+0x1c): référence indéfinie vers « deimos.cairo.cairo.cairo_text_extents_t.__init »"

Is it possible that LDC does not emit the "cairo_text_extents_t"'s initializer for a reason or another ?

On 1 Jun 2016, at 19:27, Basile B. via digitalmars-d-ldc wrote:
> The second is quite un-understandable.
>
> "...src/kheops/canvas.d:(.text.std.typecons.Tuple!(double, double).Tuple kheops.canvas.Canvas.textSize(immutable(char)[])[std.typecons.Tuple!(double, double).Tuple kheops.canvas.Canvas.textSize(immutable(char)[])]+0x1c): référence indéfinie vers « deimos.cairo.cairo.cairo_text_extents_t.__init »"
>
> Is it possible that LDC does not emit the "cairo_text_extents_t"'s initializer for a reason or another ?

Are you including the Deimos modules in the compilation command line, one way or another? If not, this might be a reason why the initialiser is not emitted at all.

Deimos used to be intended as a "header-only library" – i.e., no need to ever actually build the modules –, and I am still very much a proponent of that idea, but people (Walter amongst them, IIRC) have recently argued that all modules should always be included in the compilation.

 — David

On Sunday, 5 June 2016 at 23:37:16 UTC, David Nadlinger wrote:
> On 1 Jun 2016, at 19:27, Basile B. via digitalmars-d-ldc wrote:
>> The second is quite un-understandable.
>>
>> "...src/kheops/canvas.d:(.text.std.typecons.Tuple!(double, double).Tuple kheops.canvas.Canvas.textSize(immutable(char)[])[std.typecons.Tuple!(double, double).Tuple kheops.canvas.Canvas.textSize(immutable(char)[])]+0x1c): référence indéfinie vers « deimos.cairo.cairo.cairo_text_extents_t.__init »"
>>
>> Is it possible that LDC does not emit the "cairo_text_extents_t"'s initializer for a reason or another ?
>
> Are you including the Deimos modules in the compilation command line, one way or another? If not, this might be a reason why the initialiser is not emitted at all.
>
> Deimos used to be intended as a "header-only library" – i.e., no need to ever actually build the modules –, and I am still very much a proponent of that idea, but people (Walter amongst them, IIRC) have recently argued that all modules should always be included in the compilation.
>
>  — David

No, the cairo deimos binding is passed as a static library: so the *.a file as a source then only the search path (-I). Then LDC is called via LDMD2 (with exactly the same command line that's passed when I use DMD).

The project also does the same (*.a + I<source root>) with libX11 (which is several order of magnitude bigger then cairo) and no similar error has occured.

On the other hand I've already found several issues in the old cairo binding so I really don't accuse LDC to have a bug, furthemore the real problem I had is now fixed (dmd_personnality). I'll report a bug if it happens with another library.

On 6 Jun 2016, at 1:13, Basile B. via digitalmars-d-ldc wrote:
> No, the cairo deimos binding is passed as a static library: so the *.a file as a source then only the search path (-I). Then LDC is called via LDMD2 (with exactly the same command line that's passed when I use DMD).
>
> The project also does the same (*.a + I<source root>) with libX11 (which is several order of magnitude bigger then cairo) and no similar error has occured.
>
> On the other hand I've already found several issues in the old cairo binding so I really don't accuse LDC to have a bug, furthemore the real problem I had is now fixed (dmd_personnality). I'll report a bug if it happens with another library.

It would still be interesting to have a look what's going on there. The initialiser should definitely be emitted if all modules are linked in.

 — David

On Monday, 6 June 2016 at 00:18:57 UTC, David Nadlinger wrote:
> It would still be interesting to have a look what's going on there. The initialiser should definitely be emitted if all modules are linked in.
>
>  — David

There's definitively something that's not linked correctly (or not linked as DMD tells ld to do). Today I've tried again. This time cairo was ok but I had to add the x11 sources to the "final" static library otherwise an application couldn't be compiled.

An attempt to reproduce the scheme compiles fine:

============================script================================

if [ ! -d "X11" ]; then
	git clone https://github.com/nomad-software/x11.git
fi
cd x11
dub build --build=release --compiler=ldc2
cd ..

# in the IRL case I have 3 other sub static libraries.
# used by the "final" static library.
# in the IRL case for this step I have to add all the X11 d sources...
ldmd2 lib.d x11/libx11.a \
-Ix11/source -lib

# ...otherwise the final app doesn't compile during this last step.
ldmd2 bug.d lib.a x11/libx11.a \
-Ix11/source -L-lX11

============================lib.d==================================
module lib;

import x11.Xlib;

void foo()
{
    // in the IRL case, error begins when using these 3 X11 function
    auto display = XOpenDisplay(null);
    auto screen = DefaultScreen(display);
    auto visual = DefaultVisual(display, screen);
}

============================bug.d==================================
module bug;

import lib;

void main()
{
    foo();
}
===================================================================

I'd like to help with a good bug report but I cant manage to reproduce the issue, sorry.