On Tuesday, 18 June 2013 at 20:23:42 UTC, 1100110 wrote:
On 06/18/2013 10:14 AM, Bottled Gin wrote:
Actually, I seriously doubt everything is working as
expected. For
example, what happens when an application loads (via dlopen or
similar) a D dynamic library:
* Are exception handlers
Actually, I seriously doubt everything is working as expected.
For example, what happens when an application loads (via dlopen
or similar) a D dynamic library:
* Are exception handlers registered
* Are module infos properly registered
* What happens if I call Object.factory, will that find a
On 06/18/2013 10:14 AM, Bottled Gin wrote:
Actually, I seriously doubt everything is working as expected. For
example, what happens when an application loads (via dlopen or
similar) a D dynamic library:
* Are exception handlers registered
* Are module infos properly registered
* What happens
Am Mon, 01 Oct 2012 19:18:46 +0200
schrieb Jacob Carlborg d...@me.com:
On 2012-10-01 17:06, Johannes Pfau wrote:
the problem is that we don't want the C main function in a shared
libgdruntime.so, because you might want to use libgdruntime.so in a
C/C++ app which has it's own main
On 2012-10-01 01:42, Rob T wrote:
It seems that an attempt to make the runtime shared is well under way.
Did anything get into the main dmd branch or has the effort been stalled
or ...?
Seems pretty stalled.
I will look at this too. Thanks for the pointers.
No problem.
--
/Jacob Carlborg
Am Sat, 29 Sep 2012 15:19:30 +0200
schrieb Jacob Carlborg d...@me.com:
On 2012-09-28 20:25, Maxim Fomin wrote:
I tried to check how TLS, EX, etc. (mostly exposed to dll issue) are
working and here is some kind of test:
https://github.com/mxfm/sharedtest. Unfortunately scope(exit) isn't
On 2012-10-01 12:42, Johannes Pfau wrote:
There are some reasons for dynamic libraries linked at compile time,
one is that we have to start somewhere and they are required for
plugins / dynamically loaded libraries as well ;-)
So I started a small test suite for GDC (could be adapted to other
On 1 October 2012 13:34, Jacob Carlborg d...@me.com wrote:
On 2012-10-01 12:42, Johannes Pfau wrote:
There are some reasons for dynamic libraries linked at compile time,
one is that we have to start somewhere and they are required for
plugins / dynamically loaded libraries as well ;-)
So I
On 2012-10-01 14:40, Iain Buclaw wrote:
On Linux, there has already been an runtime implementation written
that scans /proc/self/maps and adds all data sections to the GC that
way. Whether or not DMD wishes to go down that route is their own
decision. I am looking into a solution that doesn't
On 2012-10-01 12:42, Johannes Pfau wrote:
There are some reasons for dynamic libraries linked at compile time,
one is that we have to start somewhere and they are required for
plugins / dynamically loaded libraries as well ;-)
So I started a small test suite for GDC (could be adapted to other
On 2012-10-01 14:40, Iain Buclaw wrote:
On Linux, there has already been an runtime implementation written
that scans /proc/self/maps and adds all data sections to the GC that
way. Whether or not DMD wishes to go down that route is their own
decision. I am looking into a solution that doesn't
Am Mon, 01 Oct 2012 14:34:21 +0200
schrieb Jacob Carlborg d...@me.com:
On 2012-10-01 12:42, Johannes Pfau wrote:
There are some reasons for dynamic libraries linked at compile time,
one is that we have to start somewhere and they are required for
plugins / dynamically loaded libraries as
Am Mon, 01 Oct 2012 15:11:49 +0200
schrieb Jacob Carlborg d...@me.com:
On 2012-10-01 12:42, Johannes Pfau wrote:
There are some reasons for dynamic libraries linked at compile time,
one is that we have to start somewhere and they are required for
plugins / dynamically loaded libraries as
On 1 October 2012 16:06, Johannes Pfau nos...@example.com wrote:
Am Mon, 01 Oct 2012 15:11:49 +0200
schrieb Jacob Carlborg d...@me.com:
On 2012-10-01 12:42, Johannes Pfau wrote:
There are some reasons for dynamic libraries linked at compile time,
one is that we have to start somewhere and
On 2012-10-01 17:03, Johannes Pfau wrote:
I tested two different configurations:
druntime and phobos are shared libraries as well (this is the correct
solution, it's mostly working except for the GC issues)
I agree.
druntime and phobos static linking: phobos and druntime are statically
On 2012-10-01 17:06, Johannes Pfau wrote:
the problem is that we don't want the C main function in a shared
libgdruntime.so, because you might want to use libgdruntime.so in a
C/C++ app which has it's own main function.
So we currently don't link in dmain2.o into the shared library and it
must
On Saturday, 29 September 2012 at 16:09:14 UTC, Jacob Carlborg
wrote:
There's no point in doing that. But what I'm saying is if you
know beforehand the libraries you will use you can get quite
far with static libraries.
There are plenty of cases where you have to use a dynamically
loaded lib
On Friday, 28 September 2012 at 21:26:47 UTC, Iain Buclaw wrote:
The way I intend to address it is to have each module handle
it's own
gshared/thread data and pass the information to the D runtime
during
the module construction stage (.ctor) - there is already
something
done this way for
On 2012-09-30 08:41, Rob T wrote:
There are plenty of cases where you have to use a dynamically loaded lib
even if you know before hand what will be loaded. I think you understand
this if I read your posts correctly.
In my case I have a pre-existing C++ app that is designed to load user
On Sunday, 30 September 2012 at 10:57:24 UTC, Jacob Carlborg
wrote:
On 2012-09-30 08:41, Rob T wrote:
I think most of us know that we need to support all types of
libraries. Static and dynamic, both for link time and runtime.
OK we're all in agreement on this point.
You can have a look at
On 2012-09-28 20:25, Maxim Fomin wrote:
I tried to check how TLS, EX, etc. (mostly exposed to dll issue) are
working and here is some kind of test:
https://github.com/mxfm/sharedtest. Unfortunately scope(exit) isn't
executed when it is situated in a shared library and which calls some
throwing
On 2012-09-28 19:54, Rob T wrote:
I suppose the answer is very complicated, but why can't the runtime
execute as a shared lib? Is it a design limitation of the runtime model?
This sort of problem should have been dealt with from the ground up, not
now. What can be done to fix it, or is it a
On Saturday, 29 September 2012 at 13:19:01 UTC, Jacob Carlborg
wrote:
That's a fairly uninteresting test.
I am not a D developer which means I have no incentive in blindly
portraying D as a language having shared libraries support when
in fact it has some issues. I am a D user which has
On 2012-09-29 17:40, Maxim Fomin wrote:
I was not taking about dynamic loading, but about dynamic linking. If I
understand topic right, the issue is the former, not the latter.
The title of the thread says ... and loading.
BTW, in majority cases dynamic loading gives no advantages over
On 2012-09-28 02:04, Rob T wrote:
I'm using C++ main app that dynamically loads shared libs at runtime,
but I cannot load D shared libs because they cannot be linked to the
non-fPIC built phobos2/druntime lib. It seems that the only way to get
things working is to re-build the C++ code so that
On 2012-09-28 01:21, Rob T wrote:
For me to get C or C++ to run a D function, I had to do the following:
//
// C/C++ library source
//
// sample D function from library
void foo(int i, int j, int k);
// D runtime initialization shutdown
void init();
Am Fri, 28 Sep 2012 02:04:11 +0200
schrieb Rob T r...@ucora.com:
So if I read this right, I can build phobos/druntime with -fPIC
from the source code and it will work OK? If so, then why was
this not done with the latest distrubution package, or is this
only possible after a certain
On 28 September 2012 12:14, Johannes Pfau nos...@example.com wrote:
Am Fri, 28 Sep 2012 02:04:11 +0200
schrieb Rob T r...@ucora.com:
So if I read this right, I can build phobos/druntime with -fPIC
from the source code and it will work OK? If so, then why was
this not done with the latest
I am trying out gdc 4.7 branch with -fPIC, but the info I'm
getting is that even with a successulf PIC build I will still not
be able to reliably execute D functions directly from C/C++ code.
Old patch, which shows what needs to be done:
On 28 September 2012 17:43, Rob T r...@ucora.com wrote:
I am trying out gdc 4.7 branch with -fPIC, but the info I'm getting is that
even with a successulf PIC build I will still not be able to reliably
execute D functions directly from C/C++ code.
Old patch, which shows what needs to be
On Friday, 28 September 2012 at 17:07:16 UTC, Iain Buclaw wrote:
Because the [bleeping] runtime does not support running from a
shared library.
I suppose the answer is very complicated, but why can't the
runtime execute as a shared lib? Is it a design limitation of the
runtime model? This
On Thursday, 27 September 2012 at 17:10:07 UTC, Jacob Carlborg
wrote:
Actually, I seriously doubt everything is working as expected.
I tried to check how TLS, EX, etc. (mostly exposed to dll issue)
are working and here is some kind of test:
https://github.com/mxfm/sharedtest. Unfortunately
On 28 September 2012 18:54, Rob T r...@ucora.com wrote:
On Friday, 28 September 2012 at 17:07:16 UTC, Iain Buclaw wrote:
Because the [bleeping] runtime does not support running from a shared
library.
I suppose the answer is very complicated, but why can't the runtime execute
as a shared
Hi,
I have same issue, but it is possible make shared library,
first of all you have to make shared variant of druntime and
phobos library, than it should work ok.
Now I am at work, when I come back home I will post some more
details about this.
Daniel Kozak
On Wednesday, 26 September
Now I try it, and it is not required to build shared variant of
druntime and phobos, only rebuild it with -fPIC
On Thursday, 27 September 2012 at 06:12:38 UTC, Daniel Kozak
wrote:
Hi,
I have same issue, but it is possible make shared library,
first of all you have to make shared variant of
On Wednesday, 26 September 2012 at 20:15:35 UTC, nazriel wrote:
On Wednesday, 26 September 2012 at 20:10:47 UTC, Michael wrote:
Thanks. The loading part is very useful, but I'm still lost
when it comes to build the shared library itself.
Andrei
Program loads dll at runtime using loader
Am Thu, 27 Sep 2012 08:26:36 +0200
schrieb Daniel Kozak kozz...@gmail.com:
Now I try it, and it is not required to build shared variant of
druntime and phobos, only rebuild it with -fPIC
In the end you'll probably need a shared druntime phobos: Let's say
your main app doesn't use
On Thursday, 27 September 2012 at 05:52:44 UTC, Jens Mueller
wrote:
Maxim Fomin wrote:
You can build shared libraries on linux by manually compiling
object
files and linking them. On windows last time I tries it was not
possible.
Can you give detailed steps for doing this on Linux? Because
On 2012-09-27 10:04, Maxim Fomin wrote:
On Thursday, 27 September 2012 at 05:52:44 UTC, Jens Mueller
wrote:
Maxim Fomin wrote:
You can build shared libraries on linux by manually compiling object
files and linking them. On windows last time I tries it was not
possible.
Can you give detailed
Jacob Carlborg wrote:
On 2012-09-27 10:04, Maxim Fomin wrote:
On Thursday, 27 September 2012 at 05:52:44 UTC, Jens Mueller
wrote:
Maxim Fomin wrote:
You can build shared libraries on linux by manually compiling object
files and linking them. On windows last time I tries it was not
possible.
On Thursday, 27 September 2012 at 08:26:08 UTC, Jacob Carlborg
wrote:
1. Does this actually run?
If it were non-runnable, I wouldn't posted it.
2. This is statically linked with druntime and Phobos. What
happens when you create an executable that links with the D
dynamic library?
On 2012-09-27 10:55, Maxim Fomin wrote:
If it were non-runnable, I wouldn't posted it.
Ok, I see.
Solution depends on a problem. I understood Andrei's post that he wanted
a .so file or DLL. I told originally that it is possible to make shared
libraries on linux. Now I see there is some
On Thursday, 27 September 2012 at 09:16:48 UTC, Jacob Carlborg
wrote:
On 2012-09-27 10:55, Maxim Fomin wrote:
If it were non-runnable, I wouldn't posted it.
Ok, I see.
Solution depends on a problem. I understood Andrei's post that
he wanted
a .so file or DLL. I told originally that it is
On Thursday, 27 September 2012 at 08:26:08 UTC, Jacob Carlborg
wrote:
Last time I tried this (on Mac OS X) I got several symbols
missing. This was all symbols that are usually pointing to the
executable, inserted by the compiler. One of them would be
main and symbols like these:
On 9/27/12 2:26 AM, Daniel Kozak wrote:
Now I try it, and it is not required to build shared variant of druntime
and phobos, only rebuild it with -fPIC
Could you please send a troika composed of one dynlib, one loader using
it, and a makefile that puts the all together?
Thanks much!
On Thursday, 27 September 2012 at 08:03:34 UTC, Maxim Fomin wrote:
On Thursday, 27 September 2012 at 05:52:44 UTC, Jens Mueller
wrote:
Maxim Fomin wrote:
You can build shared libraries on linux by manually compiling
object
files and linking them. On windows last time I tries it was
not
On 2012-09-27 12:02, Daniel Kozak wrote:
With DMD 2.060 last two points are possible, only first point (Using a
shared ...) I dont try
I really need to try this when I get home.
--
/Jacob Carlborg
On Thursday, 27 September 2012 at 13:00:24 UTC, nazriel wrote:
Btw, sorry for OT.
What exactly doesn't work in Dpaste? It seems to work fine for
me(TM).
If those are UI glitches, try pressing F5 2-3 times ;D
Dpaste was completely down when I tried to post code. It was in
the middle of
On 2012-09-27 10:55, Maxim Fomin wrote:
On Thursday, 27 September 2012 at 08:26:08 UTC, Jacob Carlborg wrote:
1. Does this actually run?
If it were non-runnable, I wouldn't posted it.
2. This is statically linked with druntime and Phobos. What happens
when you create an executable that
On 9/27/12 6:26 AM, Maxim Fomin wrote:
[snip]
Thanks! I adapted your code as follows and it works with 2.058 on Centos.
*** lib.d
import std.stdio;
extern(C) int fun()
{
writeln(, world!);
return 42;
}
*** main.d
import std.stdio;
extern(C) int fun();
void main()
{
write(Hello);
On 2012-09-27 20:25, Andrei Alexandrescu wrote:
On 9/27/12 6:26 AM, Maxim Fomin wrote:
[snip]
Thanks! I adapted your code as follows and it works with 2.058 on Centos.
I seriously doubt that everything is working properly, have a look at my
reply to Maxim Fomin:
On Thursday, 27 September 2012 at 17:10:07 UTC, Jacob Carlborg
wrote:
On 2012-09-27 10:55, Maxim Fomin wrote:
On Thursday, 27 September 2012 at 08:26:08 UTC, Jacob Carlborg
wrote:
1. Does this actually run?
If it were non-runnable, I wouldn't posted it.
2. This is statically linked with
On 9/27/12 3:37 PM, Maxim Fomin wrote:
Posted code doesn't load libraries at runtime, it is just linked to
shared libraries.
Exactly! (I can't believe I'm starting to get the hang of this...) But
what we ultimately need is true dynamic loading of never-seen modules.
After the initial test I
For me to get C or C++ to run a D function, I had to do the
following:
//
// C/C++ library source
//
// sample D function from library
void foo(int i, int j, int k);
// D runtime initialization shutdown
void init();
void done();
void bar()
{
On Thursday, 27 September 2012 at 07:54:29 UTC, Johannes Pfau
wrote:
Am Thu, 27 Sep 2012 08:26:36 +0200
schrieb Daniel Kozak kozz...@gmail.com:
Now I try it, and it is not required to build shared variant
of druntime and phobos, only rebuild it with -fPIC
In the end you'll probably need a
On Thursday, 27 September 2012 at 19:57:13 UTC, Andrei
Alexandrescu wrote:
So I think in order to enable true dynamic loading, I'll need
to generate PIC for druntime and phobos, and then link
liblib.so like this:
dmd -fPIC -c lib.d
gcc -shared lib.o -o liblib.so -L/path/to/phobos -lphobos2
Haven't done any dynamic linking with D and I need to. I'm using dmd
2.058/Linux at work to build and use dynamic libraries. Here's my attempt:
*** Makefile
all: main lib.so
main: main.d
dmd main
lib.so: lib.d
dmd -fPIC -shared lib.d -of./lib.so
*** lib.d
extern(C) int
26.09.2012 21:58, Andrei Alexandrescu пишет:
Haven't done any dynamic linking with D and I need to. I'm using dmd
2.058/Linux at work to build and use dynamic libraries.
Sorry for the OT (as you are a Linux user), but if you will ever do it
on Windows, be aware of this nasty trap:
On Wednesday, 26 September 2012 at 17:57:29 UTC, Andrei
Alexandrescu wrote:
Haven't done any dynamic linking with D and I need to. I'm
using dmd 2.058/Linux at work to build and use dynamic
libraries. Here's my attempt:
Maybe it will help you
D:
On 2012-09-26 19:58, Andrei Alexandrescu wrote:
Haven't done any dynamic linking with D and I need to. I'm using dmd
2.058/Linux at work to build and use dynamic libraries. Here's my attempt:
Running make prints:
dmd -fPIC -shared lib.d -of./lib.so
/usr/bin/ld:
On 9/26/12 2:25 PM, Denis Shelomovskij wrote:
26.09.2012 21:58, Andrei Alexandrescu пишет:
Haven't done any dynamic linking with D and I need to. I'm using dmd
2.058/Linux at work to build and use dynamic libraries.
Sorry for the OT (as you are a Linux user), but if you will ever do it
on
On 9/26/12 2:59 PM, Michael wrote:
On Wednesday, 26 September 2012 at 17:57:29 UTC, Andrei
Alexandrescu wrote:
Haven't done any dynamic linking with D and I need to. I'm using dmd
2.058/Linux at work to build and use dynamic libraries. Here's my
attempt:
Maybe it will help you
D:
On 9/26/12 3:18 PM, Jacob Carlborg wrote:
Martin Nowak has a branch for this:
https://github.com/dawgfoto/druntime/tree/SharedRuntime
Thanks, I'll follow up with him.
Andrei
Thanks. The loading part is very useful, but I'm still lost
when it comes to build the shared library itself.
Andrei
Program loads dll at runtime using loader which is configured to
load concrete dll file(s). Like in gtkD
http://www.dsource.org/projects/gtkd/browser/trunk/src/gtkc/Loader.d
On Wednesday, 26 September 2012 at 20:10:47 UTC, Michael wrote:
Thanks. The loading part is very useful, but I'm still lost
when it comes to build the shared library itself.
Andrei
Program loads dll at runtime using loader which is configured
to load concrete dll file(s). Like in gtkD
Loading Shared lib isn't big issues here.
The bigger one is building Shared library (written in D) and
running it in host application without issues (EH, shared GC
etc).
Andrei, if you find out how to make those things work, please
share your findings. I'm also in need of using shared
You can build shared libraries on linux by manually compiling
object files and linking them. On windows last time I tries it
was not possible.
Maxim Fomin wrote:
You can build shared libraries on linux by manually compiling object
files and linking them. On windows last time I tries it was not
possible.
Can you give detailed steps for doing this on Linux? Because nobody as
far as I know has made this work yet?
Jens
68 matches
Mail list logo
