On Wednesday, 13 November 2019 at 00:47:11 UTC, cartland wrote:
I now have the following working on Linux and macOS.
*snip*
What is the approach on Windows these days (many posts on the
matter seem out of date)? The shared C dll was built in
MSYS2/MINGW32.
*snip*
FYI
Got it working using t
On Tuesday, 19 November 2019 at 10:10:14 UTC, cartland wrote:
On Wednesday, 13 November 2019 at 00:47:11 UTC, cartland wrote:
*snip*
PS I uninstalled ALL Microsoft build tools and Visual Studios,
then reinstalled DMD and LDC.
I now have the following working on Linux and macOS.
-
name "myapp"
targetType "executable"
description "A minimal D application."
authors "bartland"
copyright "Copyright © 2019, bartland"
license "public"
libs "mylib"
lflags "-L../../_cache/" "-rpath" "../../_cache/"
---
What is the app
On Thursday, 26 January 2017 at 19:01:41 UTC, Tofu Ninja wrote:
Actually.. if I do dub describe on the root package it lists
both the exe and the lib as targets but the build settings for
the lib has "targetType": 6 which according to
dub/source/dub/compilers/buildsettings.d is staticLibrary...
On Thursday, 26 January 2017 at 18:26:27 UTC, Tofu Ninja wrote:
On Thursday, 26 January 2017 at 18:10:12 UTC, Tofu Ninja wrote:
On Thursday, 26 January 2017 at 18:00:57 UTC, Tofu Ninja wrote:
Is this not doable?
I guess an alternative question, is there any way to have
multiple binaries(an e
On Thursday, 26 January 2017 at 18:10:12 UTC, Tofu Ninja wrote:
On Thursday, 26 January 2017 at 18:00:57 UTC, Tofu Ninja wrote:
Is this not doable?
I guess an alternative question, is there any way to have
multiple binaries(an executable and a bunch of shared libs)
built from a single dub pa
On Thursday, 26 January 2017 at 18:00:57 UTC, Tofu Ninja wrote:
Is this not doable?
I guess an alternative question, is there any way to have
multiple binaries(an executable and a bunch of shared libs) built
from a single dub package? Or should I just give up on trying to
use dub for this...
On Sunday, 22 January 2017 at 08:16:49 UTC, Tofu Ninja wrote:
Trying to get a dub sub package to output as a shared lib but
for some reason I can only get it to output as a static lib.
dub.json
---
{
"name": "tofueng",
"targetType": "execut
Trying to get a dub sub package to output as a shared lib but for
some reason I can only get it to output as a static lib.
dub.json
---
{
"name": "tofueng",
"targetType": "executable",
"targetPath" : "game",
ok i actually did everything right x3 ... but my code threw some
warnings which are interpreted as errors by default.
/solved
i want to build a shared library (.so) with dub. currently i
compile with a shell script, but i'd like to use dub
[code]
dmd -c test.d -fPIC
dmd -ofcod4xalicebridge.so test.o -shared -g -w -debug
-version=Have_cod4xalicebridge
[/code]
could anyone tell me how my dub.json has to look like?
my
It's how COM casts objects
http://msdn.microsoft.com/en-us/library/ms687230.aspx
The idea is that the object you work with is responsible for
casting itself to an interface you need.
On Tuesday, 21 October 2014 at 13:57:23 UTC, Kagamin wrote:
On Monday, 20 October 2014 at 15:07:43 UTC, MrSmith wrote:
On Monday, 20 October 2014 at 14:05:29 UTC, Kagamin wrote:
Do it the COM way: publish IModule2 interface and declare
GetInterface method, which will return a prepared pointer,
On Monday, 20 October 2014 at 15:07:43 UTC, MrSmith wrote:
On Monday, 20 October 2014 at 14:05:29 UTC, Kagamin wrote:
Do it the COM way: publish IModule2 interface and declare
GetInterface method, which will return a prepared pointer,
which you would reinterpret cast to IModule2.
Will it work
it's not possible to load new types at
runtime and use them in code that was compiled without knowing
those types.
You should simply use interfaces to achieve your goal.
In this case ether shared lib knows actual type.
But i've tried it with interfaces, (upcast also), or do you mean
On 10/20/2014 12:32 AM, MrSmith wrote:
Than any module can search for registered modules and try to cast them
to concrete type (upcast).
That can't work because the notion of types only exists during
compilation. Therefor it's not possible to load new types at runtime and
use them in code tha
On Monday, 20 October 2014 at 14:05:29 UTC, Kagamin wrote:
Do it the COM way: publish IModule2 interface and declare
GetInterface method, which will return a prepared pointer,
which you would reinterpret cast to IModule2.
Will it work on linux with simple .so libs?
I want it to be as simple as
Do it the COM way: publish IModule2 interface and declare
GetInterface method, which will return a prepared pointer, which
you would reinterpret cast to IModule2.
main
other
module1 dll
IModule
Module1
Module2 - should i import it, compile of import .di file?
module2 dll
IModule
Module2
Is it possible at all? Or it is an issue with Windows shared lib
support?
On Monday, 26 May 2014 at 10:59:00 UTC, Dejan Lekic wrote:
bioinfornatics wrote:
Hi, after building and installing dmd i fail to use generated
executable because they are an undefined symbol.
$ /opt/dmd/bin/dmd -L-lcurl testDelegate.d
$ ./testDelegate
./testDelegate: symbol lookup error:
/op
bioinfornatics wrote:
> Hi, after building and installing dmd i fail to use generated
> executable because they are an undefined symbol.
>
>
> $ /opt/dmd/bin/dmd -L-lcurl testDelegate.d
>
> $ ./testDelegate
> ./testDelegate: symbol lookup error:
> /opt/dmd/lib/libphobos2.so.0.66: undefined symb
Hi, after building and installing dmd i fail to use generated
executable because they are an undefined symbol.
$ /opt/dmd/bin/dmd -L-lcurl testDelegate.d
$ ./testDelegate
./testDelegate: symbol lookup error:
/opt/dmd/lib/libphobos2.so.0.66: undefined symbol:
curl_version_info
$ ldd ./testDeleg
On 11/12/2012 12:54 AM, Johannes Pfau wrote:
How did you link that shared lib? With ld, gcc or g++? If you link via
gcc it pulls in some special object files, one of these could contain
__data_start. g++ pulls in some more object files for c++ support, but
that's probably not necessary
On 2012-11-12 10:02, Jacob Carlborg wrote:
I'm not sure but I think it won't. The runtime needs to iterate all
loaded images (executables and dynamic libraries) and collect the data
section of each image.
I think "dl_iterate_phdr" needs to be used. That is what the Boehm GC
uses on Linux.
-
On 2012-11-12 09:54, Johannes Pfau wrote:
But anyway, the runtime uses __data_start to find the data
section which should be scanned by the gc (see rt.memory). I really
doubt this approach will work in an application with multiple shared
libraries.
I'm not sure but I think it won't. The runtim
Am Sun, 11 Nov 2012 18:49:18 -0800
schrieb Ellery Newcomer :
> Playing with pypy.
>
> I build me a shared library with ldc and try to access it via ctypes,
> and it gives me a
>
> /usr/lib64/libdruntime-ldc.so.60: undefined symbol: __data_start
How did you link that shared
a symbol that points to the data section or something and that it
is relevant in executables but not shared libraries (and thus shouldn't
be in druntime for shared lib builds)?
Yes, although I don't know if it should be in shared libraries or not.
--
/Jacob Carlborg
or something and that it
is relevant in executables but not shared libraries (and thus shouldn't
be in druntime for shared lib builds)?
On 2011-11-16 01:27, Ellery Newcomer wrote:
On 11/15/2011 01:19 AM, Jacob Carlborg wrote:
On 2011-11-14 19:05, Ellery Newcomer wrote:
core.runtime.Runtime.initialize
cool
Not sure if that will initialize everything properly. Have a look in
rt.dmain2.main and make sure you do that same init
On 11/15/2011 01:19 AM, Jacob Carlborg wrote:
> On 2011-11-14 19:05, Ellery Newcomer wrote:
>
> core.runtime.Runtime.initialize
cool
>
> Not sure if that will initialize everything properly. Have a look in
> rt.dmain2.main and make sure you do that same initialize the runtime.
yep, found that
On 2011-11-14 19:05, Ellery Newcomer wrote:
On 11/14/2011 10:31 AM, Jerry wrote:
The error looks like phobos wasn't build with
position-independent code.
Jerry
you know, I think you're right. I even wrote out the names of all those
*.a files when I was building a gdc rpm. *slaps head*
well,
c/issue/166/add-shared-lib-support).
Yeah, that's right, forgot it was not about DMD.
--
/Jacob Carlborg
Ellery Newcomer writes:
> well, it doesn't matter now. I've gotten ldc to generate shared libs
> successfully. Now I just need to know how to start up druntime.
>
> any ideas?
I haven't tried LDC, sorry. I'd think you would use it similarly to
C++. I.e. link your main program to the shared lib
e relocated. The error looks like phobos wasn't build with
>> position-independent code. Beyond that I don't know.
>>
>> Jerry
>
>DMD cannot currently generate correct PIC on linux.
>
That's a backend bug though, GDC and LDC shouldn't be affected. But
some inline asm in phobos also doesn't work in PIC (see
https://bitbucket.org/goshawk/gdc/issue/166/add-shared-lib-support).
--
Johannes Pfau
On 11/14/2011 10:31 AM, Jerry wrote:
> The error looks like phobos wasn't build with
> position-independent code.
>
> Jerry
you know, I think you're right. I even wrote out the names of all those
*.a files when I was building a gdc rpm. *slaps head*
well, it doesn't matter now. I've gotten ldc t
On 2011-11-14 17:31, Jerry wrote:
Ellery Newcomer writes:
trying to build a .so file (actually, trying to resuscitate pyd) with gdc.
celerid is spitting out
gdc -fPIC -nostartfiles -shared -fdebug {lots of object files plus some
link directives}
which is spitting out
/usr/bin/ld: /usr/lib6
Ellery Newcomer writes:
> trying to build a .so file (actually, trying to resuscitate pyd) with gdc.
>
> celerid is spitting out
>
> gdc -fPIC -nostartfiles -shared -fdebug {lots of object files plus some
> link directives}
>
> which is spitting out
>
> /usr/bin/ld: /usr/lib64/libgphobos2.a(objec
trying to build a .so file (actually, trying to resuscitate pyd) with gdc.
celerid is spitting out
gdc -fPIC -nostartfiles -shared -fdebug {lots of object files plus some
link directives}
which is spitting out
/usr/bin/ld: /usr/lib64/libgphobos2.a(object_.o): relocation
R_X86_64_32S against `_D
39 matches
Mail list logo
