On 2015-05-30 01:03, bitwise wrote:
No, it opens the image for the main program, even if called from a
shared lib.
And that void* which is returned is actually a mach_header*, if I
recall correctly.
Not sure if this is true.
I see, it was mostly a guess.
--
/Jacob Carlborg
On Sat, 30 May 2015 05:06:34 -0400, Jacob Carlborg d...@me.com wrote:
On 2015-05-30 01:03, bitwise wrote:
No, it opens the image for the main program, even if called from a
shared lib.
And that void* which is returned is actually a mach_header*, if I
recall correctly.
Not sure if this is
On Wednesday, 27 May 2015 at 21:24:25 UTC, bitwise wrote:
Basically, I've gone back to the idea of using the dylib
ctor/dtors. I don't think we really even need the image-added
callback, at least not for dylibs.
Looks good. The compiler could add a simple ctor/dtor to any D
object.
On 2015-05-27 23:24, bitwise wrote:
Good point.
I've come up another solution and posted it here:
http://dpaste.com/0DXBSNQ
Will dladdr return different values (mach_header) for different
dynamic libraries? Won't there only be one init function, as you said
earlier. Or does it work somehow
On Friday, 29 May 2015 at 12:46:43 UTC, Jacob Carlborg wrote:
On 2015-05-27 23:24, bitwise wrote:
Good point.
I've come up another solution and posted it here:
http://dpaste.com/0DXBSNQ
Will dladdr return different values (mach_header) for
different dynamic libraries? Won't there only be
On Fri, 29 May 2015 14:05:10 -0400, Jacob Carlborg d...@me.com wrote:
On 2015-05-29 18:45, bitwise wrote:
I'm going to test it out this weekend, but if I do get the wrong
address, I think I can add a symbol with __attribute__ ((visibility
(hidden))) and use dladdr on that instead. I don't
On 2015-05-29 18:45, bitwise wrote:
I'm going to test it out this weekend, but if I do get the wrong
address, I think I can add a symbol with __attribute__ ((visibility
(hidden))) and use dladdr on that instead. I don't think hidden
symbols should collide.
Doesn't dlopen open the current
On 2015-05-27 23:24, bitwise wrote:
Good point.
I've come up another solution and posted it here:
http://dpaste.com/0DXBSNQ
BTW, I'm not sure what's the best solution but you can calculate the
slide without iterating all images. Look at the first statements in
On Tuesday, 26 May 2015 at 16:25:52 UTC, bitwise wrote:
Isn't it better to avoid private undocumented functions?
Not only better, but mandatory, otherwise Apple will reject the
app from the app store.
Calling back into an unloaded image without proving a mean to
deregister the callback is a
On Wednesday, 27 May 2015 at 06:45:49 UTC, Jacob Carlborg wrote:
I'm not sure. The ___tls_get_addr function [1] is used when
accessing a TLS variable on OS X. In all native
implementations, both on OS X and Linux, the parameter is not
just a void* but struct containing the image header as
On Tuesday, 26 May 2015 at 16:25:52 UTC, bitwise wrote:
Since all global functions and symbols are shared between
images anyways, receiving the callback in the main image would
be fine. So in this case, unregistering the callbacks is no
longer needed.
That only works when the host executable
On 2015-05-27 15:38, Martin Nowak wrote:
On Linux you call it with an dso index and an offset. The DSO index is
assigned by the runtime linker (there is a special relocation for that).
Something similar could be done manually if not natively supported on OSX.
It is natively support.
--
On Wed, 27 May 2015 02:45:57 -0400, Jacob Carlborg d...@me.com wrote:
What about using a D dynamic library in a C application? The C
application would initialize the runtime which would register the
callback. Then it would be undefined to unload druntime?
Good point.
I've come up another
On 2015-05-26 18:25, bitwise wrote:
I think Martin is right. We don't need ctors/dtors or any compiler
fanciness. All we need is the two callbacks, which can be registered
when druntime is initialized.
_dyld_register_func_for_add_image
_dyld_register_func_for_remove_image
At this point, we
On 2015-05-25 21:40, bitwise wrote:
So then I think I have a full solution:
1) _dyld_register_func_for_add_image should be taken care of with the
above two fixes
2) __attribute__((constructor/destructor)) can be added to druntime when
building for osx like in the file dylib_fixes.c [1]
3) copy
On 2015-05-25 22:58, Martin Nowak wrote:
On Monday, 25 May 2015 at 19:40:52 UTC, bitwise wrote:
1) _dyld_register_func_for_add_image should be taken care of with the
above two fixes
You still cannot unregister the callback, so it can't be used for
dynamically loading druntime. Last time we
On Tue, 26 May 2015 02:28:14 -0400, Jacob Carlborg d...@me.com wrote:
On 2015-05-25 22:58, Martin Nowak wrote:
On Monday, 25 May 2015 at 19:40:52 UTC, bitwise wrote:
1) _dyld_register_func_for_add_image should be taken care of with the
above two fixes
You still cannot unregister the
I've been reading through the Mach-O docs[1], and it seems that dynamic
libs are treated the same as static libs in that exported symbols can only
be defined once, even across dynamically loaded libraries. This is why
calling rt_init from my dylib ended up calling the one that was already
On 2015-05-25 16:33, bitwise wrote:
I've been reading through the Mach-O docs[1], and it seems that dynamic
libs are treated the same as static libs in that exported symbols can
only be defined once, even across dynamically loaded libraries. This is
why calling rt_init from my dylib ended up
On Monday, 25 May 2015 at 14:33:43 UTC, bitwise wrote:
At this point, my impression is that it would be very
impractical, if not impossible to have separate druntimes for
each shared library. Even when you do link separate runtimes,
dyld still treats all the exported symbols as shared.
Yes,
On Monday, 25 May 2015 at 19:40:52 UTC, bitwise wrote:
1) _dyld_register_func_for_add_image should be taken care of
with the above two fixes
You still cannot unregister the callback, so it can't be used for
dynamically loading druntime. Last time we talked about this
problem, we found some
On Mon, 25 May 2015 14:39:37 -0400, Jacob Carlborg d...@me.com wrote:
On 2015-05-25 16:33, bitwise wrote:
I've been reading through the Mach-O docs[1], and it seems that dynamic
libs are treated the same as static libs in that exported symbols can
only be defined once, even across dynamically
I've read through these now, which I missed the first time around, so
sorry for making you guys repeat yourselves ;)
Runtime issue on Mac OS X
http://comments.gmane.org/gmane.comp.lang.d.runtime/1214
ideas for runtime loading of shared libraries.
On Sun, 24 May 2015 15:40:04 -0400, bitwise bitwise@gmail.com wrote:
[snip]
So at this point, it seems like these two fixes work as expected, but
now, I'm having some new and very strange problems.
I have a simple shared library and program I've been using to test this:
[main.d]
On 2015-05-22 18:12, Martin Nowak wrote:
One could also make emulated TLS work with shared libraries.
Yeah, but then you would need to implement something similar to the TLS
code already present in the dynamic linker in druntime. Both
alternatives would require changes to both the compiler
On 2015-05-22 03:13, bitwise wrote:
So does that mean that _dyld_register_func_for_add_image shouldn't be
called at all from shared libs at all then? The fact that there is no
unregister function seems to suggest that it's meant to be called once
from the main executable to add a callbacck that
On Wednesday, 20 May 2015 at 21:35:38 UTC, bitwise wrote:
Heh.. That's pretty useless. Any idea on the state of things?
Like if there are plans to support this in the near future(few
months)? I couldn't find many conversations on this. This
kinda-totally ruins my plans(on OSX at least).
Have
On Thursday, 21 May 2015 at 08:07:49 UTC, Jacob Carlborg wrote:
I don't think anyone is working on this. Native TLS is a
prerequisite which requires changes both to the compiler and
the runtime. There's an enhancement request for native TLS [1].
One could also make emulated TLS work with
On Thursday, 21 May 2015 at 01:31:37 UTC, bitwise wrote:
I've been reading over all the bugs and conversations I can
find, but I'm still confused about exactly what's going on here.
What I need:
-load a dynamic library on OSX using dlopen or
Runtime.loadLibrary
-use dlsym to retrieve my
On Thursday, 21 May 2015 at 15:51:38 UTC, bitwise wrote:
I'm not sure exactly what you mean about integrated runtime.
I think he means Phobos/Druntime as shared library.
Looking in /usr/share/dmd/lib, I see phobos as a static library
(which I'm assuming includes druntime, which I don't see
On 2015-05-20 23:35, bitwise wrote:
Heh.. That's pretty useless. Any idea on the state of things? Like if
there are plans to support this in the near future(few months)? I
couldn't find many conversations on this. This kinda-totally ruins my
plans(on OSX at least).
I don't think anyone is
On 2015-05-21 07:06, Joakim wrote:
Actually, TLS works on OS X: dmd emulates it, while ldc has native TLS
using undocumented OS X APIs.
The emulated TLS won't work with dynamic libraries. The runtime can only
fetch the TLS data from one source, which will be the executable itself.
I'm
dlopen() of a D shared library works when called from a C++ file, and that
a C++ file can call multiple D shared libraries simultaneously when using
RTLD_LAZY option.
Before waiting for a full solution with an integrated druntime, is there at
least a way to have a separate runtime in each shared
On Thu, 21 May 2015 15:34:56 -0400, Jacob Carlborg d...@me.com wrote:
On 2015-05-21 10:12, Timothee Cour via Digitalmars-d wrote:
dlopen() of a D shared library works when called from a C++ file, and
that a C++ file can call multiple D shared libraries simultaneously when
using RTLD_LAZY
On Thu, 21 May 2015 21:13:56 -0400, bitwise bitwise@gmail.com wrote:
Can't whatever the callback does be done from the runtime linked to the
main executable?
Or simply use dlsym from the main executable to call back into the dylib
to set things up?
Bit
On 2015-05-21 17:51, bitwise wrote:
I'm not sure exactly what you mean about integrated runtime.
Looking in /usr/share/dmd/lib, I see phobos as a static library (which
I'm assuming includes druntime, which I don't see anywhere). If the
runtime is linked as a static library, shouldn't it be
On 2015-05-21 10:12, Timothee Cour via Digitalmars-d wrote:
dlopen() of a D shared library works when called from a C++ file, and
that a C++ file can call multiple D shared libraries simultaneously when
using RTLD_LAZY option.
Before waiting for a full solution with an integrated druntime, is
On Thu, 21 May 2015 04:12:19 -0400, Timothee Cour via Digitalmars-d
digitalmars-d@puremagic.com wrote:
dlopen() of a D shared library works when called from a C++ file, and
that
a C++ file can call multiple D shared libraries simultaneously when using
RTLD_LAZY option.
Before waiting for a
On Wednesday, 20 May 2015 at 18:53:30 UTC, Jacob Carlborg wrote:
On 2015-05-20 16:44, bitwise wrote:
I tried using a shared library for OSX yesterday. I opened it
with
dlopen, retrieved my extern(C) function, and called it. All
was well,
and it seemed to work(wrote to the console with
On 2015-05-20 16:44, bitwise wrote:
I tried using a shared library for OSX yesterday. I opened it with
dlopen, retrieved my extern(C) function, and called it. All was well,
and it seemed to work(wrote to the console with writeln).
But, I got a message in the console saying shared libraries were
On Wed, 20 May 2015 17:35:37 -0400, bitwise bitwise@gmail.com wrote:
On Wednesday, 20 May 2015 at 18:53:30 UTC, Jacob Carlborg wrote:
On 2015-05-20 16:44, bitwise wrote:
I tried using a shared library for OSX yesterday. I opened it with
dlopen, retrieved my extern(C) function, and called
On Wednesday, 20 May 2015 at 21:35:38 UTC, bitwise wrote:
On Wednesday, 20 May 2015 at 18:53:30 UTC, Jacob Carlborg wrote:
On 2015-05-20 16:44, bitwise wrote:
I tried using a shared library for OSX yesterday. I opened it
with
dlopen, retrieved my extern(C) function, and called it. All
was
42 matches
Mail list logo
