• Home
  • Blog
  • Add-ons
  • Forum
  • Wiki
  • Developers
Nightingale - The tune of life, the tune of yours
  • Portal
  • Search
  • Member List
  • Calendar
  • Help
  • Portal
  • Search
  • Member List
  • Calendar
  • Help
Guest Hi, Guest
  • Login
  • Register
Login
Username:
Password: Lost Password?
 
Nightingale Forums Development Technical Development Suggestions related to non-standard distros

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
Suggestions related to non-standard distros
OldCoder Offline
Junior Member
**
Posts: 2
Threads: 1
Joined: Mar 2012
Reputation: 0
#1
03-11-2012, 06:02 AM (This post was last modified: 03-11-2012, 06:05 AM by 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.
Find
Reply
freaktechnik Offline
CCO (Chief Crashing Officer)
*******
Posts: 498
Threads: 24
Joined: Sep 2010
Reputation: 11
#2
03-11-2012, 07:34 AM
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.
freaktechnik
Website Find
Reply
OldCoder Offline
Junior Member
**
Posts: 2
Threads: 1
Joined: Mar 2012
Reputation: 0
#3
03-11-2012, 08:07 AM (This post was last modified: 03-11-2012, 08:33 AM by 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.
Find
Reply
rsjtdrjgfuzkfg Offline
Developer
*******
Posts: 664
Threads: 15
Joined: Oct 2011
Reputation: 15
#4
03-11-2012, 10:32 PM
(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.
Songbird/Nightingale Community Developer and German Translator
Find
Reply
« Next Oldest | Next Newest »


  • View a Printable Version
  • Subscribe to this thread
Forum Jump:


Users browsing this thread: 1 Guest(s)
  • Return to Top
  • Lite (Archive) Mode
  • RSS Syndication
Current time: 03-24-2023, 10:53 AM Powered By MyBB, © 2002-2023 MyBB Group.
Design By AliReza_Tofighi In WhiteCrow Software Group.
white outlined nightingale project logo

Nightingale is free!
It is an Open Source project released under the terms of the GNU General Public License v2 (GPL v2).
For more details, please read the license information.

Follow us!
f  g  t

Support
  • Community Forum
  • Official Blog
  • Add-ons
  • Wiki
  • Help Forum
Contribute
  • Developer's Center
  • Translate Nightingale
  • Source Code
  • Report a Bug
Ressources
  • Download Nightingale
Linear Mode
Threaded Mode