Use less embedded libraries on Ubuntu
darealshinji opened this issue · 12 comments
A safe way to compile xulrunner with less embedded libraries is to add these options:
--with-system-jpeg --with-system-zlib --with-system-bz2
Additional build-deps for the deps are libbz2-dev, libjpeg-turbo8-dev and zlib1g-dev. Additional build-dep for NG is libjpeg-turbo8.
The remaining embedded-library Lintian warnings are "sbDBEngine.so: sqlite", "libxul.so: libtheora", "libnss3.so: nss" and "libsqlite3.so: sqlite". The last two IMO can be overridden, since those are private dynamic libraries and not typical embedded libraries.
I wanted to point this out, it might be interresting for Launchpad releases. I don't know however if this makes sense for 12.04, as the system libraries there are probably older.
I'd doubt that ubuntu 12.04 has many older libs than what XULR 1.9 uses.
With the upgrade in process this won't even be a concern, other than perhaps sqlite?
We can't not use the embedded sqlite, even the ubuntu firefox package uses its own sqlite for xulr. All the others we should be able to use the systems counterpart, though at some point nss will be gone too (XULR 31)
Oh boy, that will be fun.
I agree that the last two should definitely be overriden. Those are built as part of XR, and I'd think any XR based application would have those. I'm not sure why libtheora is embedded in libxul.so though...
sbDBEngine.so is because of the incompatible system sqlite (this sqlite is different than the one embedded into libsqlite3.so actually).
One thing to note about libjpeg; in the xul-192-new branch, libjpeg7 is built externally from XR, so I'm not sure if any other dependencies rely on it. In the xul-9.0.1 branch, I upgraded libjpeg7 to libjpeg-turbo8, and I set it up to build with the libjpeg7 emulation ("--with-jpeg7") so it could just be a drop-in replacement. I'm not sure what, if anything, would need to be tweaked to use the system libjpeg-trubo8. I'd assume that if there's a compile time option to provide the libjpeg7 emulation, there might end up being some sort of ABI incompatibilities?
Edit:
It looks like gst-plugins-good may need libjpeg.
I'm using a XR build that is linked against system libjpeg-turbo8 and it seems to run fine.
I've added
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --with-system-bz2
to my lintian mozconfigs, and the build works just fine on 12.04 for me, thus I am going to commit that.
EDIT: commited as f9e3c40
I think we should also look into using the native NSS, as it is developed by mozilla. Well, was. I guess the main issues we could encounter would be big API changes. Further it seems that Nightingale does not link against NSS, so it's just XULR. Maybe the debian packaging lib-relinking thingeven links xulr agains the native libnss, so only the headers from the libnss in the source are used.
Configuring xulrunner with --disable-ogg will remove the embedded theora library.
Does 1.9 already have OGG playback? Isn't that for later on? (I guess libtheora means just that, though).
EDIT: I guess nsISound would use that. Does disabling ogg break that?
I can play ogg vorbis without problems on a build with --disable-ogg. The error console doesn't show anything unusual too.
Playing ogg with Nightingale should not be broken with this. nsISound is a component that is used by some extensions to play sounds, mostly notification sounds.
And I'd hope that disabling a component via flag would disable it so it doesn't produce any errors (unless ngale directly used that component, of course).