www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - I Did It! Calling D Library from Objective C in XCode on OSX

reply Mike McKee <volomike gmail.com> writes:
I finally managed to get it working, using some help from this 
forum and stackoverflow.com, and a little bit of random luck with 
tests.

// test.d
extern (C++) immutable(char)* dfunc(const char *s) {
	import std.string;
	return toStringz(fromStringz(s) ~ "-response");
}

I compiled with "dmd -c test.d" and it created a test.o file. I 
then created a Cocoa Objective C application in XCode7, but could 
have created a console application in XCode just as well.

Next, drag your test.o file into your XCode project at the top, 
underneath the first icon on the left. A dialog will pop open -- 
just go with the defaults.

I renamed the main.m as main.mm in the project. Remember the 
XCode quirk where if you use a .mm file, you may have to go to 
the project settings under Compile Sources and ensure your .mm 
file is there. If not, add it. I know that it won't do that with 
the main.m file as main.mm, but I think it has a problem with 
AppDelegate.m when renamed as AppDelegate.mm. So, keep that in 
mind.

By making it a .mm file, I can now mix Objective C and C++ 
together.

In the main.mm, I had this:

#import <Cocoa/Cocoa.h>

char *dfunc(const char *);
extern "C" int rt_init();
extern "C" int rt_term();

int main(int argc, const char * argv[]) {
	
	const char *sTest = "request";
	rt_init(); // Call D Runtime
	NSLog( "Result=%s",dfunc(sTest));
	rt_term(); // End D Runtime
	
   return NSApplicationMain(argc, argv);
}

Next, you have to link in AppKit.Framework by going to your 
project settings and choosing Targets > (click your target .app) 

 Build Phases > Link Binary with Libraries, and choose 


AppKit.Framework. This is a quirk in XCode.

Next, you have to link in libphobos2.a from your /usr/local/lib 
folder in a special way. You have to go into your project 
settings. Instead of clicking on your Targets item, click on your 
Projects item and then click > Build Settings > Linking > Other 
Linker Flags. Click the + on that and simply type the file path 
as /usr/local/lib/libphobos2.a. Do not put a -l in front of that 
or even a single "l" in front of it (without the dash). See, this 
is not g++ or gcc, which support that parameter. Instead, this is 
clang++.

Now, Run your project. When you run it, you'll see your default 
Cocoa form, yes, but in the debugger console you'll see 
"Result=request-response". This is because we passed the string 
"request" to dfunct() and it returned it tacked on "-response" on 
the end.

Okay you could stop there, but let's make this even cooler. Let's 
make it where you can code D code in XCode, have it compile and 
create your .o file, before Objective C is compiled and calls 
that .o file. So, include the actual source of the test.d into 
your project by dragging it under the first little folder icon 
from the top and telling the popup dialog to copy the file there.

Edit that test.d so that we return -response2 instead of 
-response, just to let us know we're calling the latest file.

Now, XCode thinks that .d files are DTrace files. It will 
automatically try to compile this test.d file as a DTrace file. 
So, to turn that off, go to your project settings > Targets > 
(your target) > Compile Sources, and remove test.d out of that 
list.

Next, we need to remove that test.o out of the project so that we 
build this before linktime and include it during linking. So, 
remove test.o out of the project. Next, go your project settings 

 Targets > (your target) > Build Phases > and click the + and 


choose New Run Script Phase. Simply paste the following into the 
black code area below the shell field:

/usr/local/bin/dmd -c $SRCROOT/test.d

(Note, this may take some finagling. For instance, in my case for 
some strange reason I had a folder called sample with another 
folder inside also called sample, and the test.d was in that. So, 
my line had to be:)

/usr/local/bin/dmd -c $SRCROOT/sample/test.d

Next, here's another quirk in XCode. It won't let you drag and 
drop this Run Script Phase to before the Compile Sources phases. 
However, it will let you drag other items below it. So, it was 
kind of quirky and tricky, but I made the order like so:

1. Target Dependencies
2. Copy Bundle Resources
3. Run Script
4. Link Binary with Libraries
5. Compile Sources

That ensures that when the linker phase runs, it will see a 
test.o file.

