www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - libphobos as .so?

reply Tom Demmer <t_demmer web.de> writes:
Hi all,
I am trying to compile and link Phobos under Linux to a shared library. 
So far I found to problems: The minor one is a glitch in the design:
std/gc.d and internal/gc.d go into libphobos.a with a duplicate symbol.
This is OK because ar silently overwrites the first definition with the later
on.
For the shared lib it is sufficient just to drop the gc.o from std/gc.d from
the link line. The fundamental problem is "throw". in internal/deh2.d the
function _d_throw(Object) is declared extern(Windows), which gives the symbol a
" 4" decoration. This means for a shared ELF lib that it is version 4. 
Is there a reason why it has to have Windows calling conventions?
If this could be changed to Pascal and the (probably hardcoded) call to
_d_throw 4 at every "throw", building phobos as a shared lib should work.

Or, is there a way to convince ld that "foo x" is just a simple symbol?

Thanks a lot,

Ciao
Tom
Jun 22 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Tom,

 Hi all,
 
 I am trying to compile and link Phobos under Linux to a shared
 library.
 

 function _d_throw(Object) is declared extern(Windows), which gives the
 symbol a " 4" decoration. This means for a shared ELF lib that it is
 version 4.
 

are you sure you are building with the correct versions and stuff, IIRC D/Linux and D/win32 use very different exception handling. If the common entry point actually is extern(Windows) I would say this is a bug. throw is not performance critical, wrap it in an extern(C) alternatively, why can't dmd/linux use different names for the built-ins than dmd/win32.
Jun 22 2007
parent reply Tom Demmer <t_demmer web.de> writes:
BCS Wrote:

 Reply to Tom,
 

 
 are you sure you are building with the correct versions and stuff, IIRC
D/Linux 
 and D/win32 use very different exception handling. If the common entry point 
 actually is extern(Windows) I would say this is a bug. throw is not
performance 
 critical, wrap it in an extern(C) alternatively, why can't dmd/linux use 
 different names for the built-ins than dmd/win32.
 

Wrapping into extern(C) does not help: The compiler emits a call to "_d_throw 4" whenever he has to construct a throw. But you may have a point that this code should not go into an .so anyway, because the stack may look different. Ciao Tom
Jun 22 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Tom,

 Wrapping into extern(C) does not help: The compiler emits a call to
 "_d_throw 4" whenever he has to construct a throw.
 

Oops, I mis spoke: ".../walter should/ wrap it in an extern(C)..."
 Ciao
 Tom

Jun 25 2007
parent reply Tom Demmer <t_demmer web.de> writes:
BCS Wrote:

 Reply to Tom,
 
 Wrapping into extern(C) does not help: The compiler emits a call to
 "_d_throw 4" whenever he has to construct a throw.
 

Oops, I mis spoke: ".../walter should/ wrap it in an extern(C)..."

How do I make him do that? Ciao Tom
Jun 25 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Tom,

 BCS Wrote:
 
 Reply to Tom,
 
 Wrapping into extern(C) does not help: The compiler emits a call to
 "_d_throw 4" whenever he has to construct a throw.
 


How do I make him do that?

Beer?
Jun 25 2007
parent Nicolai Waniek <no.spam thank.you.com> writes:
BCS wrote:
 Reply to Tom,
 
 BCS Wrote:

 Reply to Tom,

 Wrapping into extern(C) does not help: The compiler emits a call to
 "_d_throw 4" whenever he has to construct a throw.


How do I make him do that?

Beer?

/me places a big (virtual) barrel of beer into this newsgroup. Free beer for everyone, especially for Walter, so that he might consider making it possible to compile phobos to an .so or especially, compile a project to an .so when using phobos ;) -- .71 nicolai dot waniek at sphere71 dot com
Jul 14 2007
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
Tom Demmer wrote:
 Hi all,
 I am trying to compile and link Phobos under Linux to a shared library. 
 So far I found to problems: The minor one is a glitch in the design:
 std/gc.d and internal/gc.d go into libphobos.a with a duplicate symbol.
 This is OK because ar silently overwrites the first definition with the later
on.
 For the shared lib it is sufficient just to drop the gc.o from std/gc.d from
 the link line. The fundamental problem is "throw". in internal/deh2.d the
 function _d_throw(Object) is declared extern(Windows), which gives the symbol
a " 4" decoration. This means for a shared ELF lib that it is version 4. 
 Is there a reason why it has to have Windows calling conventions?
 If this could be changed to Pascal and the (probably hardcoded) call to
_d_throw 4 at every "throw", building phobos as a shared lib should work.
 
 Or, is there a way to convince ld that "foo x" is just a simple symbol?
 
 Thanks a lot,
 
 Ciao
 Tom

