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
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
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
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
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
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
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?
The idea is that the object you work with is responsible for
casting itself to an interface you need.
It's how COM casts objects
http://msdn.microsoft.com/en-us/library/ms687230.aspx
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
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,
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.
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
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
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
something else
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?
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 symbol:
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:
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
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
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 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 here
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 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 file
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
Ellery Newcomer ellery-newco...@utulsa.edu 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:
On 2011-11-14 17:31, Jerry wrote:
Ellery Newcomerellery-newco...@utulsa.edu 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
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 to
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
Ellery Newcomer ellery-newco...@utulsa.edu 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
-shared-lib-support).
Yeah, that's right, forgot it was not about DMD.
--
/Jacob Carlborg
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,
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
37 matches
Mail list logo
