www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - status of shared libs

reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
is there a roadmap for druntime/phobos support of shared libraries?

just built dmd from master, and I still can't coax out a 64 bit .so
Apr 05 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/5/2013 7:18 PM, Ellery Newcomer wrote:

 is there a roadmap for druntime/phobos support of shared libraries?

 just built dmd from master, and I still can't coax out a 64 bit .so


awaiting:

https://github.com/D-Programming-Language/phobos/pull/1240
Apr 05 2013
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/05/2013 07:22 PM, Walter Bright wrote:

 On 4/5/2013 7:18 PM, Ellery Newcomer wrote:

 is there a roadmap for druntime/phobos support of shared libraries?

 just built dmd from master, and I still can't coax out a 64 bit .so


 awaiting:

 https://github.com/D-Programming-Language/phobos/pull/1240


goody
Apr 05 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-04-06 04:22, Walter Bright wrote:


 awaiting:

 https://github.com/D-Programming-Language/phobos/pull/1240


Everything in druntime is done?

-- 
/Jacob Carlborg
Apr 06 2013
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/05/2013 07:22 PM, Walter Bright wrote:

 On 4/5/2013 7:18 PM, Ellery Newcomer wrote:

 is there a roadmap for druntime/phobos support of shared libraries?

 just built dmd from master, and I still can't coax out a 64 bit .so


 awaiting:

 https://github.com/D-Programming-Language/phobos/pull/1240


trying out the spiffy new shared lib support, I get this:

dmd  -unittest -fPIC -defaultlib=phobos2so -shared test1.d -oflibtest1.so
gcc  test1.c `pwd`/libtest1.so -L/usr/lib64/dmd/ -L/usr/lib/dmd/ -o test1.x
/lib64/libphobos2so.so: undefined reference to `_Dmain'
collect2: error: ld returned 1 exit status


_Dmain? wat?
Apr 06 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2013 7:15 PM, Ellery Newcomer wrote:

 dmd  -unittest -fPIC -defaultlib=phobos2so -shared test1.d -oflibtest1.so
 gcc  test1.c `pwd`/libtest1.so -L/usr/lib64/dmd/ -L/usr/lib/dmd/ -o test1.x
 /lib64/libphobos2so.so: undefined reference to `_Dmain'
 collect2: error: ld returned 1 exit status


 _Dmain? wat?


_Dmain is the mangled name for main() in your program.
Apr 06 2013
parent reply "Ellery Newcomer" <ellery-newcomer utulsa.edu> writes:
On Sunday, 7 April 2013 at 06:03:38 UTC, Walter Bright wrote:

 On 4/6/2013 7:15 PM, Ellery Newcomer wrote:

 dmd  -unittest -fPIC -defaultlib=phobos2so -shared test1.d 
 -oflibtest1.so
 gcc  test1.c `pwd`/libtest1.so -L/usr/lib64/dmd/ 
 -L/usr/lib/dmd/ -o test1.x
 /lib64/libphobos2so.so: undefined reference to `_Dmain'
 collect2: error: ld returned 1 exit status


 _Dmain? wat?


 _Dmain is the mangled name for main() in your program.


Yes, I know, but does it make sense to provide it when I call my 
shared lib from C?
Apr 07 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2013 6:14 PM, Ellery Newcomer wrote:

 On Sunday, 7 April 2013 at 06:03:38 UTC, Walter Bright wrote:

 On 4/6/2013 7:15 PM, Ellery Newcomer wrote:

 dmd  -unittest -fPIC -defaultlib=phobos2so -shared test1.d -oflibtest1.so
 gcc  test1.c `pwd`/libtest1.so -L/usr/lib64/dmd/ -L/usr/lib/dmd/ -o test1.x
 /lib64/libphobos2so.so: undefined reference to `_Dmain'
 collect2: error: ld returned 1 exit status


 _Dmain? wat?


 _Dmain is the mangled name for main() in your program.


 Yes, I know, but does it make sense to provide it when I call my shared lib
from C?


Currently, I think you'll need a D main().
Apr 07 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-08 06:16, Walter Bright wrote:


 Currently, I think you'll need a D main().


I don't think that's a good solution. Currently a quick workaround is to 
declare D main as a weak symbol.

What I think could be a better choice, in the long run, is to put the C 
and D main functions in a separate file, compiled as its own object 
file. This object file will only be linked when DMD is linking an 
executable.

