macOS How to add library to XCode 3.0 project?

[jdiamond]

This sounds so basic, but I am trying to add a library to my XCode 3.0 project so it will link. (It happens to be a dynamic library.) I have not found any line in the project settings/options that pertain directly to libraries, nor any menu option to "add library". When I tried to add -L... -l... as compile or linker flags as if I were doing a gcc command line compile with a library, it did not complain, but also did not link against the library. This may be complicated because it is a shared library, so in principle XCode should not attempt to resolve the library functions until run time, but I don't know how to tell XCode this...

On numerous other threads, it is implied that you simply drag a library file to your project to add it (although this may only applicable to static libraries). This makes sense, except for one catch: The libraries I'm interested in are in /usr/lib, one of the directories that is invisible to the OS-X Gui. Which means I can't get to it in Finder, spotlight, or Open dialogues, so I can't drag the files in. (BTW, this has been a major pet peeve of mine - does anyone know how to give the OS-X GUI permission to see the entire file system?)

For reference, in this case I'm trying to add in the mpi and pthread libraries, and to date I've only seen posts about doing this with gcc directly, not with XCode. It looks like XCode 3.1 has an actual option pane for adding libraries, but as I'm not developing for the iPhone, I don't really want to go there yet.

Any help is greatly appreciated.
Thanks,
- Jeff

 

[jdiamond]

Quick Addendum...

Just to clarify, I know it doesn't make sense to "link against" a dynamic library, and I realize that static libraries might be treated entirely differently by XCode, but I'd like to be able to add in both shared and static libraries to a project.

I am fairly new to XCode, but I was really shocked to see that it overloads you with every conceivable tuning option, while making it really hard to figure out how to do the most fundamental things, e.g., defining project constants, specifying libraries, etc.

Thanks all for your help.
- Jeff

 

[Soulstorm]

I had the same problem with you, but I solved it. I wrote an article in Project Soulstorm about this. Click here.

 

[jdiamond]

Got a little further, but still can't select from /usr...

Thanks so much for your help! Thanks to your link, I found that if you expand an individual target under the Targets list in the project, you see a folder called "Link Binary With Libraries", which you can right click on and then choose "add existing file."

But there's still one catch:

"Firstly, locate the .dylib files for that Library. The files for PCRE are located inside sw/lib/ and are called libpcre.a and libpcrecpp.a (they are the same with .dylib files). Drag those two to your project. You can copy the files to your project, or you can leave it alone, in case you need to update it afterwards.

Great, now you did that, and the file is included in your project..."

I still can't do that, because I'm trying to use standard (native) libraries in /usr/lib. And that's one of the directories you can't access from an open dialog or Finder, so I can't select the dylib or drag it in.

In principle, I could go into the shell and pseudo copy the standard libraries into a folder I can access with the GUI, but that just seems so wrong to have to do.

Does anyone know how to modify the OS-X Gui setting to allow them to see key system directories? Note that this is not the same as a "hidden" directory - these directories are not hidden - they are just somehow tagged as "inaccessible" via the GUI.

Thanks,
- Jeff

 

[jdiamond]

Worked after moving all the standard libraries!

I finally put my aesthetics aside out of necessity and copied /usr/lib to /lib so that the OS-X GUI could see them, and then the procedure you showed me worked!!! I right clicked and added the shared libraries to XCode, and XCode did the rest.

So now my only issue is making it so the OS-X GUI can see system directories. Do you folks think I should make this a new thread?

Thanks for all your help,
- Jeff

 

[wittegijt]

I think you should link to the libraries in /Developer/SDKs/, so that you can choose which version you want to link against (10.4 or 10.5). Copying files in system directories is never a good idea.

Wittegijt

 

[jdiamond]

That's a great tip!

Thanks - the GUI can access /Developer/SDKs/MacOSX10*/usr/lib, and it does seem like this is more appropriate than going for my own /usr/lib.

Also, this may seem small and obvious, but I just found that once in the build tab of the target info, there is a search box that lets you filter your options - that helps a lot.

And a general thanks to this Forum! I am so impressed at how fast people responded and how kind and helpful everyone is. It's always difficult being the only local person I know using XCode.

- Jeff

 

[Soulstorm]

I finally put my aesthetics aside out of necessity and copied /usr/lib to /lib so that the OS-X GUI could see them, and then the procedure you showed me worked!!! I right clicked and added the shared libraries to XCode, and XCode did the rest.

So now my only issue is making it so the OS-X GUI can see system directories. Do you folks think I should make this a new thread?

Thanks for all your help,
- Jeff

Never, never, never, copy entire folders from system files into other places. usr/ is located there for a reason. It's because when you try to install anything else than pre-installed libraries, like the Boost library, it will be installed into usr/ . In order to find invisible files in the finder and make it visible, you can download the Invisibles.app. I use it all the time, and it's free.

usr/lib exists for a reason. And that reason is because it's a UNIX way of handling things. It may sound weird to you, but you should get a book or two concerning UNIX, since it will show you things like dynamic library linking, standard locations of binaries, libraries and files, etc.

Dynamic Libraries have always been a pain in the butt for me and almost anyone I know. I suppose you already know the problems with dylibs if you intend to use them:

• dylibs don't keep individual data points.
• Headers are in separate place from the libraries themselves.
• You can't have a dylib that holds resources such as images etc.

For that reason, I prefer .framework files. You can make .frameworks from dylibs, and the way to do that, is the tutorial I gave you above.

Just out of curiosity, what library are you trying to use that doesn't work? Is it a standard Library?

 

[jzwolak]

open /usr/lib

I had this problem and solved it by running the following command in the Terminal app:

open /usr/lib​

Finder then gladly shows a window with the contents of /usr/lib, and you can drag libraries into Xcode!! Yay!

 

[gnasher729]

I had this problem and solved it by running the following command in the Terminal app:

open /usr/lib​

Finder then gladly shows a window with the contents of /usr/lib, and you can drag libraries into Xcode!! Yay!

No need to use Terminal. In the Finder, press Command-Shift-G (Go To Folder in the Go menu), then enter /usr/lib.

 

[onenoc]

So I'm doing something in Xcode 4.2 in C++ and had the error "genlib.h file not found" when I tried compiling a program. I then added the file to /usr/lib/C++, but am still getting the same error.

 

[chown33]

So I'm doing something in Xcode 4.2 in C++ and had the error "genlib.h file not found" when I tried compiling a program. I then added the file to /usr/lib/C++, but am still getting the same error.

As a rule, header files don't belong in a /usr/lib directory.

It's unclear from your brief description what would be the most suitable place for the header. The last place I'd recommend would be under /usr/include. Better options would be under /usr/local, creating /usr/local if needed, or creating a suitable place for your shared libraries and headers under, say, /Users/Shared. Wherever you put it, you'll still need to add that directory to the list of locations that Xcode searches for included header files.

The reason for avoiding /usr/include is because that's where Apple-provided system files reside. If you conflict with something in there, you'll be seeing unexpected problems later, if not sooner.