Irrelevant of this, DMD .so files are generally broken. If you want reliable support for .so files, use GDC. (Though it's a bit of a trick there too) - Gregor Richards
Jul 14 2007
next sibling parent TomD <t_demmer NOSPAM.web.de> writes:
Gregor Richards Wrote:

[...]
 Irrelevant of this, DMD .so files are generally broken. If you want 
 reliable support for .so files, use GDC.
 
 (Though it's a bit of a trick there too)

What tricks except -fPIC are required? Thanks, Ciao Tom
Jul 15 2007
prev sibling next sibling parent Nicolai Waniek <no.spam thank.you.com> writes:
Gregor Richards wrote:
 Tom Demmer wrote:
 
 Irrelevant of this, DMD .so files are generally broken. If you want
 reliable support for .so files, use GDC.
 
 (Though it's a bit of a trick there too)
 
  - Gregor Richards

I hope Walter addresses this problem, as it is on the linux users' wish list for that long now. /me places even more beer and food. Let's make it a .so BBQ ;) -- .71 nicolai dot waniek at sphere71 dot com
Jul 15 2007
prev sibling parent reply TomD <t_demmer nospam.web.de> writes:
Gregor Richards Wrote:

[...]
 
 Irrelevant of this, DMD .so files are generally broken. If you want 
 reliable support for .so files, use GDC.
 
 (Though it's a bit of a trick there too)
 
   - Gregor Richards

D-functions seem to work (though I did not check GC yet), but classes are a no-no. gdc0.23 chokes on Phobos, but maybe 0.24 gets better. Ciao Tom
Jul 16 2007
parent reply Gregor Richards <Richards codu.org> writes:
TomD wrote:
 Gregor Richards Wrote:
 
 [...]
 Irrelevant of this, DMD .so files are generally broken. If you want 
 reliable support for .so files, use GDC.

 (Though it's a bit of a trick there too)

   - Gregor Richards

D-functions seem to work (though I did not check GC yet), but classes are a no-no. gdc0.23 chokes on Phobos, but maybe 0.24 gets better. Ciao Tom

"Chokes on Phobos"? I've made .so's of Phobos before with GDC. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=43627 - Gregor Richards
Jul 18 2007
parent reply TomD <t_demmer NOSPAM.web.de> writes:
Gregor Richards Wrote:

 TomD wrote:
 Gregor Richards Wrote:
 
 [...]
 Irrelevant of this, DMD .so files are generally broken. If you want 
 reliable support for .so files, use GDC.

 (Though it's a bit of a trick there too)

   - Gregor Richards

D-functions seem to work (though I did not check GC yet), but classes are a no-no. gdc0.23 chokes on Phobos, but maybe 0.24 gets better. Ciao Tom

"Chokes on Phobos"? I've made .so's of Phobos before with GDC. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=43627 - Gregor Richards

tom Inges:~/d/phobos$ gdc -v -c object.d Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.1/configure --prefix=/home/dvdf/Devel/Gcc-D/r22rc2/Rgcc --disable-shared --enable-languages=c,d --disable-shared Thread model: posix gcc version 4.1.1 20060524 ( (gdc 0.22, using dmd 1.004)) /usr/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1d object.d -quiet -dumpbase object.d -mtune=pentiumpro -auxbase object -version -iprefix /usr/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/ -o /tmp/cc6Q1Ejh.s GNU D version 4.1.1 20060524 ( (gdc 0.22, using dmd 1.004)) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20060304 (Red Hat 4.1.0-3). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64497 cc1d: ../../gcc-4.1.1/gcc/d/dmd/toobj.c:417: virtual void ClassDeclaration::toObjFile(): Assertion `classinfo->structsize == (0x3C+8)' failed. object.d:0: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. tom Inges:~/d/phobos$ With the phobos sources that come with DMD1.018. But thanks for the link. Ciao Tom
Jul 18 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
TomD wrote:
 Gregor Richards Wrote:
 
 TomD wrote:
 OK I figured out what you meant with "generally broken". Simple
 D-functions seem to work (though I did not check GC yet), but classes
 are a no-no. 
 gdc0.23 chokes on Phobos, but maybe 0.24 gets better.

 Ciao
 Tom

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=43627

tom Inges:~/d/phobos$ gdc -v -c object.d

 cc1d: ../../gcc-4.1.1/gcc/d/dmd/toobj.c:417: virtual void
ClassDeclaration::toObjFile(): Assertion `classinfo->structsize == (0x3C+8)'
failed.
 object.d:0: internal compiler error: Aborted
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See <URL:http://gcc.gnu.org/bugs.html> for instructions.
 tom Inges:~/d/phobos$ 
 
 With the phobos sources that come with DMD1.018.  But thanks for the link.

You shouldn't combine DMD's phobos with GDC. The runtime library is a bit compiler-specific. You should try it with the gphobos sources that are part of the GDC source tree, which should work just fine with GDC. (IIRC it also has some patches to make it more portable since Walter mostly seems to write phobos to work on 32-bit x86 Windows & Linux) Complete gphobos sources don't seem to be included in the GDC binary distribution by the way, that just seems to contain a "header" module for object.d, for instance. (the phobos/internal/* directory is missing, including internal/object.d which contains the actual implementation)
Jul 19 2007
parent TomD <t_demmer NOSPAM.web.de> writes:
Frits van Bommel Wrote:

[...] 
 You shouldn't combine DMD's phobos with GDC. The runtime library is a 
 bit compiler-specific.
 You should try it with the gphobos sources that are part of the GDC 
 source tree, which should work just fine with GDC. (IIRC it also has 
 some patches to make it more portable since Walter mostly seems to write 
 phobos to work on 32-bit x86 Windows & Linux)
 Complete gphobos sources don't seem to be included in the GDC binary 
 distribution by the way, that just seems to contain a "header" module 
 for object.d, for instance. (the phobos/internal/* directory is missing, 
 including internal/object.d which contains the actual implementation)

Ahh, OK that makes sense. I'll try to grab gphobos. A hint in the /usr/share/doc/gdc/README file had helped (not that I believe too many people would actually check it). Or just having the source included, just like dmd does. Thanks, Ciao Tom
Jul 19 2007