OpenGL Image Textures

You should google around for the basics on static libraries, what it means to link against them, etc. I don't know if Apple's docs cover all this as regards Xcode, but it wouldn't hurt to search int hat context as well.

It seems to me that you're just not getting something here, and as AnotherJake says, this is about the easiest thing in the world. At least if you're using C and C-derived languages for OpenGL.

One other thing you might try would be to drop static libs all together and just bring the SOIL code into your project.

I am sure your lib, demo and instructions are great. Beginners will still find the most surprising ways to do things in ways you didn't anticipate (but less often if it is done well). And they are not stupid, they just havn't been there before. There's nothing better than a simple demo, especially to show how to use a library (I wish Apple would learn that), but the beginners still have to hack it, put it into their own environment, and mess it up.

Now, speaking of harder: Using libpng is harder since there are at least three totally different ways to do it, more ways to go wrong, several ways that need to be learned. In the case of SOIL, I suppose it is "local copy" only, but that isn't true in general for libpng. If I don't pick one way and stick to it, I may end up with libpng installed in lots of places on my drive. This isn't only a question for libpng but of more general nature. How are third-party libraries best handled? Unix-style, local, or framework? I may note that the "local copy" version is likely to be the one you will find first, which makes the choice harder.

And I havn't even mentioned dynamic libraries... Yes I have, since a framework is just that. Confusing for beginners? Absolutely.

I'm a strong advocate of the local copy approach, for simple reasons of good configuration management. If all of the libraries you use are contained within your project, you can check it out onto any computer with developer tools installed and be able to build it out-of-the-box. It becomes an absolute nightmare to manage the building of a project that requires libraries to be installed - what if, for example, you need to build two such projects on the same computer, but they require different and conflicting versions of the same library?

Dynamic libraries are also something I tend to avoid, but they certainly have their place...

Ingemar Wrote:Is your conclusion that you prefer the local copy approach?

Yes, I tend to prefer local copies. I don't tend to use many external libraries in the first place, and the ones I do tend to be very small (less than 100 KB to maybe a few MB for the most complex). SOIL would be a great prototypical example of a library I would approve of using. Although, I will use larger libraries if they are really necessary.

Often times when I am developing my own static libs I will keep them in a central location in my dev folder until I get enough kinks worked out.

I tend to avoid dynamic linked libraries, except for a few. One dynamically linked library I happen to use is my own windowing framework, so that it's simpler to package up nib files and support assets like control widgets and so on... And even that I am considering ditching dynamic and going static. I agree that dynamic libraries are a pain in the butt for sure, and certainly easier to confuse beginners with.

The libSOIL.a that is in the project is still bogus. Are you sure you made a new one and replaced the old one in your project? Throw the one that's in your project in the trash so it doesn't get mistaken for a good one. I tried it with mine and your project works just fine. If you still can't get the right one built, I'll email you my libSOIL.

I made a few adjustments for you, including normals and enabling/disabling texturing as needed. Here's the code: