Manually merged master-branch version of #190 #191
Conversation
|
I've now fixed a bug in 6ced858, fixed an unrelated bug in the build system, and added an xDS_Store file with the "master" version of the window parameters. In addition to the aforementioned fixes, I had to comment out four different pieces of signing-related code to get the "release" target to build without keys. For the changes, see the diff between my "master" branch and my "master-nosign" branch. Although it doesn't make sense to build a "real" release without signing, it ought to be possible to build the release target for testing without keys, or perhaps using TestKeys. |
|
The release target is not intended to be used by the general public. No one is stopping you to do so, of course, but as you noticed the build will fail. The release target requires you to have the private key for signing osxfuse updates, an Apple Developer ID Certificate for signing kernel extensions, and an Apple Developer ID Certificate for signing installer packages. I do not want to encourage people to distribute their own release builds, that "look" like official releases, therefore I am not going to remove those restrictions. For those who want to build osxfuse themselves for personal use the distribution target should be sufficient. The distribution target does not require any of the above certificates or keys and should therefore work for everyone. By default it will create an installer package that can be installed on the build machine's version of OS X. Calling it with the proper command line switches will add support for additional versions of OS X. As for the "compiler selection bug": I have run into issues with kernel extensions built for 10.6 using llvm-gcc in the past. Kernel extensions for 10.6 should be built with gcc 4.2 to be safe. Requiring gcc 4.2 is not a bug, but a deliberate choice. Xcode 4.0 to 4.2 are unsupported due to a bug in the included linker (see README.md for details) and Xcode 4.3 does not include gcc 4.2. This make Xcode 3.2.6 the latest supported version of Xcode for building osxfuse with support for 10.6. |
|
The key issue does, however, complicate testing of changes to release.sh. :-) If the compiler selection isn't a bug, then the Xcode selection is, because it currently uses Xcode 4.3 if present, and then fails building for 10.6 due to the missing compiler. The old build script lists Xcode 4.3 as the latest version for 10.6, which is precisely why I installed it. |
|
A lot has changed between osxfuse-2 and master. While you can technically build osxfuse-2 with Xcode 4.3 on 10.7 for 10.6 it might not be a good idea to do so. osxfuse 2.7.4 was built using Xcode 3.2.6 and 6.1.1. osxfuse 3 (master) will be built using Xcode 3.2.6, 4.6.3, and 6.1.1 (or 6.2). Everything else is basically untested, at least by me. |
|
Something that isn't a good idea shouldn't be the default choice just because a particular version of Xcode is present. :-) I used the table of Xcode versions and SDK versions in the osxfuse-2 build.sh as a guide for obtaining the latest available Xcode for each SDK (well, almost - I think 6.1.2 requires 10.10). While it probably makes sense to allow building with less desirable Xcode versions when more desirable versions aren't present, it certainly shouldn't prefer a less desirable version to a more desirable version that is present. So I guess the "latest Xcode for each SDK" rule that it follows is overly simplistic. BTW, you don't strictly need 10.7 to run 4.3.3. Although the 4.3.3 GUI doesn't work on 10.9, the command-line tools do. Here, on 10.9, I have: Installed Xcode versions: 3.1.4, 3.2.6, 4.3.3, 6.1.1, 5.1.1, 4.6.3 For test purposes, it would be useful to have an option to exclude specific Xcode versions, but ordinary users shouldn't have to use that option just to get a working build. |
The present setup uses Finder to set up the window parameters for the install image. This is undesirable for multiple reasons, and need not be repeated on every build when the window parameters haven't changed. With this change, the .DS_Store file (containing the window settings) is captured and used for subsequent builds. The intent is that a "vetted" copy can be checked into the repository, with no further need to use Finder in the build until some change is made to the parameters (at which point the saved version can be deleted to cause it to be recomputed). This commit does not include the .DS_Store copy (xDS_Store), which belongs in a separate commit. It does include the binary attribute for xDS_Store.
The 10.5 version of "cp" doesn't support the "-a" option, though it's just a shorthand for "-pPR", so it's easily fixed.
|
Are the "issues with kernel extensions built for 10.6 using llvm-gcc" something subtle? I tried my build on 10.6, and it passed a simple "smoke test" with sshfs, though of course that's not a thorough test. This was built with the Xcode 4.3.3 version of llvm-gcc-4.2, which might not be identical to the one in Xcode 3.2.6, in spite of the version match. I have a cleaned up version of this branch, which I'll push if you haven't done anything with it yet, but it does "rewrite history", and hence isn't guaranteed safe for something "published". |
|
I just force-pushed the updated branch, replacing the previous 6 commits with 4 new ones. I left out the "compiler selection fix", though there's still an issue there. |
|
I spend some time looking into llvm-gcc situation for Mac OS X 10.6 builds: Kexts including ppc code and built with llvm-gcc fail to load on Mac OS X 10.5. This is the reason I switched from llvm-gcc to gcc-4.2 for Xcode 3.2.6 in 2011. The old build script did not support specifying different compilers for the Mac OS X 10.5 and 10.6 SDKs. After the switch I noticed that a deadlock under heavy load on 10.6 had disappeared, too. I do not recall specifics. I cannot be sure but I think this might have been a bug in the osxfuse locking code. I ran some tests with an llvm-gcc version of osxfuse and could not find any issues on 10.6. So I think we should give llvm-gcc another try on 10.6. |
|
Thanks again for your work. |
|
I've now determined conclusively that the same nominal compiler version can produce different results as a function of which Xcode version it came from, so if this sort of thing is an issue, it really needs to tie to the combination of Xcode version and compiler version, rather than expecting the compiler version alone to uniquely determine the behavior. It's also worth keeping in mind that there's at least one known issue with the system you use to build releases, causing the broken ppc64 builds (which I can't reproduce here). Although the current Band-Aid fix (removing 64-bit content from the support tools) is a perfectly acceptable workaround, it is still just a Band-Aid over some unidentified build problem. |
This manually merges the first two commits from #190, adjusting for the file reorganization. See the comments there for details.
I have not tested this version of those commits, due to multiple issues preventing my building the release target on my system (having nothing to do with these changes).
For this reason (and the fact that the changed window parameters prevent merely copying the file from the osxfuse-2 branch), there's no commit with an initial xDS_Store file included.