How to add library to XCode 3.0 project?

Discussion in 'Mac Programming' started by jdiamond, Dec 17, 2008.

  1. jdiamond macrumors 6502

    Dec 17, 2008
    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.
    - Jeff
  2. jdiamond thread starter macrumors 6502

    Dec 17, 2008
    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
  3. Soulstorm macrumors 68000


    Feb 1, 2005
    I had the same problem with you, but I solved it. I wrote an article in Project Soulstorm about this. Click here.
  4. jdiamond thread starter macrumors 6502

    Dec 17, 2008
    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.

    - Jeff
  5. jdiamond thread starter macrumors 6502

    Dec 17, 2008
    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
  6. wittegijt macrumors member

    Feb 18, 2007
    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.

  7. jdiamond thread starter macrumors 6502

    Dec 17, 2008
    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
  8. Soulstorm macrumors 68000


    Feb 1, 2005
    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 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?
  9. jzwolak macrumors newbie

    Jun 11, 2010
    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!
  10. gnasher729 macrumors P6


    Nov 25, 2005
    No need to use Terminal. In the Finder, press Command-Shift-G (Go To Folder in the Go menu), then enter /usr/lib.
  11. onenoc macrumors newbie

    Jan 14, 2012
    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.
  12. chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset
    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.

Share This Page