> On Dec 29, 2014, at 10:47 PM, Philip Chimento <philip chimento gmail com> wrote:
>
>
> webkit1gtk3 and webkit2gtk3 definitely won't work in that pull request; that's just what I renamed the svn and git versions to. In retrospect I'm not sure that's a great idea especially for webkit1gtk3, because 2.4.x won't build without a bunch of patches.
So maybe I should just delete those two modules and push the rest. It’s all about getting 1.10 going in modulesets-stable, right?
Sure, I was going to keep those two modules in the hope of getting them to build, but perhaps given how often WebKitGTK won't build on OSX, we'd be better off always building from tarballs so we can patch them.
For the brave souls we could include a WebKit-svn or WebKit-git module on modulesets-unstable.
> I was trying webkit2gtk3 today on stable and it looks like they removed support for the Quartz target from the cmake build system. Uh oh.
That’s been a problem all along, ever since I first submitted patches for Quartz back on 1.2. Not only were the patches rejected, but they changed the Makefiles so that Mac and X11 were synonymous. Not too hard to patch around, but annoying none the less. Is this similarly patchable or are we stuck at 1.10?
Well, I've at least gotten 2.4.7 (webkit1gtk3) to build, so we're not stuck at 1.10. 2.4.7 is the last Autotools release, though they are still cutting security releases from that branch.
I'm trying to build 2.6.4 (webkit2gtk3) from a tarball now. The cmake files were easy enough to patch. I'm hoping that they didn't remove the Quartz target from the code altogether, just never got around to enabling it in the new build system.
On Tue, Dec 30, 2014 at 11:41 AM, John Ralls <jralls ceridwen us> wrote:
> On Dec 29, 2014, at 5:01 PM, John Ralls <jralls ceridwen us> wrote: > > Didn’t build webkit2gtk3, though. Didn’t even start, because WebKitGtk seems to have dumped autotools in favor of cmake. That was a git build. I’ll try a stable version next.
Stable fails with -arch i386:
> ld: warning: ignoring file Source/_javascript_Core/llint/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.o, file was built for unsupported file format ( 0xCF 0xFA 0xED 0xFE 0x07 0x00 0x00 0x01 0x03 0x00 0x00 0x00 0x01 0x00 0x00 0x00 ) which is not the architecture being linked (i386): Source/_javascript_Core/llint/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.o > ld: warning: ignoring file ./.libs/libWTF.a, file was built for archive which is not the architecture being linked (i386): ./.libs/libWTF.a > Undefined symbols for architecture i386: > "_main", referenced from: > implicit entry/start for main executable > ld: symbol(s) not found for architecture i386 > clang: error: linker command failed with exit code 1 (use -v to see invocation)
I guess configure ignores the passed-in C.*FLAGS and deduces its own. Rude, but fixable.
Which version are you building? If it's a cmake version, apparently you have to specify them at cmake time, not as makeargs.