Now we need to ensure the linker sees the test.o file. To do 
that, go to your project settings > Targets > (choose your 
target) > Build Settings > Basic > Linking > Other Linker Flags. 
Remember where we added the libphobos2.a file there? Now we need 
to add the test.o file there. So, doubleclick it's value and 
click the + sign. Type in:

$(SRCROOT)/test.o

Note that even though my test.d was in $SRCROOT/sample, for some 
reason it dropped the test.o in $SRCROOT. So, it may take some 
finagling in your case to ensure you have the right path. Note 
also that paths in XCode are in format $(ENV_VAR), but in Bash 
(/bin/sh) are in $ENV_VAR format.

Next, ensure that the libphobos2.a line is above the test.o line 
in the Other Linker Flags. So, drag it there if you have to do so.

At that point, we're set -- let's compile and run. What will 
happen is that it will compile the test.d file first with the dmd 
compiler and make a test.o, then the linker will link 
libphobos2.a, then link test.o, and then start to compile your 
Objective C and C++. XCode will then merge in what it needs from 
Phobos2 and your test.o into the executable binary and will no 
longer require either one. To prove my point, you can run an 
otool -L command on the binary executable that XCode creates and 
you'll see no references to phobos or test.o.

The output you'll see in your debugger console will say 
RESPONSE=request-response2 because it's running through your 
latest source code.

So, from here on out, you can use Objective C minimally, and 
Objective C++ minimally, and have a lot of your code in D. This 
code can then interact with your Cocoa application. Now, as you 
may know (or learn), Cocoa apps are pretty plain -- Apple's 
pretty fascist here and will let you make any kind of app as long 
as the elements are grey or white, lol. This is why I recommend 
using the Cocoa webkit framework -- you'll get far more color and 
style opportunities to make widgets of any sort. I also recommend 
enabling the Objective C embedding into the HTML DOM so that 
Javascript can call that. At that point, your Javascript can call 
ObjC minimally, and then your ObjC can call D, and then D can 
return a response right back through ObjC back to the Javascript.

As for D calling the Apple Foundation Classes, they are, 
evidently, available to C++, so perhaps they can be loaded in D.
Dec 14 2015
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 12/14/2015 02:09 AM, Mike McKee wrote:

 I finally managed to get it working


Congratulations! But this is not the right medium for this blog post. ;) 
Please polish and publish it somewhere before someone puts it on Reddit 
now. :)

Ali
Dec 14 2015
parent John Colvin <john.loughran.colvin gmail.com> writes:
On Monday, 14 December 2015 at 11:12:03 UTC, Ali Çehreli wrote:

 On 12/14/2015 02:09 AM, Mike McKee wrote:

 I finally managed to get it working


 Congratulations! But this is not the right medium for this blog 
 post. ;) Please polish and publish it somewhere before someone 
 puts it on Reddit now. :)

 Ali


+1 It's great you've achieved this, it would make a good blog 
post.

P.S. Of course posting here is better than not telling anyone at 
all, but blog posts about D are somewhat in short supply.
Dec 14 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-14 11:09, Mike McKee wrote:


 As for D calling the Apple Foundation Classes, they are, evidently,
 available to C++, so perhaps they can be loaded in D.


They're not available in C++. They're available in Objective-C++, which 
is a different language.

Yes, they can be accessed from D [1].

[1] http://dlang.org/spec/objc_interface.html

-- 
/Jacob Carlborg
Dec 14 2015
parent reply Mike McKee <volomike gmail.com> writes:
On Monday, 14 December 2015 at 17:28:20 UTC, Jacob Carlborg wrote:

 [1] http://dlang.org/spec/objc_interface.html


Unfortunately, my version of DMD on this OSX doesn't support the 
(Objective-C) extern when I run the example given at the bottom 
of that objc_interface.html page.

$ dmd -m64 -L-framework -LFoundation test.d
test.d(5): Error: valid linkage identifiers are D, C, C++, 
Pascal, Windows, System
test.d(5): Error: found '-' when expecting ')'
test.d(5): Error: no identifier for declarator C
test.d(5): Error: declaration expected, not ')'
test.d(9): Error: unrecognized declaration

$ dmd --version
DMD64 D Compiler v2.068
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright

I think I installed dmd through homebrew. I don't know how to 
update it -- I'm still green when it comes to homebrew and only 
know apt-get from Ubuntu Linux.
Dec 14 2015
parent reply Mike McKee <volomike gmail.com> writes:
On Monday, 14 December 2015 at 18:13:02 UTC, Mike McKee wrote:

 I think I installed dmd through homebrew. I don't know how to 
 update it -- I'm still green when it comes to homebrew and only 
 know apt-get from Ubuntu Linux.


Oh, I found I could do:

$ sudo brew update
$ sudo brew upgrade dmd

Now it generates this error:

$ dmd -m64 -L-framework -LFoundation test.d
test.d(6): Error: undefined identifier 'selector'
test.d(12): Error: undefined identifier 'selector'
test.d(13): Error: undefined identifier 'selector'

Here's the source I'm trying to compile, and evidently it doesn't 
like  selector for some reason:

// test.d
module main;

extern (Objective-C)
interface Class
{
     NSString alloc()  selector("alloc");
}

extern (Objective-C)
interface NSString
{
     NSString initWithUTF8String(in char* str) 
 selector("initWithUTF8String:");
     void release()  selector("release");
}

extern (C) void NSLog(NSString, ...);
extern (C) Class objc_lookUpClass(in char* name);

void main()
{
     auto cls = objc_lookUpClass("NSString");
     auto str = cls.alloc().initWithUTF8String("Hello World!");
     NSLog(str);
     str.release();
}
Dec 14 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-14 20:20, Mike McKee wrote:


 Oh, I found I could do:

 $ sudo brew update
 $ sudo brew upgrade dmd


Alternatively you can install DMD using DVM [1].


 Now it generates this error:

 $ dmd -m64 -L-framework -LFoundation test.d
 test.d(6): Error: undefined identifier 'selector'
 test.d(12): Error: undefined identifier 'selector'
 test.d(13): Error: undefined identifier 'selector'

 Here's the source I'm trying to compile, and evidently it doesn't like
  selector for some reason:

 // test.d
 module main;

 extern (Objective-C)
 interface Class
 {
      NSString alloc()  selector("alloc");
 }

 extern (Objective-C)
 interface NSString
 {
      NSString initWithUTF8String(in char* str)
  selector("initWithUTF8String:");
      void release()  selector("release");
 }

 extern (C) void NSLog(NSString, ...);
 extern (C) Class objc_lookUpClass(in char* name);

 void main()
 {
      auto cls = objc_lookUpClass("NSString");
      auto str = cls.alloc().initWithUTF8String("Hello World!");
      NSLog(str);
      str.release();
 }


Hmm, that should work.  selector is defined in core.attributes which 
should be imported automatically through the object module. Perhaps the 
compiler doesn't pick up the correct version of druntime.

Could you please add "-v" do the command line when compiling. Look in 
the beginning of the output for "import object". If you open the 
"object" module, it should contain a line like this, in the beginning of 
the file (line 52 for me) :

version (D_ObjectiveC) public import core.attribute : selector;

Then in the "attribute" module (which should come right after the 
"object" module in the output) should contain this, in the bottom of the 
file:

version (D_ObjectiveC) struct selector
{
     string selector;
}

My output with the "-v" flag looks like this:

$ dmd -v main.d
binary    dmd
version   v2.069.1
config    /Users/jacob/.dvm/compilers/dmd-2.069.1/osx/bin/dmd.conf
parse     main
importall main
import    object 
(/Users/jacob/.dvm/compilers/dmd-2.069.1/osx/bin/../../src/druntime/import/object.d)
import    core.attribute 
(/Users/jacob/.dvm/compilers/dmd-2.069.1/osx/bin/../../src/druntime/import/core/attribute.d)
import    std.stdio 
(/Users/jacob/.dvm/compilers/dmd-2.069.1/osx/bin/../../src/phobos/std/stdio.d)

You can also see the config file used in the beginning of the output 
above. That tells the compiler where do find the druntime.

Please try all these commands directly on the command line without using 
Xcode in anyway.

[1] https://github.com/jacob-carlborg/dvm

-- 
/Jacob Carlborg
Dec 14 2015
parent reply Mike McKee <volomike gmail.com> writes:
On Tuesday, 15 December 2015 at 07:52:50 UTC, Jacob Carlborg 
wrote:

 Could you please add "-v" do the command line when compiling.


