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
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
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 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 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 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 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

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


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


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?

Windows. Given the simplicity of the needed C function we can simply generate it inside the compiler.
Apr 10 2013
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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 next 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 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 next sibling parent 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
prev sibling next sibling parent 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
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
next sibling 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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

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 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
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 next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c32dfeb45c4104dd603629
Content-Type: text/plain; charset=UTF-8

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) --001a11c32dfeb45c4104dd603629 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 23 May 2013 16:28, Jacob Carlborg <span dir=3D"ltr">&lt= ;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span=
 wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo=

lid;padding-left:1ex"> <div class=3D"im">On 2013-05-23 03:01, Ellery Newcomer wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 1. D executable, C dll =3D&gt; always worked<br> 2. D executable, D dll, statically loaded =3D&gt; now in 2.063 HEAD<br> 3. D executable, D dll, dynamically loaded (hot swapping) =3D not yet<br> 4. C executable, D dll =3D&gt; not yet<br> </blockquote> <br> now? :)<br> </blockquote> <br></div> 2 works. 4 could possibly work if it&#39;s statically loaded. Although I&#3= 9;m not sure if the runtime will be properly initialized from C.<span class= =3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br></div><div class=3D"gmail_extra" style=
Is there an ETA for any any of these? case 3 is of critical importance... =

</div> --001a11c32dfeb45c4104dd603629--
May 23 2013
prev sibling next sibling parent "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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c1f5f0ac717804dd61780a
Content-Type: text/plain; charset=UTF-8

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. --001a11c1f5f0ac717804dd61780a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 23 May 2013 21:45, Jacob Carlborg <span dir=3D"ltr">&lt= ;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span=
 wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo=

lid;padding-left:1ex"> <div class=3D"im">On 2013-05-23 12:33, Manu wrote:<br> <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> Is there an ETA for any any of these? case 3 is of critical<br></div> importance... and also 5. C executable, D dll, dynamically loaded (hot<br> swapping)<br> </blockquote> <br> I don&#39;t know. 5 would probably automatically work if 3 worked, or with = minor modifications. As for the ETA, I don&#39;t know. See if you can put s= ome pressure Walter or Martin Nowak. I&#39;m talking about Linux and possib= ly FreeBSD here. Don&#39;t know the status on Windows.</blockquote> <div><br></div><div style>I think there&#39;s already some pressure on the = 2 of them.</div><div style>It&#39;s been a major roadblock for a long time = for us.</div></div></div></div> --001a11c1f5f0ac717804dd61780a--
May 23 2013
prev sibling parent Manu <turkeyman gmail.com> writes:
--089e01227f04e13be704dd61f849
Content-Type: text/plain; charset=UTF-8

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. --089e01227f04e13be704dd61f849 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 23 May 2013 21:57, Jakob Ovrum <span dir=3D"ltr">&lt;<a= href=3D"mailto:jakobovrum gmail.com" target=3D"_blank">jakobovrum gmail.co= m</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q= uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Thursday, 23 May 2013 at 11:45:41 UTC, Jacob Carlborg = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Don&#39;t know the status on Windows.<br> </blockquote> <br></div> Hasn&#39;t pretty much all of this always worked on Windows?<br> <br> I&#39;ve been using DLLs written in D on Windows for years, including in si= tuations where they are loaded by a C application.<br> <br> It had its issues when it came to sharing TypeInfo and GC instances and wha= tnot, but it works.<br> </blockquote></div><br></div><div class=3D"gmail_extra" style>They&#39;re n= ot unimportant details.</div></div> --089e01227f04e13be704dd61f849--
May 23 2013