Incorrect SDK version detection

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Change TOOLCHAIN_VERSION to 2.2
2. Run ./toolchain.sh headers with iPhone SDK 2.2

What is the expected output? 
SDK is version 2.2

What do you see instead?
SDK is version 2.2.1

What version of the product are you using? On what operating system?
Latest toolchain script on Ubuntu

Original issue reported on code.google.com by mnemonic...@gmail.com on 8 Feb 2009 at 3:34

[GoogleCodeExporter]

Aha, I'll bet that relates to the new rounding script. That CFBundleShortVersion
string is a tricky one.

Thanks for the report.

Original comment by m4d...@gmail.com on 8 Feb 2009 at 6:32

• Changed state: Accepted

[GoogleCodeExporter]

Perhaps you can add an if statement to define a new toolchain_version variable.

if CFBundleShortVersion == 2.2.0.9, then toolchain_version_new = 2.2.1, else
toolchain_version_new = toolchain_version

then use toolchain_version_new wherever it needs to be placed. simple and 
dirty. just
like all my little fixes. haha

Original comment by jtxdriggers on 8 Feb 2009 at 6:55

[GoogleCodeExporter]

jtxdriggers could by right. If we can't trust the apple CFBundleShortVersion it 
will
be easier to write a mapping function.

It won't be dirty if we have something like 
SDK_VERSION=`sdk_version_by_short_version
$CFBundleShortVersion`.

But I like the rounding function. Some months ago I didn't know that awk is a 
kind of
programming language. :)

Original comment by toeloo...@googlemail.com on 8 Feb 2009 at 10:04

[GoogleCodeExporter]

I didn't realize that both of CFBundleShortVersionString does have the same 
string in
version.plist.

So, I guess this will always produce the same SDK version for 2.2 and 2.2.1.

Maybe it could be solved by checking the BuildVersion and/or SourceVersion too ?

Original comment by mnemonic...@gmail.com on 9 Feb 2009 at 5:01

[GoogleCodeExporter]

Thanks for looking into that, I can see that there is very little difference in 
the
version numbering which possibly is a problem. I would like to avoid getting 
into
BuildVersion and SourceVersion because they're not generic enough and can't be
derived from the main version number, nor do they appear to be totally 
sequential. I
suppose we could probably map full version numbers to SourceVersion ones, but 
I'm
hoping to avoid that at this stage.

I am inclined to modify the version checking function and treat "2.2.1" and 
"2.2" as
equals, although this might get us into a mess later. Do note, however that in
switching to 2.2.1 I didn't make any changes apart from the version number,
everything else built the same. I'm going to try that first and we'll see how 
we go.

Original comment by m4d...@gmail.com on 9 Feb 2009 at 12:33

• Changed state: Started
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I've made the change in r68 of the unstable branch, can you verify if this 
fixes the
issue?

Original comment by m4d...@gmail.com on 9 Feb 2009 at 1:16

[GoogleCodeExporter]

It's fixed now, thanks

Original comment by mnemonic...@gmail.com on 9 Feb 2009 at 1:37

[GoogleCodeExporter]

Original comment by m4d...@gmail.com on 10 Feb 2009 at 10:59

• Changed state: Fixed

[GoogleCodeExporter]

I was far too hasty in closing this one, it's not fixed as of r69. Keep using 
68 at
this stage.

Original comment by m4d...@gmail.com on 10 Feb 2009 at 11:16

• Changed state: Started

[GoogleCodeExporter]

Okay so I've been looking into this and starting to wonder: should we even 
support
minor revisions like this one? Perhaps we should be sticking to 2.2 since 
pretty much
anything built for it is going to work on 2.2.1 unless there's a really specific
dependency on something that's changed, which seems very unlikely to me.

I'm considering that perhaps we should not support building specifically for
toolchain 2.2.1 and instead we should just look for the pkg file 
iPhoneSDK{target
version}.pkg in the dmg and skip the whole version detection using plists. This 
is
going to require a certain amount of reworking to the version logic but I think 
it's
the way to go.

What's the consensus on this?

Original comment by m4d...@gmail.com on 10 Feb 2009 at 11:53

[GoogleCodeExporter]

I've made the changes I described in comment 10 and they're now available at 
r70 in
the unstable branch. Can everyone please verify if this works for them? I'd 
like to
get this merged into the trunk soon since at this stage it's broken from the 
previous
version modifications.

Original comment by m4d...@gmail.com on 10 Feb 2009 at 2:04

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I would prefer the idea that, if we use a 2.2.1 firmware then we should use 
toolchain
2.2.1. So we could support the latest features in 2.2.1 firmware (if there's 
any). 

Though, as I examined the iPhone SDK image, the only thing that differentiate 
2.2.1
from 2.2 aside from the plist information (SourceVersion and BuildVersion) is 
the
original dmg filename.

Original comment by mnemonic...@gmail.com on 10 Feb 2009 at 2:09

[GoogleCodeExporter]

But, if that's too complex to do, by just supporting 2.2 would be fine. 

