10.6 SDk and 10.5 Deployment

  • Ok, so what is the real truth regarding using a base SDK of 10.6 and a deployment target of 10.5?

    The blogosphere says this cannot be done and Apple says it is OK.

    We have issues running a 10.6 SDK build on a 10.5.8 system.

    We have a certain percentage of customers who are on 10.5.8.

    Who should I believe? Apple or the blogosphere?

    -koko
  • On Jun 27, 2012, at 12:53 PM, koko wrote:

    > Ok, so what is the real truth regarding using a base SDK of 10.6 and a deployment target of 10.5?
    >
    > The blogosphere says this cannot be done and Apple says it is OK.
    >
    > We have issues running a 10.6 SDK build on a 10.5.8 system.
    >
    > We have a certain percentage of customers who are on 10.5.8.
    >
    > Who should I believe? Apple or the blogosphere?

    Rather than continue to ask in generalities, how about giving us some specifics?

    What problems are you experiencing, exactly? What claims have you seen others make asserting that your problems are insurmountable? What assurances from Apple are you questioning?

    --Kyle Sluder
  • Did this for years for a client -a few years ago- with no problems, though you don't mention what issues you have - which makes it impossible to help.

    So *obviously* it can be done - any problems kind of depends on what you're doing - which you don't mention.

    Rob

    On Jun 27, 2012, at 3:53 PM, koko wrote:

    > Ok, so what is the real truth regarding using a base SDK of 10.6 and a deployment target of 10.5?
    >
    > The blogosphere says this cannot be done and Apple says it is OK.
    >
    > We have issues running a 10.6 SDK build on a 10.5.8 system.
    >
    > We have a certain percentage of customers who are on 10.5.8.
    >
    > Who should I believe? Apple or the blogosphere?
    >
    > -koko
  • Point well taken.  As it turns out all issues were related to Xcode.

    -koko

    On Jun 27, 2012, at 2:03 PM, Kyle Sluder wrote:

    > On Jun 27, 2012, at 12:53 PM, koko wrote:
    >
    >> Ok, so what is the real truth regarding using a base SDK of 10.6 and a deployment target of 10.5?
    >>
    >> The blogosphere says this cannot be done and Apple says it is OK.
    >>
    >> We have issues running a 10.6 SDK build on a 10.5.8 system.
    >>
    >> We have a certain percentage of customers who are on 10.5.8.
    >>
    >> Who should I believe? Apple or the blogosphere?
    >
    > Rather than continue to ask in generalities, how about giving us some specifics?
    >
    > What problems are you experiencing, exactly? What claims have you seen others make asserting that your problems are insurmountable? What assurances from Apple are you questioning?
    >
    > --Kyle Sluder
  • On Jun 27, 2012, at 2:53 PM, koko wrote:

    > Ok, so what is the real truth regarding using a base SDK of 10.6 and a deployment target of 10.5?
    >
    > The blogosphere says this cannot be done and Apple says it is OK.
    >
    > We have issues running a 10.6 SDK build on a 10.5.8 system.
    >
    > We have a certain percentage of customers who are on 10.5.8.
    >
    > Who should I believe? Apple or the blogosphere?

    It can definitely be done in theory.

    In practice you have to test the heck out of it, because without the 10.5 SDK, there’s nothing keeping you from accidentally using 10.6+ APIs, whose effects will only show up by throwing runtime exceptions on 10.5.

    Charles
  • Whenever you support an earlier OS, you should always have that earliest and all intermediate SDKs available, and you should make it a standard practice to build your products against those SDKs at least before releasing to customers just as you do an analyzer build. This will help you identify many of the cases where you need to safeguard against the use of unavailable APIs, methods, and classes. Oh, and you really should be turning on and listening to practically every warning possible. Then, after you do all that, testing definitely should be done.
    --
    Gary L. Wade (Sent from my iPad)
    http://www.garywade.com/

    On Jun 28, 2012, at 8:13 AM, Charles Srstka <cocoadev...> wrote:

    > On Jun 27, 2012, at 2:53 PM, koko wrote:
    >
    >> Ok, so what is the real truth regarding using a base SDK of 10.6 and a deployment target of 10.5?
    >>
    >> The blogosphere says this cannot be done and Apple says it is OK.
    >>
    >> We have issues running a 10.6 SDK build on a 10.5.8 system.
    >>
    >> We have a certain percentage of customers who are on 10.5.8.
    >>
    >> Who should I believe? Apple or the blogosphere?
    >
    > It can definitely be done in theory.
    >
    > In practice you have to test the heck out of it, because without the 10.5 SDK, there’s nothing keeping you from accidentally using 10.6+ APIs, whose effects will only show up by throwing runtime exceptions on 10.5.
    >
    > Charles
  • On 6/28/12, Gary L. Wade <garywade...> wrote:
    > Whenever you support an earlier OS, you should always have that earliest and
    > all intermediate SDKs available, and you should make it a standard practice
    > to build your products against those SDKs at least before releasing to
    > customers just as you do an analyzer build. This will help you identify many
    > of the cases where you need to safeguard against the use of unavailable
    > APIs, methods, and classes. Oh, and you really should be turning on and
    > listening to practically every warning possible. Then, after you do all
    > that, testing definitely should be done.

    >> It can definitely be done in theory.
    >>
    >> In practice you have to test the heck out of it, because without the 10.5
    >> SDK, there’s nothing keeping you from accidentally using 10.6+ APIs, whose
    >> effects will only show up by throwing runtime exceptions on 10.5.
    >>

    One additional gotcha that I have hit multiple times is that if your
    application links to system .dylibs (not .frameworks), Xcode links to
    the explicit filename versioned .dylib file on your system that the
    generic one is symlinked to. This is a problem if say 10.6 has a newer
    version of libcrypto.dylib or libreadline.dylib which doesn't exist on
    10.5. Your app will crash on launch on 10.5 because it can't find the
    dependent library. For this, I have resorted to using
    install_name_tool to rewrite the dependencies to link to the generic
    symlinked version because Xcode has fought all my attempts to control
    what it actually links to.

    -Eric
    --
    Beginning iPhone Games Development
    http://playcontrol.net/iphonegamebook/
  • On Jun 28, 2012, at 1:58 PM, Eric Wing <ewmailing...> wrote:

    >
    > One additional gotcha that I have hit multiple times is that if your
    > application links to system .dylibs (not .frameworks), Xcode links to
    > the explicit filename versioned .dylib file on your system that the
    > generic one is symlinked to. This is a problem if say 10.6 has a newer
    > version of libcrypto.dylib or libreadline.dylib which doesn't exist on
    > 10.5. Your app will crash on launch on 10.5 because it can't find the
    > dependent library. For this, I have resorted to using
    > install_name_tool to rewrite the dependencies to link to the generic
    > symlinked version because Xcode has fought all my attempts to control
    > what it actually links to.

    Be careful! There could be binary incompatibilities between the two versions of the dylib—sometimes even between point revisions! We got bit by this in the 10.5->10.6 transition.

    --Kyle Sluder
  • On 6/28/12, Kyle Sluder <kyle...> wrote:
    > On Jun 28, 2012, at 1:58 PM, Eric Wing <ewmailing...> wrote:
    >
    >>
    >> One additional gotcha that I have hit multiple times is that if your
    >> application links to system .dylibs (not .frameworks), Xcode links to
    >> the explicit filename versioned .dylib file on your system that the
    >> generic one is symlinked to. This is a problem if say 10.6 has a newer
    >> version of libcrypto.dylib or libreadline.dylib which doesn't exist on
    >> 10.5. Your app will crash on launch on 10.5 because it can't find the
    >> dependent library. For this, I have resorted to using
    >> install_name_tool to rewrite the dependencies to link to the generic
    >> symlinked version because Xcode has fought all my attempts to control
    >> what it actually links to.
    >
    > Be careful! There could be binary incompatibilities between the two versions
    > of the dylib—sometimes even between point revisions! We got bit by this in
    > the 10.5->10.6 transition.
    >

    Yes, absolutely!

    -Eric
    --
    Beginning iPhone Games Development
    http://playcontrol.net/iphonegamebook/
  • On Jun 28, 2012, at 4:19 PM, Kyle Sluder wrote:

    > On Jun 28, 2012, at 1:58 PM, Eric Wing <ewmailing...> wrote:
    >
    >>
    >> One additional gotcha that I have hit multiple times is that if your
    >> application links to system .dylibs (not .frameworks), Xcode links to
    >> the explicit filename versioned .dylib file on your system that the
    >> generic one is symlinked to. This is a problem if say 10.6 has a newer
    >> version of libcrypto.dylib or libreadline.dylib which doesn't exist on
    >> 10.5. Your app will crash on launch on 10.5 because it can't find the
    >> dependent library. For this, I have resorted to using
    >> install_name_tool to rewrite the dependencies to link to the generic
    >> symlinked version because Xcode has fought all my attempts to control
    >> what it actually links to.
    >
    > Be careful! There could be binary incompatibilities between the two versions of the dylib—sometimes even between point revisions! We got bit by this in the 10.5->10.6 transition.

    My current solution to this is to stash a copy of the dylibs that I need for whatever OS in a folder somewhere, and then adding "-L/path/to/custom/dylibs/folder -lwhatever” to Other Linker Flags in the build settings, and leaving the dylib out of Xcode’s link phase.

    Charles
previous month june 2012 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
Go to today