Mine was completely different:

$ dmd -v test.d
binary    dmd
version   v2.069
config    /usr/local/bin/dmd.conf
parse     test
importall main
import    object	(/Library/D/dmd/src/druntime/import/object.d)
semantic  main
entry     main      	test.d
semantic2 main
test.d(7): Error: undefined identifier 'selector'
test.d(13): Error: undefined identifier 'selector'
test.d(14): Error: undefined identifier 'selector'

Also, look what I have in my import/core folder. It doesn't match 
yours:

atomic.d      checkedint.d  demangle.d    internal/     memory.d  
     simd.d        sync/         thread.d      vararg.d
bitop.d       cpuid.d       exception.d   math.d        runtime.d 
     stdc/         sys/          time.d

So, then I uninstalled dmd via brew, but found it left a 
/Library/D folder behind. Therein lies the problem. So, I did 
sudo brew uninstall --force dmd, sudo su, removed the /Library/D 
folder, and then sudo brew install dmd. Now it works!

volomike:cpptod4 mike$ dmd -m64 -L-framework -LFoundation test.d
volomike:cpptod4 mike$ ls
test	test.d	test.o
volomike:cpptod4 mike$ ./test
2015-12-15 03:07:52.669 test[7308:116958] Hello World!
volomike:cpptod4 mike$
Dec 15 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-15 09:08, Mike McKee wrote:

 On Tuesday, 15 December 2015 at 07:52:50 UTC, Jacob Carlborg wrote:

 Could you please add "-v" do the command line when compiling.


 Mine was completely different:

 $ dmd -v test.d
 binary    dmd
 version   v2.069
 config    /usr/local/bin/dmd.conf
 parse     test
 importall main
 import    object    (/Library/D/dmd/src/druntime/import/object.d)
 semantic  main
 entry     main          test.d
 semantic2 main
 test.d(7): Error: undefined identifier 'selector'
 test.d(13): Error: undefined identifier 'selector'
 test.d(14): Error: undefined identifier 'selector'

 Also, look what I have in my import/core folder. It doesn't match yours:

 atomic.d      checkedint.d  demangle.d    internal/     memory.d
 simd.d        sync/         thread.d      vararg.d
 bitop.d       cpuid.d       exception.d   math.d        runtime.d
 stdc/         sys/          time.d

 So, then I uninstalled dmd via brew, but found it left a /Library/D
 folder behind. Therein lies the problem. So, I did sudo brew uninstall
 --force dmd, sudo su, removed the /Library/D folder, and then sudo brew
 install dmd. Now it works!


So a broken installer. I recommend using DVM [1]. It can install 
multiple versions of DMD and they live side by side completely independent.


 volomike:cpptod4 mike$ dmd -m64 -L-framework -LFoundation test.d
 volomike:cpptod4 mike$ ls
 test    test.d    test.o
 volomike:cpptod4 mike$ ./test
 2015-12-15 03:07:52.669 test[7308:116958] Hello World!
 volomike:cpptod4 mike$


Cool :)

[1] https://github.com/jacob-carlborg/dvm

-- 
/Jacob Carlborg
Dec 15 2015
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 15 December 2015 at 09:04:45 UTC, Jacob Carlborg 
wrote:

 On 2015-12-15 09:08, Mike McKee wrote:

 On Tuesday, 15 December 2015 at 07:52:50 UTC, Jacob Carlborg 
 wrote:

 Could you please add "-v" do the command line when compiling.


 Mine was completely different:

 $ dmd -v test.d
 binary    dmd
 version   v2.069
 config    /usr/local/bin/dmd.conf
 parse     test
 importall main
 import    object    
 (/Library/D/dmd/src/druntime/import/object.d)
 semantic  main
 entry     main          test.d
 semantic2 main
 test.d(7): Error: undefined identifier 'selector'
 test.d(13): Error: undefined identifier 'selector'
 test.d(14): Error: undefined identifier 'selector'

 Also, look what I have in my import/core folder. It doesn't 
 match yours:

 atomic.d      checkedint.d  demangle.d    internal/     
 memory.d
 simd.d        sync/         thread.d      vararg.d
 bitop.d       cpuid.d       exception.d   math.d        
 runtime.d
 stdc/         sys/          time.d

 So, then I uninstalled dmd via brew, but found it left a 
 /Library/D
 folder behind. Therein lies the problem. So, I did sudo brew 
 uninstall
 --force dmd, sudo su, removed the /Library/D folder, and then 
 sudo brew
 install dmd. Now it works!




