www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - huge stack of __dmd_personality_v0 when static libraries are used.

reply Basile B. <b2.temp gmx.com> writes:
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__T5parseTwTAaZ5pa
seFNaNfKAaZw+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.
Jun 01 2016
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
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
Jun 01 2016
parent reply Basile B. <b2.temp gmx.com> writes:
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 ?
Jun 01 2016
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
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
Jun 05 2016
parent reply Basile B. <b2.temp gmx.com> writes:
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.
Jun 05 2016
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
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
Jun 05 2016
parent Basile B. <b2.temp gmx.com> writes:
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.
Jun 05 2016