Closed Bug 717513 Opened 12 years ago Closed 9 days ago

Build fixes for 10.7

Categories

(Camino Graveyard :: General, defect)

1.9.2 Branch
x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: phiw2, Unassigned)

References

()

Details

Attachments

(3 files)

To build on 10.7, some changes to configure.in are needed, as it doesn't generate the required defines (egrep fails silently).

Mozilla central implemented those changes in bug 655339.
Comparison between config.status on 10.6 and 10.7. The bottom of the file shows the main issue.

The secondary issue is a failing in Xcode version detection.
Attached file patch for configure.in
this
* disables the Xcode version detection (suggested by smokey on IRC)
* ports the patch for bug 655339
Note you'll have to regenerate configure after applying this patch.

Bug 641232 was the bug about the Xcode version detection; they ended up ripping out that check (which is fine for the future in Gecko), but doing so touches a lot more than I'd rather us do here.
Striptease needs to be disabled in camino/makefile.in and camino/installer/makefile.in, even with the 10.4u.sdk, else the build goes down in flames.
(My original build attempts had it disabled, as I did on 10.6 with the 10.5sdk)
(In reply to philippe from comment #4)
> Striptease needs to be disabled in camino/makefile.in and
> camino/installer/makefile.in, even with the 10.4u.sdk, else the build goes
> down in flames.

Can you give me an error log for that sometime?  I'm (a little) surprised it fails with gcc 4.0 / 10.4 SDK only on 10.7 hosts.

Regarding http://wiki.caminobrowser.org/Development:Building:Mac_OS_X_10.7#Command_line_build_process

Have you tried specifying the full paths to gcc and g++ in the .mozconfig, rather than making the symlinks specified in that section?  Or is only specifying the C/C++ compiler paths not enough to build the Obj-C++ stuff in Gecko?
(In reply to Smokey Ardisson (not following bugs - do not email) from comment #6)
> (In reply to philippe from comment #4)
> > Striptease needs to be disabled in camino/makefile.in and
> > camino/installer/makefile.in, even with the 10.4u.sdk, else the build goes
> > down in flames.
> 
> Can you give me an error log for that sometime?  I'm (a little) surprised it
> fails with gcc 4.0 / 10.4 SDK only on 10.7 hosts.

Sure:
http://dev.l-c-n.com/camino/Lion/buildlog-10.7-striptease-fail.txt.zip

> 
> Regarding
> http://wiki.caminobrowser.org/Development:Building:Mac_OS_X_10.
> 7#Command_line_build_process
> 
> Have you tried specifying the full paths to gcc and g++ in the .mozconfig,
> rather than making the symlinks specified in that section?  Or is only
> specifying the C/C++ compiler paths not enough to build the Obj-C++ stuff in
> Gecko?

Not yet. But I plan to do so (for a first run, I preferred to have the whole set-up as close as possible to 10.6).
(In reply to philippe from comment #7)
> > Can you give me an error log for that sometime?  I'm (a little) surprised it
> > fails with gcc 4.0 / 10.4 SDK only on 10.7 hosts.
> 
> Sure:
> http://dev.l-c-n.com/camino/Lion/buildlog-10.7-striptease-fail.txt.zip

Ah; the first failure, at least, is a libstuff file looking for a system header that's gone on 10.7 (see bug 673789 for a similar problem with Breakpad), and apparently the SDK selection isn't getting passed into the striptease build.  That's, I think, because striptease is built as host program; I'd have to root around in the flag setup to be sure.

The other errors may follow from that; it's not clear at a glance, and I don't have time to dig around there right now.

We don't have a bug on striptease build failures (just bug 414397), but I know that we had to disable it in some conditions (gcc-4.2?) before.  We ought to just open a general bug on its failures and report all of the various configs we know to fail (with error logs, if we still have them).
(In reply to Smokey Ardisson (not following bugs - do not email) from comment #8)

> We don't have a bug on striptease build failures (just bug 414397), but I
> know that we had to disable it in some conditions (gcc-4.2?) before.  We
> ought to just open a general bug on its failures and report all of the
> various configs we know to fail (with error logs, if we still have them).

Striptease is now bug 718124.
A couple of notes, related to Xcode 4.3.x. The whole package is now an application (codesigned !), living in /Applications.
(everything untested so far)
* the symlink dance for the gcc4.0 compiler and the 10.4u.sdk should still work, with the caveat that it might break the codesigning
* building from within Xcode is probably broken, the Developer/Library/Xcode/PrivatePlugIns doesn't appear to exist anymore…
* the /path/to/sdk needs to be modified (possibly enough to change that in the .mozconfig). See core bug 734220.
path is /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
* Packaging is broken according to core bug 734629. /Developer/Tools is now /Applications/Xcode.app/Contents/Developer/Tools
(In reply to philippe from comment #10)

> * the /path/to/sdk needs to be modified (possibly enough to change that in
> the .mozconfig). See core bug 734220.
> path is
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/
> Developer/SDKs
> * Packaging is broken according to core bug 734629. /Developer/Tools is now
> /Applications/Xcode.app/Contents/Developer/Tools

You could probably also "fix" those with symlinks, if you're willing to have a dummy /Developer sitting around.
Status: NEW → RESOLVED
Closed: 9 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: