[OldCoder]

I maintain a Linux distro of my own design. It has a non-standard structure but is up-to-date with respect to libraries. Nightengale builds successfully if a few minor changes are made. I'm not able to run the resulting program, but I thought I'd offer some related suggestions for developers.

As a side note, I ported Rhythmbox 2.95 to my distro recently. I look forward to completing a Nightengale port and comparing the two programs.

If there's a solution to the XPCOM issue that's discussed below, I'll maintain a Nightengale page at my site (which discusses open-source programs in general). For now, I'll follow this thread and I can also be reached at the site:

http://tools.99k.org/

The upstream remarks below are for Nightengale developers. The downstream remarks are for other developers who'd like to build the program.

1. GStreamer detection.

Upstream: Some distros put libraries in non-standard locations. I'd suggest modifying "build.sh" to make it easier for distro maintainers to override the default-directories list that's used to locate GStreamer.

Downstream: If you have GStreamer in a non-standard location, edit "build.sh". Look for one or more lines that say "/usr/lib". Add an absolute path for the GStreamer "lib" directory on the same line (or lines), before "/usr/lib". Put a space after the path.

2. Prebuilt binaries.

Upstream: The Nightengale dependencies tarball that's downloaded by "build.sh" includes prebuilt binaries (for example, "libsqlite3.a"). Eventually, the binaries should be replaced with sources; distro maintainers may need to do a full build for things to work and this will include the dependencies.

Additionally, if possible, "build.sh" should allow downstream developers to use the system's copies of libraries (such as XULRunner).

Downstream: If you have libraries in non-standard locations, the prebuilt binaries may cause "build" errors. To correct the errors, try adding absolute paths for the "lib" directories associated with Alsa and "libIDL" to the environment variable LD_LIBRARY_PATH. Note that entries in the variable should be separated by colons. If you're using "bash", "export" the variable afterward.

3. "glib2" compatibility patch.

Upstream and downstream: For Nightengale 1.11, "sbGStreamerService.cpp" needs a patch to compile against newer releases of "glib2". The line that includes "glib/gutils.h" should include "glib.h" instead. This change should be backwards-compatible with older versions of "glib2". Note: The change may already have been made in the Nightengale "git" sources.

4. XPCOM issue.

I made the downstream changes mentioned above and Nightengale then built without problems. However, when I tried to run the program, the error message "Couldn't load XPCOM" was printed.

I tried modifying Nightengale to build against my distro's copy of XULRunner instead of the copy provided by the Nightengale dependencies tarball. This seemed like a possible workaround. Note: My copy of XULRunner is release 1.9.2.19; I assume that this release is compatible.

I didn't see a simple way to do this. Ultimately, I deleted the prebuilt XULRunner binaries (to ensure that they weren't used) and worked out some distro-specific changes that allowed "build.sh" to succeed. The resulting executable produced the same error message ("Couldn't load XPCOM"). That's where I stopped.

Note: "build.sh" didn't rebuild a prebuilt executable named "nightengale-bin". However, most of the Nightengale code seems to be in libraries that were rebuilt, so this may not be related to the problem.

[freaktechnik]

To point two: Songbird (and so does Ngale) uses a modified XULRunner afaik. With the build based on Gecko/XULRunner 6+ we will use the users system librarys and not ship our own ones.

[OldCoder]

I assume that the XULRunner changes are (or will be) in the master branch. I'll check the three main branches (master, nightengale-1.8, and sb-trunk-xul-1) and see if any of them fly.

Edit: All three branches use the prebuilt binaries. This leaves two possibilities:

(a) If the modified XULRunner is available separately, I'll try building it.

(b) If the XPCOM error is a known problem, and if there's a fix, I'll see if the fix works for my setup.

[rsjtdrjgfuzkfg]

(03-11-2012, 08:07 AM)OldCoder Wrote: I assume that the XULRunner changes are (or will be) in the master branch. I'll check the three main branches (master, nightengale-1.8, and sb-trunk-xul-1) and see if any of them fly.

Edit: All three branches use the prebuilt binaries. This leaves two possibilities:

(a) If the modified XULRunner is available separately, I'll try building it.

(b) If the XPCOM error is a known problem, and if there's a fix, I'll see if the fix works for my setup.

Please note that the master build is not yet completely ported to the new xulrunner, and thus it does not build yet. We might use prebuild dependencies there, too, but as we will build our own xulrunner, it will be compartible to other builds as well.
Currently we do not use own xulrunner builds for all platforms, but use the ones from Songbird. This causes various issues, and we're working on improving that. But as we plan to move to Gecko 6 soon, we might not fix the issue for Gecko 1.9.2.

Note that I can't speak for the xulrunner situation on linux, we use own builds there. Let's wait for some input by ilikenwf on that issue, he's the one that build them. Probably he can tell you about needed modification or build flags or anything else that might be related to the issue.