title: Link static library inside dynamic (Cocoa Touch) framework
body: <p>I have a dynamic framework which links against Google Maps (which is, as far as I see it, still kind of a static library, if not exactly that, just with a framework wrapper).</p>
  
  <p>The problem is that the framework links against the static library and also seems to include its code directly, as I don't need to link or embed Google Maps in the app that uses the framework and everything works fine.
  Except if I work with Google Maps inside the app as well.</p>
  
  <p>Either I get "undefined symbols for architecture XY" during the compile phase, or I link Google Maps against it and then I get a wall of warnings in the debug-console during app-launch like:</p>
  
  <blockquote>
    <p>Class GMSPolyline2D is implemented in both
    /.../Build/Products/Debug-iphonesimulator/MyFramework.framework/MyFramework
    and
    /..../Bundle/Application/7C73324B-4A42-4063-98AA-879345997DE6/MyApp.app/MyApp.
    One of the two will be used. Which one is undefined.</p>
  </blockquote>
  
  <p>Is there any way to only link against Google Maps in the framework, but NOT to include the symbols in the framework-product as well? It works for dynamic frameworks, but static libraries seem to be just included. I already tried weak-linking with <code>-weak_framework</code> and <code>-weak_library</code>, but it does not seem to work.</p>
  
  <p>Actually, I could not make Xcode find the GoogleMaps binary for <code>-weak_library</code> inside its framework dir, even with directly linking inside the .framework folder as Library Search Path.</p>
  
  <p>Since I am the only user of my framework I can enforce that every app that uses the framework DOES include the Google Maps framework. So far the app works fine except the warnings (and so far it does not matter which of both classes is used at runtime, since both should be the same). However, I would sleep better if there was a nicer solution :)</p>
  
  <hr>
  
  <p>Edit: I could get -weak_library to work by just handing over the absolute path directly in the linker-flag section instead of using the <em>Library Search Path</em> setting. However, the problem still remains, obviously it is still included in the framework.</p>