On Mon, 2008-11-03 at 16:54 +0000, Ken Moffat wrote:
> 1. libxul-embedding.pc needs -L${sdkdir}/sdk/lib to be able to find
> libxpcomglue which is a *static* lib (yeugh!) - used by yelp. I
> think there is similar breakage in other .pc files, but I don't
> have anything that uses them (and, $DEITY, what a mess! - stripped
> libs below xulrunner-1.9.0.3/ and unstripped below
> xulrunner-devel-1.9.0.3, a maze of stable and unstable files).
>
Interesting... I don't recall encountering anything like that. I've got
Yelp 2.24.0 built against Xulrunner without any patches or special
flags...> 2. I'm NOT using separate nss, nspr at the moment. Xulrunner puts > its own nspr libs into /usr/lib/xulrunner-1.9.0.3/ (without > unstripped copies in -devel- ) and even after heavy work on > mozilla-nspr.pc.in to actually point to these, they aren't found. > I've moved them to /usr/lib where I expected to find them, with > symlinks from where they were. I tried using the one in Xulrunner, and found the same problems you described. Then I tried a standalone version. The latter required a lot less messing around with .pc files - I'm pretty sure that the change to libxul-embedding.pc.in was the only thing that needed hacking. It's the only one I've put into my own build scripts, at least. One qualification, actually - my NSS/NSPR version is built according to the BLFS instructions (including the Fedora patch), but applied to a newer version. Nothing hacky, at least... > No patch for the moment, I've still got a lot more testing to do on > this! > > Commenting on the configure: > > > # Needed to make things using XUL find NSPR. > > echo "Requires: nspr" >> xulrunner/installer/libxul-embedding.pc.in > > > Not sure if this would help my use case - epiphany already pulls in > my mozilla-nss which requires nspr. But thanks for the detail, that > should help my testing! The problem here, from memory, was that either Yelp or Epiphany found Xulrunner, and assumed it provided NSS. I don't know whether they're at fault or whether Xulrunner is, but the above change was enough to make it work. > > ./configure --prefix=/usr --silent \ > No separate build directory ? As I said in the last email, I mostly grabbed the instructions from Slackware build scripts (apart from using the FF3 sources to build Xulrunner). This includes most of the configure flags, so while it's possible some of them are unnecessary, I've left them in for now. > > --enable-application=xulrunner \ > > --enable-system-cairo \ > > --enable-system-lcms \ > > --enable-strip \ > optional! Hmm, maybe my aversion to stripping things is why my '/' > is full :-( > > --enable-jemalloc \ > does this provide any benefits on non-windows platforms ? > > --enable-safe-browsing \ > > --enable-webservices \ > SOAP ? I guessed this was probably obsolete. No idea about those last two... I think I just copied them from Slackware... > > --disable-pedantic \ > > --disable-long-long-warning \ > I guess these two are for gcc-4.3. > > --disable-debug \ > > --disable-tests \ > > --disable-gnomevfs \ > > --disable-javaxpcom \ > > --disable-mochitest \ > > --disable-installer \ > > --disable-crashreporter \ > I don't use '--silent'; I got warning messages that this option is > not available for xulrunner Oh? Didn't notice it myself, but if it's not fatal, I might have overlooked it... > > --disable-updater \ > > --with-system-png \ > (needs libpng patched for apng) Yes, that's true. Someone was kind enough to post the patch on this list some months back, when FF3 first came out... I've been using it since. > > --with-system-zlib \ > > --with-system-jpeg \ > > --with-system-bz2 \ > > --with-system-nss \ > > --with-system-nspr > No --enable-optimize --enable-svg (dunno if the latter matters for > xulrunner, but it is accepted) ? Actually, my own build does include --enable-optimize, but I trimmed it to avoid anyone accidentally copying anything gcc-4.3 specific. As for --enable-svg, I think it's the default these days - certainly, I have SVG support on a Firefox built this way. > > I'm using --enable-system-sqlite because I loathe multiple static > builds of libraries, but I did have to create a .pc for libsqlite - > I've now found a fedora patch to look for a different sqlite header > which might serve the same purpose, but that .pc is easy enough to > create. Odd - I thought I was using a system SQLite, but looking at my scripts now, I don't see any sign of it. I'll have to correct that... As for the .pc file being missing, what version of SQLite are you using? I have 3.6.2 installed, and it provides an sqlite3.pc file already. > I also use --with-pthreads, but that only applies if you are > building nspr. > > I'm still using a .mozconfig (the mozilla site still says its the > preferred way to build), so I have to make -f client.mk build etc. As I said, I grabbed this out of the Slackware build, which used the autotools-style. Not sure why Mozilla favour one over the other, but the more conventional autotools approach fits in better with my build scripts, so I kept it... My main reason for looking at all this was wanting to build Gnome 2.24. I'd been running FF3 for a while out of a separate directory, with Gnome built against my old FF2 installation. On upgrading Gnome though, I wanted to get rid of FF2 completely, so did a bit of Googling that turned up the Slackware scripts mentioned earlier. Simon.
signature.asc
Description: This is a digitally signed message part
-- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