Original comment by mnemonic...@gmail.com on 10 Feb 2009 at 2:13

[GoogleCodeExporter]

Hi,

For the SDK named "iphone_sdk_for_iphone_os_2.2.19m2621afinal.dmg", the version
returned in the bundle is 2.2.0.9000000000, and the directory inside the mnt 
point
reads 2.2.1.

If we consider this as a RC-like versioning, the attached patch against r68 
could
make sense. Its purpose is to detect and rename x.y.z.900000...0 versions by
x.y.(z+1). With this patch, one may use TOOLCHAIN_VERSION="2.2.1" or still use 
the
current TOOLCHAIN_VERSION="2.2".

Any comments are welcome, especially considering the new policy introduced in
check_environment in r70.

Original comment by damien.c...@gmail.com on 10 Feb 2009 at 9:43

Attachments:

• toolchain-221vercheck.patch

[GoogleCodeExporter]

Thanks for the patch damien. We originally had a similar approach, but the 
problem is
that Apple hasn't changed the version number for 2.2.1 in the .plist files. For 
both
2.2 and 2.2.1, CFBundleShortVersionString is 2.2.0.9000000000. That means that 
a 2.2
SDK is treated as a 2.2.1 which is incorrect. Hence the current quick fix, which
doesn't allow building specifically for 2.2.1.

I think to satisfy everybody the best approach would be to change the way we 
detect
the version of the SDK. The most accurate way seems to be to inspect the xar 
Payload
of each .pkg file and look for a folder titled iPhone{version}.sdk. Perhaps to 
ensure
that the dmg provided meets a minimum standard we could compare the
CFBundleShortVersionString with the toolchain version but failure only produces 
a
warning message. This comparison could help guide the script for which Payload 
file
to search for the folder and I suppose from there it could simply search each 
Payload
until it finds the right folder.

The algorithm is something like:
Check plist CFBundleShortVersionString and compare such that 2.2 and 2.2.1 are
considered "equal" versions.
    a. If the result is that the SDK is newer than the toolchain version, look for
the appropriate version folder using the first two digits of the toolchain 
version
(ex: Toolchain is 2.0.1 and we're using SDK 2.2, look for iPhoneSDK2_0.pkg)
    b. If the result is that the SDK is older than the toolchain version, fail and
tell the user to upgrade their SDK.
    c. If the result is that both are equal versions, check for a package called
iPhoneSDK{first two digits of TOOLCHAIN_VERSION}.pkg. This will indicate 
whether the
SDK is for a .1 revision of the toolchain version (ex: 2.2.1) or is a full 
number
version (2.2). To clarify: SDK dmg 2.2.1 has a package for SDK 2.2 called
iPhoneSDK2_2.pkg and the 2.2.1 package is named iPhoneSDKHeadersAndLibs.pkg, 
while in
SDK 2.2 the package for 2.2 is named iPhoneSDKHeadersAndLibs.pkg

Using this method we can accurately detect the appropriate package for the 
toolchain,
as long as Apple continues on the same versioning scheme (i.e. the next release 
is
2.3, not 2.2.2). It's a bit nasty but as I see it it should work. Currently this
logic is partially implemented in r71, but 3-digit versions are still 
disallowed.

The alternative is to do as mnemonic.fx suggested and check the build version. 
This
is the most accurate method but it means we need to map build versions to 
revisions
using a list of some kind. This may be problematic since we have no way of 
predicting
future build numbers and thus can't produce a generic algorithm to detect the
appropriate package to use.

Original comment by m4d...@gmail.com on 11 Feb 2009 at 1:47

• Changed state: Started

[GoogleCodeExporter]

From my experience, the difference between the 2.2 and 2.2.1 firmwares are 
small, but
significant. When using the 2.2.1 SDK with the 2.2 firmware, cctools compiled 
fine,
but gcc failed to make. However, simply using the 2.2.1 firmware instead lead 
to an
extremely clean compile for both cctools and gcc.

A simple way to get the exact version number would be to just ask for the user's
input as soon as the user started toolchain.sh. User input is required for sudo 
and
logging in to the Apple dev site, as well as other small instances (like if 
certain
files exist, should they be recopied). Then read the version number from
version.plist, and if the version numbers are too dissimilar, then terminate 
the script.

Original comment by jtxdriggers on 11 Feb 2009 at 3:14

[GoogleCodeExporter]

Fix committed at unstable r72 and tested with toolchain and SDK combinations of
versions 2.2 and 2.2.1. Can everyone please confirm if they're happy with this 
so we
can try to merge across to the trunk?

Original comment by m4d...@gmail.com on 11 Feb 2009 at 11:45

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here it's 

http://developer.apple.com/documentation/developertools/conceptual/softwaredistr
ibution4/SoftwareDistribution4.pdf

It's old (about 2 years ago), but it does explain the way Apple's Installer 
interpret
versions from version.plist.

So it's using a 5-tuple version, which consist of:

CFBundleShortVersionString.SourceVersion.BuildVersion

Original comment by mnemonic...@gmail.com on 11 Feb 2009 at 6:59