The "rt_info" and D "main" functions should also be refactored so D main 
calls "rt_info" to avoid duplicating code.

-- 
/Jacob Carlborg
Apr 07 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2013 11:34 PM, Jacob Carlborg wrote:

 On 2013-04-08 06:16, Walter Bright wrote:


 Currently, I think you'll need a D main().


 I don't think that's a good solution. Currently a quick workaround is to
declare
 D main as a weak symbol.


That may get rid of the error message, but the issue is getting the dll 
initialized properly.
Apr 08 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-04-09 01:14, Walter Bright wrote:


 That may get rid of the error message, but the issue is getting the dll
 initialized properly.


There's "rt_init", C initializers and Windows DLL main. That's why a 
described a better solution below.

-- 
/Jacob Carlborg
Apr 08 2013
prev sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 8 April 2013 at 04:16:20 UTC, Walter Bright wrote:

 On 4/7/2013 6:14 PM, Ellery Newcomer wrote:

 On Sunday, 7 April 2013 at 06:03:38 UTC, Walter Bright wrote:

 On 4/6/2013 7:15 PM, Ellery Newcomer wrote:

 dmd  -unittest -fPIC -defaultlib=phobos2so -shared test1.d 
 -oflibtest1.so
 gcc  test1.c `pwd`/libtest1.so -L/usr/lib64/dmd/ 
 -L/usr/lib/dmd/ -o test1.x
 /lib64/libphobos2so.so: undefined reference to `_Dmain'
 collect2: error: ld returned 1 exit status


 _Dmain? wat?


 _Dmain is the mangled name for main() in your program.


 Yes, I know, but does it make sense to provide it when I call 
 my shared lib from C?


 Currently, I think you'll need a D main().


I think there is no need for D main and it can be fixed simply by 
defining _Dmain() in druntime. If user defines _Dmain() somewhere 
in his code, it would be caught by linker, if not the behavior 
would depend on druntime version. Advantage is that there would 
be no building errors (may be except when _deh_beg and _deh_end 
are required), the question is what to do in default version - 
silently ignore or throw error.
Apr 08 2013
prev sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 8 April 2013 at 01:14:19 UTC, Ellery Newcomer wrote:

 On Sunday, 7 April 2013 at 06:03:38 UTC, Walter Bright wrote:

 On 4/6/2013 7:15 PM, Ellery Newcomer wrote:

 dmd  -unittest -fPIC -defaultlib=phobos2so -shared test1.d 
 -oflibtest1.so
 gcc  test1.c `pwd`/libtest1.so -L/usr/lib64/dmd/ 
 -L/usr/lib/dmd/ -o test1.x
 /lib64/libphobos2so.so: undefined reference to `_Dmain'
 collect2: error: ld returned 1 exit status


 _Dmain? wat?


 _Dmain is the mangled name for main() in your program.


 Yes, I know, but does it make sense to provide it when I call 
 my shared lib from C?


DMD inserts some additional info in object file if main() is 
present and sometimes it is required. One of the solutions is to 
use dummy D module (with main function defined) which forwards 
startup arguments to C main function.
Apr 07 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-08 06:35, Maxim Fomin wrote:


 DMD inserts some additional info in object file if main() is present and
 sometimes it is required. One of the solutions is to use dummy D module
 (with main function defined) which forwards startup arguments to C main
 function.


druntime already defines a C main function as well, which forwards to 
the D main function.

-- 
/Jacob Carlborg
Apr 07 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 8 April 2013 at 06:29:33 UTC, Jacob Carlborg wrote:

 On 2013-04-08 06:35, Maxim Fomin wrote:


 DMD inserts some additional info in object file if main() is 
 present and
 sometimes it is required. One of the solutions is to use dummy 
 D module
 (with main function defined) which forwards startup arguments 
 to C main
 function.


 druntime already defines a C main function as well, which 
 forwards to the D main function.


C main function need to be renamed or D main function should be 
supplied (then a program would start from C code, not D, but this 
is not a problem)

By the way, druntime links to _Dmain, but does not necessarily 
forwards to it.
Apr 08 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-08 11:51, Maxim Fomin wrote:


 C main function need to be renamed or D main function should be supplied
 (then a program would start from C code, not D, but this is not a problem)

 By the way, druntime links to _Dmain, but does not necessarily forwards
 to it.


The C main function defined in druntime forward to the D main function. 
The C main function calls "_d_run_main" and passes in a pointer to the D 
main function. "_d_run_main" then calls the d main function. Indirectly 
the C main forwards to D main.

-- 
/Jacob Carlborg
Apr 08 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-04-08 13:21, Jacob Carlborg wrote:


 The C main function defined in druntime forward to the D main function.
 The C main function calls "_d_run_main" and passes in a pointer to the D
 main function. "_d_run_main" then calls the d main function. Indirectly
 the C main forwards to D main.


Forgot the link:

https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L348

-- 
/Jacob Carlborg
Apr 08 2013
prev sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 8 April 2013 at 11:21:07 UTC, Jacob Carlborg wrote:

 On 2013-04-08 11:51, Maxim Fomin wrote:


 C main function need to be renamed or D main function should 
 be supplied
 (then a program would start from C code, not D, but this is 
 not a problem)

 By the way, druntime links to _Dmain, but does not necessarily 
 forwards
 to it.


 The C main function defined in druntime forward to the D main 
 function. The C main function calls "_d_run_main" and passes in 
 a pointer to the D main function. "_d_run_main" then calls the 
 d main function. Indirectly the C main forwards to D main.


This is exactly why main() does not necessarily forwards to 
_Dmain().

import std.stdio;

alias extern(C) int function(char[][] args) MainFunc;

extern (C) int _d_run_main(int argc, char **argv, MainFunc 
mainFunc);

extern(C) int main(int argc, char** argv)
{
     return _d_run_main(argc, argv, &bar);
}

void main()
{
     writeln("D main");
}

extern(C) int bar(char[][] args)
{
     writeln("bar");
     return 0;
}

Guess what would happen.
Apr 08 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-04-08 14:27, Maxim Fomin wrote:


 This is exactly why main() does not necessarily forwards to _Dmain().

 import std.stdio;

 alias extern(C) int function(char[][] args) MainFunc;

 extern (C) int _d_run_main(int argc, char **argv, MainFunc mainFunc);

 extern(C) int main(int argc, char** argv)
 {
      return _d_run_main(argc, argv, &bar);
 }

 void main()
 {
      writeln("D main");
 }

 extern(C) int bar(char[][] args)
 {
      writeln("bar");
      return 0;
 }

 Guess what would happen.


Sure, if you redefine the C main function.

-- 
/Jacob Carlborg
Apr 08 2013
prev sibling parent "Ellery Newcomer" <ellery-newcomer utulsa.edu> writes:
On Monday, 8 April 2013 at 04:35:59 UTC, Maxim Fomin wrote:

 DMD inserts some additional info in object file if main() is 
 present and sometimes it is required. One of the solutions is 
 to use dummy D module (with main function defined) which 
 forwards startup arguments to C main function.


