• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: Debug/Release Library Matching
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Debug/Release Library Matching


  • Subject: RE: Debug/Release Library Matching
  • From: "David Litwin" <email@hidden>
  • Date: Mon, 10 Oct 2005 18:35:06 -0700

I asked this a few weeks back but never got an answer.  To rephrase it:

 

How do I build a Debug and Release version of a dynamic library, and have my app’s Debug and Release configurations link against the proper version.


When I try adding the dynamic lib from the sub-project disclosure (like static libraries) it seems to disregard the source and generate a path to the app build destination.

 

My current work around is to just always link both the Release and Debug app against the Release version of the dynamic lib by dragging the actual build target from the file system into the app’s Frameworks and External Libraries area.

It happens that there are no extra interfaces exported in the Debug dynamic lib so I can get away with this, but it isn’t the preferred solution for a number of reasons the foremost being that the Debug won’t cause the Release dynamic lib to be built (just the debug) so building takes almost twice as long and can’t be a one step process.


David Litwin

 


This works well for static libraries (why isn’t it in the user’s guide?) but not for dynamic libs.  When I do this with my dynamic libs it issues a fullpath on the link line, and the path it gives the dynamic lib is that of my build product, not the path where the lib is built.

 

David Litwin

 

Chris Espinosa writes:

The best way to do this is to use a shared build folder between the project that builds the static library and the project that builds its clients. Both projects should have Debug and Release configurations (the names are arbitrary, but should be the same in each project).

When you build the static library's Debug configuration, it will build into $(SYMROOT)/Debug/mylib.a, and when you build Release, it will build into $(SYMROOT)/Release/mylib.a. Note that the library names are the same but they're in per-configuration directories, much like CodeWarior puts per-target intermediates into per-target directories.

Then drag the static library project and drop it into your app project. When you disclose it, it will show that it builds foo.a. Drag that into the Link Binaries with Libraries build phase of your target.

Then when you build the Debug configuration of your app, it will use the Debug build folder, and automatically pick up the Debug static library, and the same for the Release configuration.

If you really want the files in the same place and named differently, then you have to use separate targets for your Debug and Release versions of your app (and probably use just one configuration). Add the mylib_d.a static library to the Debug target and the mylib.a static library to the Release target, just like in CodeWarrior.

Chris

 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Prev by Date: Failed to load debugging library
  • Next by Date: Re: Incompatibilities between home-compiled and apple's libpng
  • Previous by thread: Failed to load debugging library
  • Next by thread: creating a package in xcode 1.5 with an alternative 'stub' app for 10.1 and 10.2
  • Index(es):
    • Date
    • Thread