Using sudo with homebrew is strongly recommended against 
(https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/FAQ.md#why-does-homeb
ew-say-sudo-is-bad- ). I have no idea how you got something in /Library/D, but
it doubt it was from homebrew. In particular, if you weren't using root then I
don't think homebrew would even be able to write there.


 So a broken installer.


Possible, but more likely a leftover from installing dmd some 
other way. Seems to be the case in 90% of "I installed dmd using 
X and it didn't work".


 I recommend using DVM [1]. It can install multiple versions of 
 DMD and they live side by side completely independent.


The important thing is not to mix and match installers unless you 
know how they work.
Dec 15 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-15 15:43, John Colvin wrote:


 I have no idea how you got something in /Library/D, but it doubt it
 was from homebrew.


The native installer installs into /Library/D.


 Possible, but more likely a leftover from installing dmd some other way.
 Seems to be the case in 90% of "I installed dmd using X and it didn't
 work".


Shouldn't an installer make sure the files it installed is the files 
being used?


 The important thing is not to mix and match installers unless you know
 how they work.


DVM will take precedence :)

-- 
/Jacob Carlborg
Dec 15 2015
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 16 December 2015 at 07:46:53 UTC, Jacob Carlborg 
wrote:

 On 2015-12-15 15:43, John Colvin wrote:


 I have no idea how you got something in /Library/D, but it 
 doubt it
 was from homebrew.


 The native installer installs into /Library/D.


Well that probably explains the problem then.


 Possible, but more likely a leftover from installing dmd some 
 other way.
 Seems to be the case in 90% of "I installed dmd using X and it 
 didn't
 work".


 Shouldn't an installer make sure the files it installed is the 
 files being used?


How exactly would it do that? I guess it could parse some output 
from dmd to check that it's looking in the right directories, 
that would be a nice enhancement.

I wouldn't want it to try and do much to fix the situation if it 
didn't work, that would be too intrusive.


 The important thing is not to mix and match installers unless 
 you know
 how they work.


 DVM will take precedence :)


How does it do that?

DVM seems useful if you really need multiple versions of DMD 
installed, but in general I don't like having a special installer 
tool for each piece of software, each with its own way of doing 
things.
Dec 16 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-12-16 10:19, John Colvin wrote:


 How exactly would it do that? I guess it could parse some output from
 dmd to check that it's looking in the right directories, that would be a
 nice enhancement.


Not sure, but for one thing, don't put any files any global directories. 
That is, don't put dmd.conf in /etc, don't put phobos in /usr/lib and so on.


 How does it do that?


It adds DMD to the beginning of the PATH environment variable and 
doesn't rely on any global files.


 DVM seems useful if you really need multiple versions of DMD installed,
 but in general I don't like having a special installer tool for each
 piece of software, each with its own way of doing things.


I can see the point of that. But with the current update rate of D and 
the fact it breaks my code in each single release, I think being able to 
have multiple versions of DMD installed is crucial.

Another advantage is that DVM is cross-platform. If you're using 
multiple platforms you can use the same way to install DMD on all the 
platforms.

-- 
/Jacob Carlborg
Dec 16 2015
prev sibling next sibling parent reply bachmeier <no spam.com> writes:
Is it okay if I copy your post to the wiki at this link?

http://wiki.dlang.org/Cookbook
Dec 14 2015
next sibling parent reply Mike McKee <volomike gmail.com> writes:
On Monday, 14 December 2015 at 19:13:20 UTC, bachmeier wrote:

 Is it okay if I copy your post to the wiki at this link?

 http://wiki.dlang.org/Cookbook


Sure! :)

Feel free to fix grammar or anything out of sorts (or could be 
better said), if you want. My goal is to enable more people to be 
able to do this.
Dec 14 2015
parent bachmeier <no spam.com> writes:
On Monday, 14 December 2015 at 19:15:22 UTC, Mike McKee wrote:

 On Monday, 14 December 2015 at 19:13:20 UTC, bachmeier wrote:

 Is it okay if I copy your post to the wiki at this link?

 http://wiki.dlang.org/Cookbook


 Sure! :)

 Feel free to fix grammar or anything out of sorts (or could be 
 better said), if you want. My goal is to enable more people to 
 be able to do this.


