DLL equivalent on a Mac?
BlitzMax Forums/BlitzMax Programming/DLL equivalent on a Mac?
| ||
| 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? |
| ||
| I presume Frameworks would be the Mac equivilent |
| ||
| I think they're called shared libraries. |
| ||
| Can BlitzMax compile them? |
| ||
| Nope |
| ||
| The Mac equivalent to dll files are files with the .dylib extension. |
| ||
| 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". http://www.google.fr/search?hl=fr&q=gcc+visibility+%22version+scripts%22&meta= |
| ||
| I see no obvious reason why it wouldn't work They don't appear to like location-specific assembler - like what BlitzMax makes. |
| ||
| 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 ? |
| ||
| 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 |
| ||
| 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 ? |
| ||
| 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 :-) |
| ||
| 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. |
| ||
| 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. |
| ||
| yep. |
| ||
| 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? |
| ||
| ...if it is at all possible to get BlitzMax code to integrate with the objective-c screensaver framework in xcode. It ain't easy... |
| ||
| [snip for new subject] |
   |