PureBasic Forums - English

Been a while since I've done any MacOSX programming but needed to create a shared library today and is well in that regard.

I created a simple shared lib and PB furnished me with a .so file much to my surprise - I was expecting a .dylib.

I used OpenLibrary() to run the exported functions and no problem.

Being a Windows man at heart I then scratched my head looking for the equivalent of a Windows import library (.lib) for the shared library; meaning that I can use Import and statically link the function stubs etc.

Anyhow; I couldn't find one and so resigned myself to having to load the shared lib through OpenLibrary() etc.

Then, just for the hell of it, I tried Import directly on the .so file and... it worked!

What the deuce is going on here?

Can someone shed some light on this and perhaps explain the differences between a .so file and a .dylib? My puzzlement undoubtedly arises from my severe entrenchment within WIndows.

Thanks.

this might shed some light difference between shared library (dylib) vs loadable module (bundle)
http://www.finkproject.org/doc/porting/shared.php

Did you try to compile the executable with the imports and run it, It might not find the .so if you use import.

Thanks for the link - though I'd already come across that one. This time I ran the otool utility to look at the .so file and it comes up as a dylib (as opposed to a loadable module which normally carries a .so extension!) The article says that shared libs (.dylib) can be linked against (as well as dynamically loaded via an API) which appears to be what I discovered earlier.

So why does PB shove a .so extension on these files in place of .dylib?

I did find that my shared lib still has to be within arms reach of the executable even following static linking. But then I have just found the following from the manual for the ld linker :

A dynamic library (aka dylib or framework) is a final linked image. Putting a dynamic library on the command line causes two things: 1) The generated final linked image will have encoded that it depends on that dynamic library. 2) Exported symbols from the dynamic library are used to resolve references.

Seems to answer my questions.

Truth is though that there is so much contradictory info out on the web regarding this kind of thing.

I can't say any of it makes sense to me but then I don't have a mac or have any sense, come to think about it!

I think it's a problem on PB side, as it's a dylib which is created. Feel free to rename it until it get it fixed

Hi Fred, renaming is fine if using OpenLibrary() etc. Otherwise, with static linking, the system insists on keeping the .so extension!