www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Creating a dynamic library on Linux with DMD

reply Frank Benoit <keinfarbton googlemail.com> writes:
I want to call D from Java.
I think, I need a dynamic library (.so) which implements generated C stubs.

The lib does only need to export those C function. The lib shall contain
 the needed runtime. (and i want to use tango)

Is that possible?
Jun 07 2007
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Yes; it is. Use extern(C) and don't worry too much about the calling convention
stuff (I got it working on Linux and Windows). If you need the JNI, you need to
wrap the header (I used bcd.gen and did some manual editing after that). I'm
working on a transparent Java-D interop layer, but it's on hold for a while;
I'll probably get back to it this fall. I can send you what I have so far if
that'd be helpful. So, basically, no, you don't need a C library, just compile
the D library as a standard shared object.

All the best,
Fraser

Frank Benoit Wrote:


 I want to call D from Java.
 I think, I need a dynamic library (.so) which implements generated C stubs.
 
 The lib does only need to export those C function. The lib shall contain
  the needed runtime. (and i want to use tango)
 
 Is that possible?
Jun 07 2007
prev sibling next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Hm, ppl telling me, that building a .so is possible with GDC and not
well supported with DMD.

What is the difference here?
Jun 10 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Frank Benoit wrote:

 Hm, ppl telling me, that building a .so is possible with GDC and not
 well supported with DMD.
 
 What is the difference here?


IIRC, to build a .so the compiler backend needs to be able to generate 
position-independent code. GDC uses a GCC backend, which have no problem 
with this that I'm aware of (just pass -pic/-PIC on the command line). 
The backend DMD uses on the other hand simply can't do that at the moment.
Jun 10 2007
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
I found that "nm -u libT.so" tells me about lots of unresolved symbols.
They prevent the .so from loading in a non D app. I want to export only
"extern(C)" functions.

$ nm -u libT.so
         U _D10ModuleInfo6__vtblZ
         U _D10TypeInfo_i6__initZ
         U _D10TypeInfo_k6__initZ
         U _D11TypeInfo_Aa6__initZ
         U _D11TypeInfo_Ag6__initZ
         U _D11TypeInfo_Ah6__initZ
         U _D11TypeInfo_Au6__initZ
         U _D11TypeInfo_Aw6__initZ
         U _D13TypeInfo_Enum6__vtblZ
         U _D13TypeInfo_Enum7__ClassZ
         U _D14TypeInfo_Tuple6__vtblZ
         U _D15TypeInfo_Struct6__vtblZ
         U _D16TypeInfo_Pointer6__vtblZ
         U _D16TypeInfo_Typedef6__vtblZ
         U _D16TypeInfo_Typedef7__ClassZ
         U _D17TypeInfo_Delegate6__vtblZ
         U
_D5tango4core9Exception11IOException5_ctorMFAaZC5tango4core9Exception11IOException
         U _D5tango4core9Exception11IOException7__ClassZ
         U
_D5tango4core9Exception24IllegalArgumentException5_ctorMFAaZC5tango4core9Exception24IllegalArgumentException
         U _D5tango4core9Exception24IllegalArgumentException7__ClassZ
         U _D6Object7__ClassZ
         U _D6object6Object5opCmpMFC6ObjectZi
         U _D6object6Object6toHashMFZk
         U _D6object6Object6toUtf8MFZAa
         U _D6object6Object8opEqualsMFC6ObjectZi
         U _D9ClassInfo6__vtblZ
         U _D9invariant12_d_invariantFC6ObjectZv
         U _Dmodule_ref
         w _Jv_RegisterClasses
         U __ULDIV__
         w __cxa_finalize  GLIBC_2.1.3
         w __gmon_start__
         U _adDupT
         U _d_array_bounds
         U _d_arrayappendT
         U _d_arraycatnT
         U _d_arraycopy
         U _d_arraysetlengthiT
         U _d_assert
         U _d_assert_msg
         U _d_delarray
         U _d_dynamic_cast
         U _d_newarrayT
         U _d_newclass
         U _d_throw 4
         U _main
         U _memset16
         U _memset32
         U close  GLIBC_2.0
         U exit  GLIBC_2.0
         U fgetc  GLIBC_2.0
         U fgetwc  GLIBC_2.2
         U fputc  GLIBC_2.0
         U fputwc  GLIBC_2.2
         U getErrno
         U isatty  GLIBC_2.0
         U log10l  GLIBC_2.0
         U memcpy  GLIBC_2.0
         U onUnicodeError
         U read  GLIBC_2.0
         U setErrno
         U stdin  GLIBC_2.0
         U stdout  GLIBC_2.0
         U strerror  GLIBC_2.0
         U strlen  GLIBC_2.0
         U write  GLIBC_2.0
Jun 10 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Frank Benoit wrote:

 I found that "nm -u libT.so" tells me about lots of unresolved symbols.
 They prevent the .so from loading in a non D app. I want to export only
 "extern(C)" functions.


(This assumes GDC)
You could try using visibility attributes. I've never needed them, but 
AFAICT this should work on ELF targets and Darwin[1]:

Pass -fvisibility=hidden on the command line for all your modules 
(including those in the standard library; you'll have to recompile this 
unless you can figure out some way to apply them to the binary library). 
This will hide all symbols from anything outside the shared lib they're 
in, unless overridden for that specific symbol.
The way to do that should be to either use:
---
pragma(GNU_attribute, visibility("default")) {
     // ... declarations of exported functions ...
     // (The braces are optional if only one symbol is declared within)
}
---
or, for each function to be exported:
---
pragma(GNU_set_attribute, FUNCTION_NAME, visibility("default"));
---


References:
Command line: http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html 
(at the bottom, -fvisibility)
Visibility attribute: 
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bvisibility_007d-attribute-1980
GDC syntax for attributes: http://dgcc.sourceforge.net/gdc/manual.html 
(section "Declaration and Type Attributes")


[1]: I have no idea if it'll work on Windows, but .so isn't typically 
used there so that shouldn't matter :).
Jun 10 2007
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
OK, so there is really no chance with DMD :/
Frits, thanks for this, i will try it with GDC.
Jun 10 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Frank Benoit wrote:

 OK, so there is really no chance with DMD :/
 Frits, thanks for this, i will try it with GDC.


Now that I think about it, the D spec specifies:
---
Public means that any code within the executable can access the member.

Export means that any code outside the executable can access the member. 
Export is analogous to exporting definitions from a DLL.
---

So then to correctly implement this the compilers should technically 
already make "hidden" the default visibility, and use "default" only for 
symbols with the "export" attribute in D. That would be pure D, without 
compiler-specific attributes.
I'm not sure if this is currently implemented like that though, and I 
don't feel like checking -- it's late over here.
Jun 10 2007
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
With "I want to export only "extern(C)" functions." i meant "i do only
care about the C functions, the application loading the lib does not
load other than extern(C) functions". Is your suggesting solving the
unresolved symbols or did you get me wrong and your suggestion is hiding
the other functions?
Jun 10 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Frank Benoit wrote:

 With "I want to export only "extern(C)" functions." i meant "i do only
 care about the C functions, the application loading the lib does not
 load other than extern(C) functions". Is your suggesting solving the
 unresolved symbols or did you get me wrong and your suggestion is hiding
 the other functions?


AFAIK, what I wrote /should/ make it "impossible" to link to hidden 
functions from executables or other shared object files, as well as 
disabling dlsym() access to them.
Other functions might still be present in the library (especially those 
called by your exported functions).
The .so would probably still contain some unresolved symbols, especially 
of symbols defined in the standard C library.

If I misunderstood something or was unclear then I'm sorry. Like I 
mentioned in my other post, it's kinda late over here (after 2 AM).
Jun 10 2007
parent Frank Benoit <keinfarbton googlemail.com> writes:
 If I misunderstood something or was unclear then I'm sorry. Like I
 mentioned in my other post, it's kinda late over here (after 2 AM).


yes, same timezone *yawn*
Jun 10 2007