Closed Bug 358390 Opened 18 years ago Closed 18 years ago

cannot build Camino with cairo gfx

Categories

(Camino Graveyard :: General, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jaas, Assigned: stuart.morgan+bugzilla)

Details

Attachments

(2 files)

Camino will not build with the cairo-cocoa toolkit.
Here is what I have done so far that has gotten me further along. 1. Build Camino with toolkit=cairo-cocoa and NO OBJDIR. If you build with an objdir, modifying the Xcode project will be much more difficult in later steps. 2. The build will fail. 3. Open the Xcode project, you'll probably have to upgrade it. Save an upgraded copy, it'll be named Camino.xcodeproj. Throw away the old Camino.xcode project and modify all instances of Camino.xcode in the camino makefile to say Camino.xcodeproj. We won't check this new project file in, just do it for the sake of getting this working. 4. In the copy files phases of the Xcode project, find where it copies libgfx_mac.dylib and delete that. Then also find fontEncoding.properties and delete that entry. Those don't exist under cairo apparently. 5. Now you need to add the new gfx library, libgkgfx.dylib to a copyphase. Find that in $topsrcdir/dist/Embed and add it to the appropriate copy phase. 6. Close the Xcode project 7. Do "make" in the "camino" directory and your build will succeed. Now Camino simply fails to launch, complaining that libwidget_mac.dylib is not a dylib. According to "otool" it is a mach-o bundle, not a dylib, but that seems to be what it always was. The problem is probably that something is linking against it now that wasn't before and dyld can't deal with it.
(In reply to comment #1) > 3. Open the Xcode project, you'll probably have to upgrade it. Save an upgraded > copy, it'll be named Camino.xcodeproj. Throw away the old Camino.xcode project > and modify all instances of Camino.xcode in the camino makefile to say > Camino.xcodeproj. An easier way of getting the same effect is to save the copy, move aside Camino.xcode, and rename Camino.xcodeproj to Camino.xcode.
Here's what the Xcode project needs to build non-static: - As josh mentioned, remove Gecko/Gecko Components/Components/libgfx_mac.dylib and Gecko/Gecko Res/fonts/fontEncoding.properties - Add Gecko/Gecko Components/Components/ (the file on disk is dist/bin/components/libgkgfxthebes.dylib). In the targets section, remove it from Camino/Copy Bundle Resources (where Xcode in all likelyhood will put it automagically) and add it to the Copy Files step near the top with (currently) 34 items that's full of other .dylib files. - Add Gecko/libthebes.dylib (the file on disk is dist/bin/libthebes.dylib). That should ultimately end up in the Camino/Link Binary With Libraries phase as well as the Copy Files (12) about half way down that has various .dylibs and libwidget.rsrc. Then in nsStaticComponents.cpp, |nsGfxMacModule| becomes |nsGfxModule|. One note: the vast majority of our .dylib files come from dist/Embed, not dist/bin. The fact that the things we need aren't available there feels like it may be a bug. I assume mento can clarify that. I'll try to play with static tonight and get instructions for that as well.
Sorry, the second step should say "Add Gecko/Gecko Components/Components/dist/bin/components/libgkgfxthebes.dylib"
Assignee: nobody → stuart.morgan
Attached patch fix (deleted) — Splinter Review
Static and non-static, tested both ways. The instructions above were a bit off, but this should be good to go.
Attachment #246513 - Flags: superreview?(mark)
I've disabled SVG in Camino's mozconfig until this lands, as SVG now has a hard dependency on cairo gfx (bug 354866).
Attachment #246513 - Flags: superreview?(mark) → superreview+
Since this will break all non-cairo builds as is, we'll need to land the toolkit switch to cairo at the same time (in /camino/config/mozconfig); that should probably have been in this patch, but isn't. I assume we'll need a clobber as well?
Our use of the Cocoa toolkit is currently specified in configure.in http://lxr.mozilla.org/mozilla/source/configure.in#4384 (where we override the Darwin platform default, which is now cairo-cocoa). Presumably we just need to remove that line instead of adding something to the mozconfig?
(In reply to comment #8) > Presumably we just need to remove that line instead of adding something to the mozconfig? Yeah, I was just discovering that an posting a correction.
Attachment #246691 - Flags: superreview?
Attachment #246691 - Flags: superreview? → review+
Landed (and re-enabled SVG to try to stop the burning). Everyone cross your fingers.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: