Hello Everyone, I'm trying to upgrade to Gnome 2.22 it was recently put on the Gnome repo the past few days. I struggled with lots of packages failing and have fixed most of my issues however When I try to update Yelp it complains with the following error message. /usr/bin/ld: cannot find -lgtkembedmoz collect2: ld returned 1 exit status make[3]: *** [yelp] Error 1 make[3]: Leaving directory `/usr/ports/gnome/yelp/work/src/yelp-2.22.0/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/ports/gnome/yelp/work/src/yelp-2.22.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/ports/gnome/yelp/work/src/yelp-2.22.0' make: *** [all] Error 2 =======> ERROR: Building '/usr/ports/gnome/yelp/yelp#2.22.0-1.pkg.tar.gz' failed. -- Packages where update failed/usr/bin/ld: cannot find -lgtkembedmoz collect2: ld returned 1 exit status make[3]: *** [yelp] Error 1 make[3]: Leaving directory `/usr/ports/gnome/yelp/work/src/yelp-2.22.0/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/ports/gnome/yelp/work/src/yelp-2.22.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/ports/gnome/yelp/work/src/yelp-2.22.0' make: *** [all] Error 2 =======> ERROR: Buildinglgtkembedmoz '/usr/ports/gnome/yelp/yelp#2.22.0-1.pkg.tar.gz' faillgtkembedmozed. -- Packages where update failed yelp yelp I'm pretty sure lgtkembedmoz is part of mozilla-runtime but there isn't any mozilla-dev or mozilla packages on any of the repos I have and I already have firefox. I've also tried compiling xulrunner with no suscess compiling xulrunner. Any assistance with finding a fix for this would be greatly helpful. Thanks, Brian Madonna
On Sun, 30 Mar 2008 22:02:43 -0400 Brian Madonna wrote: <libgtkembedmoz.so missing>
I'm pretty sure lgtkembedmoz is part of mozilla-runtime but there isn't any mozilla-dev or mozilla packages on any of the repos I have and I already have firefox. I've also tried compiling xulrunner with no suscess compiling xulrunner. Any assistance with finding a fix for this would be greatly helpful.
Brett made several improvements to how Firefox is build, starting with this version. Quote from that mail (http://lists.crux.nu/pipermail/crux/2008-March/008153.html): "It links all of Firefox's internal libraries and extensions statically, into the main binary. This reduces disk space consumption, improves start-time performance and doesn't break any applications that build against Firefox. Mozilla's own binary builds are built this way, in fact." As you can here in a git tree for opt (http://tinyurl.com/2md7or), libgtkembedmoz.so was part of the FF build, if I'm reading that diff corectly. Since xulrunner also provides libgtkembedmoz.so, you could use that.It builds just fine here, and I used Mike's port (http://crux.nu/portdb/?q=xul&a=search). HTH Pedja -- 'Vegetarian' -- it's an old Indian word meaning 'lousy hunter'. - Red Green
Hello, Predrag. On Mon, 31 Mar 2008 16:10:28 +0200 Predrag Ivanovic <predivan@nadlanu.com> wrote:
[...] As you can here in a git tree for opt (http://tinyurl.com/2md7or), libgtkembedmoz.so was part of the FF build, if I'm reading that diff corectly. Since xulrunner also provides libgtkembedmoz.so, you could use that.It builds just fine here, and I used Mike's port (http://crux.nu/portdb/?q=xul&a=search). Be aware that my port provides a binary version of xulrunner. I was not able to build it (or to find recent sources) at that time. I am using it just to make beta version of rssowl-2.0 happy.
-- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta
On Tue, 01 Apr 2008 10:19:44 +0300 Mikhail Kolesnik wrote:
Hello, Predrag. Hi, Mikhail.
[...] As you can here in a git tree for opt (http://tinyurl.com/2md7or), libgtkembedmoz.so was part of the FF build, if I'm reading that diff corectly. Since xulrunner also provides libgtkembedmoz.so, you could use that.It builds just fine here, and I used Mike's port (http://crux.nu/portdb/?q=xul&a=search). Be aware that my port provides a binary version of xulrunner. I was not able to build it (or to find recent sources) at that time. I forgot to mention that it's binary version, sorry.AFAICT, Gentoo has both xulrunner and xulrunner-bin in Portage or whatever that thing they use is called.If you look at dependencies for building it, it's easy to understand why...
I am using it just to make beta version of rssowl-2.0 happy. That's was my idea, maybe he can use your port of xulrunner-bin to satisfy yelp's dependency on firefox.Or he can dig up port for previous version of FF, update the version, and build it like it was built before.It would be bloated, granted, but at least Yelp would build.
Pedja -- "People are more violently opposed to fur than leather, because it is far more easier to harass old ladies in fur,than motorcycle gangs in leather..."
On Tue, 01 Apr 2008 12:49:18 +0200 Predrag Ivanovic wrote:
[...].Or he can dig up port for previous version of FF, update the version, and build it like it was built before.It would be bloated, granted, but at least Yelp would build.
This is a snapshot of Firefox port from opt just before update to 2.0.0.13: http://crux.nu/gitweb/?p=ports/opt.git;a=snapshot;h=f02496a0ddf3a029e8322e7e... Pedja -- The Roman Rule: The one who says it cannot be done should never interrupt the one who is doing it.
On Tue, 1 Apr 2008 13:16:53 +0200 Predrag Ivanovic wrote:
On Tue, 01 Apr 2008 12:49:18 +0200 Predrag Ivanovic wrote:
[...].Or he can dig up port for previous version of FF, update the version, and build it like it was built before.It would be bloated, granted, but at least Yelp would build.
This is a snapshot of Firefox port from opt just before update to 2.0.0.13: http://crux.nu/gitweb/?p=ports/opt.git;a=snapshot;h=f02496a0ddf3a029e8322e7e...
Pedja
I'm going to discuss potential solutions to this problem with Matt at the next chance I get, which are producing a proper xulrunner 1.8 port for either opt or the GNOME repo, reverting Firefox to building dynamically instead of statically in opt or a dynamically-linked version of Firefox for the GNOME repo. When Firefox 3.0 is released, xulrunner will become the Firefox backend, alleviating problems like this once and for all, as programs will build against xulrunner, not Firefox. -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
When Firefox 3.0 is released, xulrunner will become the Firefox backend, alleviating problems like this once and for all, as programs will build against xulrunner, not Firefox.
One of us is looking at outdated information. According to Ben Smedberg, the XULRunner maintainer, Firefox will not ship with a system-wide XULRunner. http://benjamin.smedbergs.us/blog/2007-05-15/xulrunner-what-we-are-doing/ I'm actually not convinced we save much by disabling shared libraries. (Although I certainly appreciate the effort. I've done several by-hand builds of the Mozilla codebase, and it's not a simple thing by any means.) Will _________________________________________________________________ Pack up or back up–use SkyDrive to transfer files or keep extra copies. Learn how. hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_...
On Tue, 1 Apr 2008 07:17:35 -0500 William Lewis wrote:
When Firefox 3.0 is released, xulrunner will become the Firefox backend, alleviating problems like this once and for all, as programs will build against xulrunner, not Firefox.
One of us is looking at outdated information. According to Ben Smedberg, the XULRunner maintainer, Firefox will not ship with a system-wide XULRunner. http://benjamin.smedbergs.us/blog/2007-05-15/xulrunner-what-we-are-doing/ I'm actually not convinced we save much by disabling shared libraries. (Although I certainly appreciate the effort. I've done several by-hand builds of the Mozilla codebase, and it's not a simple thing by any means.)
We're both right. Their official builds will stay much the same, all the underlying groundwork for xulrunner is already present in Firefox 3.0 beta* and will be present in the official release. The CRUX packages will work with xulrunner as the backend, unlike upstream Mozilla. This is how my current firefox 3 repo works and how I intend to push it to opt when Firefox 3.0 is finalised.
Will
_________________________________________________________________ Pack up or back up–use SkyDrive to transfer files or keep extra copies. Learn how. hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_...
-- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
We're both right. Their official builds will stay much the same, all the underlying groundwork for xulrunner is already present in Firefox 3.0 beta* and will be present in the official release.
The CRUX packages will work with xulrunner as the backend, unlike upstream Mozilla. This is how my current firefox 3 repo works and how I intend to push it to opt when Firefox 3.0 is finalised.
If I understand it correctly, in the 2.0.0.x branches of both Firefox and Thunderbird, each package compiles and installs its own copies of all the Mozilla-specific stuff, e.g. NSPR, XPCOM, libxul, etc. So the benefit of the new system is to minimize compile time and compile frequency for updates to the engine. In other words, if there's a security bug in Mozilla's JavaScript handling, then one update (to XULRunner) is all that is needed. That way, both Firefox and Thunderbird (and whatever else, e.g. Songbird) reap the benefits. We also go from multiple copies of the installed libraries to a single copy. Is all this correct? Also, earlier on the list, you described the build as disabling the dynamic libraries, IIRC. So what am I missing? Doesn't XULRunner need to be compiled with dynamic libs to be leveraged by Firefox and Thunderbird? Thanks in advance, Will _________________________________________________________________ Pack up or back up–use SkyDrive to transfer files or keep extra copies. Learn how. hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_...
On Tue, 1 Apr 2008 11:26:38 -0500 William Lewis wrote:
We're both right. Their official builds will stay much the same, all the underlying groundwork for xulrunner is already present in Firefox 3.0 beta* and will be present in the official release.
The CRUX packages will work with xulrunner as the backend, unlike upstream Mozilla. This is how my current firefox 3 repo works and how I intend to push it to opt when Firefox 3.0 is finalised.
If I understand it correctly, in the 2.0.0.x branches of both Firefox and Thunderbird, each package compiles and installs its own copies of all the Mozilla-specific stuff, e.g. NSPR, XPCOM, libxul, etc. So the benefit of the new system is to minimize compile time and compile frequency for updates to the engine. In other words, if there's a security bug in Mozilla's JavaScript handling, then one update (to XULRunner) is all that is needed. That way, both Firefox and Thunderbird (and whatever else, e.g. Songbird) reap the benefits. We also go from multiple copies of the installed libraries to a single copy. Is all this correct?
Also, earlier on the list, you described the build as disabling the dynamic libraries, IIRC. So what am I missing? Doesn't XULRunner need to be compiled with dynamic libs to be leveraged by Firefox and Thunderbird?
Yes, that's correct, although the Firefox 2.0.0.X in opt now builds against system nss/nspr, to minimise wasted space. I disabled the dynamic libraries (excluding what Firefox forces dynamic) for Firefox only, xulrunner, being an actual generic platform for other applications, should be built dynamic and is.
Thanks in advance, Will
_________________________________________________________________ Pack up or back up–use SkyDrive to transfer files or keep extra copies. Learn how. hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_...
-- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
participants (5)
-
Brett Goulder -
Brian Madonna -
Mikhail Kolesnik -
Predrag Ivanovic -
William Lewis