http://wiki.dlang.org/Calling_a_D_library_from_Objective_C_in_XCode

Anyone should feel free to edit it or move it to a better 
location. I don't know anything about this topic. I'm also off to 
give a final exam right now, so the only formatting I did was to 
highlight the code.
Dec 14 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-14 20:13, bachmeier wrote:

 Is it okay if I copy your post to the wiki at this link?

 http://wiki.dlang.org/Cookbook


Please don't. There's a lot of errors and weird things in the post. It 
doesn't really do what the title says. At least it's not interesting at 
all since it uses the C++ interface to call D, not the Objective-C 
interface. Which there is no reason to do, it could just use the C 
interface. No point in mixing C++ in the picture.

-- 
/Jacob Carlborg
Dec 14 2015
parent bachmeier <no spam.com> writes:
On Tuesday, 15 December 2015 at 07:57:56 UTC, Jacob Carlborg 
wrote:

 On 2015-12-14 20:13, bachmeier wrote:

 Is it okay if I copy your post to the wiki at this link?

 http://wiki.dlang.org/Cookbook


 Please don't. There's a lot of errors and weird things in the 
 post. It doesn't really do what the title says. At least it's 
 not interesting at all since it uses the C++ interface to call 
 D, not the Objective-C interface. Which there is no reason to 
 do, it could just use the C interface. No point in mixing C++ 
 in the picture.


I removed the link to it, but I can't delete a wiki page.
Dec 15 2015
prev sibling parent reply pizza_dox_9999 <hanzmeier70 web.de> writes:
On Monday, 14 December 2015 at 10:09:29 UTC, Mike McKee wrote:

 I finally managed to get it working, using some help from this 
 forum and stackoverflow.com, and a little bit of random luck 
 with tests.

 [...]


Hello dlang forum,

I tried to replicate the shown, but I failed at the dmd compile 
stage. The dmd compiler for windows only puts out .obj files and 
no .o files. Is there another flag to set that makes the dmd 
compiler behave differently? Or is there another way to produce 
.o files from dlang source code?

Best regards pizza_dox_9999
Jan 04
parent reply Mike Shah <mshah.475 gmail.com> writes:
On Thursday, 4 January 2024 at 14:17:01 UTC, pizza_dox_9999 wrote:

 On Monday, 14 December 2015 at 10:09:29 UTC, Mike McKee wrote:

 I finally managed to get it working, using some help from this 
 forum and stackoverflow.com, and a little bit of random luck 
 with tests.

 [...]


 Hello dlang forum,

 I tried to replicate the shown, but I failed at the dmd compile 
 stage. The dmd compiler for windows only puts out .obj files 
 and no .o files. Is there another flag to set that makes the 
 dmd compiler behave differently? Or is there another way to 
 produce .o files from dlang source code?

 Best regards pizza_dox_9999


I haven't tried, but ldc2 may also be an option if dmd does not 
support this functionality.
Jan 04
parent pizza_dox_9999 <hanzmeier70 web.de> writes:
On Friday, 5 January 2024 at 05:22:54 UTC, Mike Shah wrote:

 On Thursday, 4 January 2024 at 14:17:01 UTC, pizza_dox_9999 
 wrote:

 On Monday, 14 December 2015 at 10:09:29 UTC, Mike McKee wrote:

 I finally managed to get it working, using some help from 
 this forum and stackoverflow.com, and a little bit of random 
 luck with tests.

 [...]


 Hello dlang forum,

 I tried to replicate the shown, but I failed at the dmd 
 compile stage. The dmd compiler for windows only puts out .obj 
 files and no .o files. Is there another flag to set that makes 
 the dmd compiler behave differently? Or is there another way 
 to produce .o files from dlang source code?

 Best regards pizza_dox_9999


 I haven't tried, but ldc2 may also be an option if dmd does not 
 support this functionality.


Thank you for the response. But it was a silly mistake on my 
side. On debian all compilers produce .o files. I think it was 
the thing that I used them on Windows.
Best regards pizza_dox_9999
Jan 05