My target is python extension modules. I can't touch c main. I 
can provide a dummy _Dmain and then manually start up and shut 
down the d runtime; that's the way PyD's been doing it for the 
last seven years, but I think it breaks when you have more than 
one shared lib.
Apr 08 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-07 04:15, Ellery Newcomer wrote:


 trying out the spiffy new shared lib support, I get this:

 dmd  -unittest -fPIC -defaultlib=phobos2so -shared test1.d -oflibtest1.so
 gcc  test1.c `pwd`/libtest1.so -L/usr/lib64/dmd/ -L/usr/lib/dmd/ -o test1.x
 /lib64/libphobos2so.so: undefined reference to `_Dmain'
 collect2: error: ld returned 1 exit status


 _Dmain? wat?


It's declared in druntime and therefore expected to be included:

https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L348

I think it needs weak linkage or similar. I don't know if it's possible 
to do in D, but in C it can be done like this:

https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dylib_fixes.c

Don't know if that is compiled and linked. There probably needs to be a 
way to exclude the C main function as well.

-- 
/Jacob Carlborg
Apr 07 2013
parent reply Martin Nowak <code dawg.eu> writes:
On 04/07/2013 10:21 AM, Jacob Carlborg wrote:

 On 2013-04-07 04:15, Ellery Newcomer wrote:
 I think it needs weak linkage or similar. I don't know if it's possible
 to do in D, but in C it can be done like this:

 https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dylib_fixes.c


Yes, druntime should only weakly link against _Dmain.
Apr 07 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 07.04.2013 17:19, Martin Nowak wrote:

 On 04/07/2013 10:21 AM, Jacob Carlborg wrote:

 On 2013-04-07 04:15, Ellery Newcomer wrote:
 I think it needs weak linkage or similar. I don't know if it's possible
 to do in D, but in C it can be done like this:

 https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dylib_fixes.c


 Yes, druntime should only weakly link against _Dmain.


I think the correct way is to remove the C main function from dmain2.d 
and put it in an extra library to be linked with the executable. At 
least on Windows, you won't be able to link back from the DLL to the 
main executable.
Apr 08 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-08 20:00, Rainer Schuetze wrote:


 I think the correct way is to remove the C main function from dmain2.d
 and put it in an extra library to be linked with the executable. At
 least on Windows, you won't be able to link back from the DLL to the
 main executable.


The D main function as well?

-- 
/Jacob Carlborg
Apr 08 2013
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 08.04.2013 20:54, Jacob Carlborg wrote:

 On 2013-04-08 20:00, Rainer Schuetze wrote:


 I think the correct way is to remove the C main function from dmain2.d
 and put it in an extra library to be linked with the executable. At
 least on Windows, you won't be able to link back from the DLL to the
 main executable.


 The D main function as well?


Inside a DLL you don't run the D main function, and the executable must 
have it (or WinMain), so it doesn't make sense to define one in the 
shared druntime DLL.

Depending on whether _Dmain, WinMain or DLLMain is found in the D source 
code, the corresponding startup code is linked, and only the startup 
code for _Dmain drags in the the C main function.
Apr 08 2013
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On 04/08/2013 08:00 PM, Rainer Schuetze wrote:

 On 07.04.2013 17:19, Martin Nowak wrote:

 On 04/07/2013 10:21 AM, Jacob Carlborg wrote:

 On 2013-04-07 04:15, Ellery Newcomer wrote:
 I think it needs weak linkage or similar. I don't know if it's possible
 to do in D, but in C it can be done like this:

 https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dylib_fixes.c


 Yes, druntime should only weakly link against _Dmain.


 I think the correct way is to remove the C main function from dmain2.d
 and put it in an extra library to be linked with the executable. At
 least on Windows, you won't be able to link back from the DLL to the
 main executable.


I think the best way is to sythesize a main function in the executable.
Something like this.

extern(C) int main(int argc, char** argv)
{
   rt_init(argc, argv);
   runMain(&_Dmain);
   return rt_term();
}
Apr 09 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-09 17:51, Martin Nowak wrote:


 I think the best way is to sythesize a main function in the executable.
 Something like this.

 extern(C) int main(int argc, char** argv)
 {
    rt_init(argc, argv);
    runMain(&_Dmain);
    return rt_term();
 }


By "sythesize", you mean not defined in druntime?

-- 
/Jacob Carlborg
Apr 09 2013
parent Martin Nowak <code dawg.eu> writes:
On 04/09/2013 06:49 PM, Jacob Carlborg wrote:

 On 2013-04-09 17:51, Martin Nowak wrote:


 I think the best way is to sythesize a main function in the executable.
 Something like this.

 extern(C) int main(int argc, char** argv)
 {
    rt_init(argc, argv);
    runMain(&_Dmain);
    return rt_term();
 }


 By "sythesize", you mean not defined in druntime?


Yes as Rainer pointed out the current mechanism doesn't work well on 
Windows. Given the simplicity of the needed C function we can simply 
generate it inside the compiler.
Apr 10 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 04/06/2013 04:22 AM, Walter Bright wrote:

 On 4/5/2013 7:18 PM, Ellery Newcomer wrote:

 is there a roadmap for druntime/phobos support of shared libraries?

 just built dmd from master, and I still can't coax out a 64 bit .so


 
 awaiting:
 
 https://github.com/D-Programming-Language/phobos/pull/1240


I see it's been added :-)

Are there any extra flags that need to be added to dmd.conf for this to work
successfully?  On my system I find that the shared library is not found when
running programs built against it:

   error while loading shared libraries: libphobos2so.so: cannot load shared
object file: no such file or directory

I can get round this by exporting /opt/dmd/lib to LD_LIBRARY_PATH but if I
recall right, this is a frowned-upon way of identifying where shared libraries
are to be found ...
Apr 07 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 07 Apr 2013 18:36:04 +0200
schrieb Joseph Rushton Wakeling <joseph.wakeling webdrake.net>:


 On 04/06/2013 04:22 AM, Walter Bright wrote:

 On 4/5/2013 7:18 PM, Ellery Newcomer wrote:

 is there a roadmap for druntime/phobos support of shared libraries?

 just built dmd from master, and I still can't coax out a 64 bit .so


 
 awaiting:
 
 https://github.com/D-Programming-Language/phobos/pull/1240


 
 I see it's been added :-)
 
 Are there any extra flags that need to be added to dmd.conf for this
 to work successfully?  On my system I find that the shared library is
 not found when running programs built against it:
 
    error while loading shared libraries: libphobos2so.so: cannot load
 shared object file: no such file or directory
 
 I can get round this by exporting /opt/dmd/lib to LD_LIBRARY_PATH but
 if I recall right, this is a frowned-upon way of identifying where
 shared libraries are to be found ...
 


In theory: Add the .so directory to /etc/ld.so.conf, run ldconfig
http://linux.die.net/man/8/ldconfig

But: This usually requires proper version information in the .so library
and a properly set soname. I doubt anyone has looked into that yet.
Apr 07 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 04/07/2013 07:38 PM, Johannes Pfau wrote:

 In theory: Add the .so directory to /etc/ld.so.conf, run ldconfig
 http://linux.die.net/man/8/ldconfig


Oh, of course.  I did once know this years ago, but I'd forgotten as it's so
long since I last installed a shared library into anything other than
/usr/local/lib.


 But: This usually requires proper version information in the .so library
 and a properly set soname. I doubt anyone has looked into that yet.


Well, I have had no problems with dmd, but when I tried also adding /opt/gdc/lib
I got the following error message upon running ldconfig:

    /sbin/ldconfig.real: /opt/gdc/lib/libstdc++.so.6.0.18-gdb.py is not an ELF
file - it has the wrong magic bytes at the start.
Apr 07 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 07 Apr 2013 19:56:15 +0200
schrieb Joseph Rushton Wakeling <joseph.wakeling webdrake.net>:


 On 04/07/2013 07:38 PM, Johannes Pfau wrote:

 In theory: Add the .so directory to /etc/ld.so.conf, run ldconfig
 http://linux.die.net/man/8/ldconfig


 
 Oh, of course.  I did once know this years ago, but I'd forgotten as
 it's so long since I last installed a shared library into anything
 other than /usr/local/lib.
 

 But: This usually requires proper version information in the .so
 library and a properly set soname. I doubt anyone has looked into
 that yet.


 
 Well, I have had no problems with dmd, but when I tried also
 adding /opt/gdc/lib I got the following error message upon running
 ldconfig:
 
     /sbin/ldconfig.real: /opt/gdc/lib/libstdc++.so.6.0.18-gdb.py is
 not an ELF file - it has the wrong magic bytes at the start.


Then ldconfig is less picky than I thought ;-) The other problem is
actually a problem in gcc, not gdc specific:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816

Most linux distributions move that file manually to a different location
when creating the gcc package.
Apr 08 2013
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 04/08/2013 10:25 AM, Johannes Pfau wrote:

 Then ldconfig is less picky than I thought ;-) The other problem is
 actually a problem in gcc, not gdc specific:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816
 
 Most linux distributions move that file manually to a different location
 when creating the gcc package.


Aaahh, OK.  If I understand right it's a harmless warning, so I might as well
just leave everything where it is ...
Apr 09 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/5/2013 7:18 PM, Ellery Newcomer wrote:

 is there a roadmap for druntime/phobos support of shared libraries?

 just built dmd from master, and I still can't coax out a 64 bit .so


There are the following scenarios:

1. D executable, C dll => always worked
2. D executable, D dll, statically loaded => now in 2.063 HEAD
3. D executable, D dll, dynamically loaded (hot swapping) = not yet
4. C executable, D dll => not yet
Apr 08 2013
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/08/2013 04:18 PM, Walter Bright wrote:

 On 4/5/2013 7:18 PM, Ellery Newcomer wrote:

 is there a roadmap for druntime/phobos support of shared libraries?

 just built dmd from master, and I still can't coax out a 64 bit .so


 There are the following scenarios:

 1. D executable, C dll => always worked
 2. D executable, D dll, statically loaded => now in 2.063 HEAD
 3. D executable, D dll, dynamically loaded (hot swapping) = not yet
 4. C executable, D dll => not yet


now? :)
May 22 2013
next sibling parent 1100110 <0b1100110 gmail.com> writes:
On 05/22/2013 08:01 PM, Ellery Newcomer wrote:

 On 04/08/2013 04:18 PM, Walter Bright wrote:

 On 4/5/2013 7:18 PM, Ellery Newcomer wrote:

 is there a roadmap for druntime/phobos support of shared libraries?

 just built dmd from master, and I still can't coax out a 64 bit .so


 There are the following scenarios:

 1. D executable, C dll =3D> always worked
 2. D executable, D dll, statically loaded =3D> now in 2.063 HEAD
 3. D executable, D dll, dynamically loaded (hot swapping) =3D not yet
 4. C executable, D dll =3D> not yet


=20
 now? :)



Good question, since phobos is now shared...
May 22 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-23 03:01, Ellery Newcomer wrote:


 1. D executable, C dll => always worked
 2. D executable, D dll, statically loaded => now in 2.063 HEAD
 3. D executable, D dll, dynamically loaded (hot swapping) = not yet
 4. C executable, D dll => not yet


 now? :)


2 works. 4 could possibly work if it's statically loaded. Although I'm 
not sure if the runtime will be properly initialized from C.

-- 
/Jacob Carlborg
May 22 2013
parent reply Manu <turkeyman gmail.com> writes:
On 23 May 2013 16:28, Jacob Carlborg <doob me.com> wrote:


 On 2013-05-23 03:01, Ellery Newcomer wrote:

  1. D executable, C dll => always worked

 2. D executable, D dll, statically loaded => now in 2.063 HEAD
 3. D executable, D dll, dynamically loaded (hot swapping) = not yet
 4. C executable, D dll => not yet


 now? :)


 2 works. 4 could possibly work if it's statically loaded. Although I'm not
 sure if the runtime will be properly initialized from C.

 --
 /Jacob Carlborg


Is there an ETA for any any of these? case 3 is of critical importance...
and also 5. C executable, D dll, dynamically loaded (hot swapping)
May 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-23 12:33, Manu wrote:


 Is there an ETA for any any of these? case 3 is of critical
 importance... and also 5. C executable, D dll, dynamically loaded (hot
 swapping)


I don't know. 5 would probably automatically work if 3 worked, or with 
minor modifications. As for the ETA, I don't know. See if you can put 
some pressure Walter or Martin Nowak. I'm talking about Linux and 
possibly FreeBSD here. Don't know the status on Windows.

-- 
/Jacob Carlborg
May 23 2013
next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Thursday, 23 May 2013 at 11:45:41 UTC, Jacob Carlborg wrote:

 Don't know the status on Windows.


Hasn't pretty much all of this always worked on Windows?

I've been using DLLs written in D on Windows for years, including 
in situations where they are loaded by a C application.

It had its issues when it came to sharing TypeInfo and GC 
instances and whatnot, but it works.
May 23 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-23 13:57, Jakob Ovrum wrote:


 Hasn't pretty much all of this always worked on Windows?


I haven't tried it, I don't know.

-- 
/Jacob Carlborg
May 23 2013
prev sibling parent Manu <turkeyman gmail.com> writes:
On 23 May 2013 21:57, Jakob Ovrum <jakobovrum gmail.com> wrote:


 On Thursday, 23 May 2013 at 11:45:41 UTC, Jacob Carlborg wrote:


 Don't know the status on Windows.


 Hasn't pretty much all of this always worked on Windows?

 I've been using DLLs written in D on Windows for years, including in
 situations where they are loaded by a C application.

 It had its issues when it came to sharing TypeInfo and GC instances and
 whatnot, but it works.


They're not unimportant details.
May 23 2013
prev sibling parent Manu <turkeyman gmail.com> writes:
On 23 May 2013 21:45, Jacob Carlborg <doob me.com> wrote:


 On 2013-05-23 12:33, Manu wrote:

  Is there an ETA for any any of these? case 3 is of critical

 importance... and also 5. C executable, D dll, dynamically loaded (hot
 swapping)


 I don't know. 5 would probably automatically work if 3 worked, or with
 minor modifications. As for the ETA, I don't know. See if you can put some
 pressure Walter or Martin Nowak. I'm talking about Linux and possibly
 FreeBSD here. Don't know the status on Windows.



I think there's already some pressure on the 2 of them.
It's been a major roadblock for a long time for us.
May 23 2013