I'm trying to compile my own dylib with some code I want to reuse. (I'm putting it in that format as a learning experiment of sorts.)

I can compile it fine, but I'm not sure how to actually use it a project. Like in apple's example, I wrapped the "#pragma GCC visibility push(default)" tags (with pop) around my header file that declares the class and it's functions. (Not sure why it's there though... wouldn't they go in the cpp file, as it's the one with half the function definitions?)

Anyway, as I've seen in other libs and API's in the past, like GLUT and OpenGL, they accompany the library with a header file that "externs" all the functions in the lib, like so:


And such. Is this what I should do? But how would I get that header to read the dylib? With more "pragma" commands? As I understand it, pragma designates some form of compiler comment, but I'm not sure about that.

Thanks!

EDIT: I've also got my header set to "public"...

extern functions in header files serve only to let the compiler know that a function with that signature exists, and will be resolved later by the linker. You need to add the dylib to the files that are linked when you build the executable.

Don't use a dylib. They cause pain and suffering.

Even a framework is probably overkill, though it's certainly better.

Try a static library instead.

OneSadCookie Wrote:Don't use a dylib. They cause pain and suffering.

Even a framework is probably overkill, though it's certainly better.

Try a static library instead.

You mean one of those .a things? Yeah, I think I made one of those with the g++ command line compiler once... lets see if I can do it again..

EDIT: I'd actually like to make a framework, they're great for easy project management. Cocoa or Carbon?

Static library command:
ar rc lib.a list.o of.o objects.o
You get the .o objects with the -c option to gcc/g++.

Frameworks are easiest to make with XCode. Just make a project/add a new target for a framework.

akb825 Wrote:Static library command:
ar rc lib.a list.o of.o objects.o
You get the .o objects with the -c option to gcc/g++.

Frameworks are easiest to make with XCode. Just make a project/add a new target for a framework.

Well here's what I did, and I got loads of errors:

Dragged the cpp file and both it's headers into an empty project with a carbon framework target. Compiled. Opened the framework in finder. Dragged the main header to the frameworks (newly created) "Headers" folder. Added the framework to a testbed project. Compiled. Got errors.

Meh, oh well. It was just an experiment, also trying to make something easier to add to a project. I'd just finished adding Mac OS X/Big Endian support to the glFont API, and was just trying to compile the two (three, counting my addition) source files into something simple. If anybody knows of a good tutorial/reference page that might give easy instructions to do this.

Thanks!

ThemsAllTook Wrote:extern functions in header files serve only to let the compiler know that a function with that signature exists, and will be resolved later by the linker. You need to add the dylib to the files that are linked when you build the executable.

Hang on, if I compiled a static library (.a) with a function called int mySuperCoolFunctionThatDoesEverything(void). And then chucked it into an xCode project with a header containing this:


And then included that header in my main file, could I use that function? Oh yeah, and when it comes to classes (lets say my lib had a class called "bob"), would this be suitable?


Thanks!

include whatever header your library has, just use the functions from that and dont declare extern functions for this reason, at least thats what I always do and it seems to work fine for me.

This page might be helpful. It's Cocoa oriented but I don't think you need any Cocoa skills to follow along with the video, since it's really all about the framework process. There is also a handy link at the top to the Apple framework page.

AnotherJake Wrote:This page might be helpful. It's Cocoa oriented but I don't think you need any Cocoa skills to follow along with the video, since it's really all about the framework process. There is also a handy link at the top to the Apple framework page.

Hey thanks for that link! I'm pretty sure it's gonna prove useful. I know nothing about Cocoa, but it does seem like everything can be applied to other stuff too.

What version of Mac OS X was the video recorded on though? It looks a bit like Puma...

Jones Wrote:...What version of Mac OS X was the video recorded on though? It looks a bit like Puma...

I can't tell from the video but I think I found it back during 10.3.something and it matched the Xcode and interface I was using then as I recall. It'll prolly work the same now.

From the looks of it, it's definitely Panther. The interface elements aren't deeply shaded like in Puma and below, and on top of that, there aren't any pinstripes on the title bars or menu bar. Also, there isn't a spotlight menu, so it's not Tiger. (plus, AnotherJake said he found it during the days of Tiger)

akb825 Wrote:From the looks of it, it's definitely Panther. The interface elements aren't deeply shaded like in Puma and below, and on top of that, there aren't any pinstripes on the title bars or menu bar. Also, there isn't a spotlight menu, so it's not Tiger. (plus, AnotherJake said he found it during the days of Tiger)

10.3, is panther not tiger. And while it has no pinstripes in the window, it lacks the pinstripes in the menu bar also... then again, is it really important? (Funny me saying this, as I started this line of convo...)

I meant Panther, but typed Tiger. Oops.

Either way, I wanted to make that point so you know it's current, and will work with XCode.