DLL equivalent on a Mac?

BlitzMax Forums/BlitzMax Programming/DLL equivalent on a Mac?

JoshK(Posted 2008) [#1]
Is there an equivalent to a dll in MacOS? I can make the script version of Leadwerks Engine work in Mac. The BlitzMax module will work in Mac. Is there a way to make a programmable library like a DLL for Mac, that all programmers can control with any language?

MrTAToad(Posted 2008) [#2]
I presume Frameworks would be the Mac equivilent

Perturbatio(Posted 2008) [#3]
I think they're called shared libraries.

JoshK(Posted 2008) [#4]
Can BlitzMax compile them?

Brucey(Posted 2008) [#5]

JaviCervera(Posted 2008) [#6]
The Mac equivalent to dll files are files with the .dylib extension.

Koriolis(Posted 2008) [#7]
I thought someone would mention it, but you can most probably do a dylib with BlitzMax, "by hand".
Create a dylib project in xcode, and include the (release version) static libs files (.a) produced by the compilation of your module.
Absolutely untested, but I see no obvious reason why it wouldn't work (especially given that BlitzMax uses the XCode version of GCC under the hood anyway).
Once you've got it to work, you should refine this by making sure not to export unwanted symbols. By default, shared library ala Unix/Linux export everything.
One possibility is to use "version scripts".

Brucey(Posted 2008) [#8]
I see no obvious reason why it wouldn't work

They don't appear to like location-specific assembler - like what BlitzMax makes.

Koriolis(Posted 2008) [#9]
Assembler? I'm talking about object code archives, not assembler source code (note: the ".a" extension is used both for assembler source code and UNIX-like compiled code archives). Or were yous precisely talking about the (binary, object code) archives?
And by "location-specific", do you mean there are absolute paths somewhere ?

Brucey(Posted 2008) [#10]
From my experiments I get errors related to non-relocatable assembler, which appears to be the kind of assembler that BlitzMax generates.

But I'm sure it's just something I've been doing wrong... :-p

Koriolis(Posted 2008) [#11]
Oh, dammit. Yes you're totally right, code for a shared lib must be compiled with the "Position Independent Code" option (-fpic) and I there's no reason for BlitzMax to pass this option to gcc.
I seem to remember you managed to tweak the BlitzMax compiler front end to pass different options to gcc (or am I crazy...?), couldn't you try to add "-fPIC" ?

EDIT: Mmmm, I found a page on the net stating that on MacOS, -fPic is implied by default, so this should work out of the box.
EDIT2: Unless the problem occurs before the linker is even called. OK, enough of "maybe", I'll have to check by myself before throwing more hypotheses. I have too little knowledge about how BlitzMax ties everything together unde the hood.
EDIT3: now I get the feeling that you were really talking about the assembler *source code* that appeared to be not compilable with "-fPIC" after you precisely tried to add the option ... right ?

Brucey(Posted 2008) [#12]
the assembler *source code* that appeared to be not compilable

From my experiments attempting to build a screensaver (which requires the object file built with specific compiler flags), the errors I couldn't work around were to do with the generated assembler code.

If you can find a way around it, I'd be interested to see it :-)

Koriolis(Posted 2008) [#13]
Well, this raised my interest, for sure. I'll definitely have a look, the big question is when I'll have time. In any case, I'll be sure to report my findings, if any.

Koriolis(Posted 2008) [#14]
OK, I took some time to look at this, and sadly all I can do is confirm your diagnostic: the assembly generated by BlitzMax (at least on a PPC mac) is not relocatable. So it seems simply impossible to build reliable dylibs. There's not much that can be done there :/
Only BRL could do somthing, and they've got better things to do I guess.

Brucey(Posted 2008) [#15]

ImaginaryHuman(Posted 2009) [#16]
I was just reading through this thread since I was sort of interested in finding out if it is at all possible to get BlitzMax code to integrate with the objective-c screensaver framework in xcode. You look like you've already been experimenting far further than I have and met some dead ends. Oh well. Looks to me as though the only way to make Mac screensavers is to specifically create a screensaver project in xcode, to specifically use the screensaver framework which appears to include the automatic opening of a fullscreen display, and use the framework's timing system to update the display. To in any way shape or form get some kind of blitzmax code to be called from that to do initialization and updating, suggests you'd have to have some way to either a) get xcode to understand blitzmax code (a plugin?) and compile it and figure out how to call blitz's functions from the objective-c framework, or use blitz's output files like you tried to do. Otherwise it seems like you have to write the screensaver in objective c entirely.

I suppose you could do what people used to do in the old days, e.g. on the Amiga - just create your own screensaver engine, like a little app that sits running on your computer, maybe with a tiny window in the corner of the desktop that senses mouse-over to trigger, and then after activation opens up a normal blitzmax opengl window, show an effect, and close the screen when a key is pressed or mouse moved. It wouldn't integrate at all with the system preferences screensaver panel or preview window, though. But hey, some people actually made these things in the old days, like `after dark`.

Or find a way to call blitz code from objective c?

Brucey(Posted 2009) [#17]
...if it is at all possible to get BlitzMax code to integrate with the objective-c screensaver framework in xcode.

It ain't easy...

ImaginaryHuman(Posted 2009) [#18]
[snip for new subject]