Hi everyone, I just finished building GNOME 2.10 from CVS with JHBuild. I still have some serious bugs to resolve, but I wanted to share my build notes so far and hopefully we can use this thread to put together a community version of GNOME 2.10 while we wait for the next version of JDS. I'll volunteer to build the binary packages once all the "showstopper" bugs are resolved.
1) Prerequisites. JHBuild is a Python script that checks out (or updates) each module from CVS and builds them in the correct order. Here are the environment variables I set before compiling: export CC="cc" export CXX="CC" export CFLAGS="-xO3 -xtarget=native -xstrconst -xildoff" export CPPFLAGS="-I/opt/csw/include" export CXXFLAGS="-xO4 -xtarget=native -xildoff" export LDFLAGS="-R/opt/csw/lib -L/opt/csw/lib -Wl,-ztext -Wl,-zdefs -Wl,-zcombreloc" export MAKE="gmake" A few comments are in order. I am using some libraries from BlastWave to avoid having to build packages not built by JHBuild. There are a few conflicts, however, particularly with libintl.so.3 from CSWggettext, which is built during the JHBuild bootstrap, and libxml2.so.2 from CSWlibxml2, which is built during the main JHBuild process. Looking at a running gnome-terminal process with pldd, I can see that *both* versions of libintl.so.3 and libxml2.so.2 are being loaded, which I'm not at all happy about. Probably the solution would be to remove those packages from the JHBuild process. For my ~/.jhbuildrc, I edited these lines: moduleset = 'gnome-2.10' autogenargs='--disable-static' os.environ['MAKE'] = 'gmake -j2' There are a few packages which don't build properly with 'gmake -j2', but it speeds up the build process for most packages and I can manually run make if a package build fails. Another flag which is useful for manual, but not automated, builds is "-Wl,-ztext" in LDFLAGS, which returns an error if all symbols haven't been resolved when building a shared library. Most of the time, a shared library will be linked against all libraries that it requires, but on Solaris, occasionally there will be a missing "-lm" or "-lsocket -lnsl" that will probably not be a problem since the main executable will likely be linking against those libraries, but it's good practice to have shared libs be self-contained in their link requirements. For "plugin" libraries that are dlopen'ed at run-time, however, perhaps it doesn't make sense to do this when the dependencies are other loadable modules, so in those cases I just removed the '-Wl,-ztext' flag to continue the build. I based the "-Wl,-zcombreloc" flag on Alan Coopersmith's blog entry about improving GNOME startup time via ld flags. http://blogs.sun.com/roller/page/alanc?entry=can_gnome_startup_time_be His suggestion of removing unneeded libraries from the .pc files is a good one, but it requires every library to be self contained in its dependencies, and even worse, some applications may link against a particular library and then call functions directly from one of its dependencies (-lX11 or -lgobject-2.0, for example). So doing this correctly is difficult and the '-Wl,-ztext' flag is helpful, although tedious. I'll put together some patches to fix the link dependency issues I've found so far and share them soon. I also need to figure out why "-R/usr/ucblib" slipped into some of the link lines and how to get rid of that. Now, a list of the BlastWave packages I'm using (besides the two already mentioned), along with some brief notes on particular modules I had trouble with. Again, when I have a chance to put together and test patches for these issues, I'll share them. CSWlibpopt CSWiconv CSWaudiofile CSWexpat CSWjpeg CSWossl CSWfconfig CSWzlib CSWbzip2 CSWlibnet CSWlibexif CSWftype2 GStreamer plugins: CSWaalib CSWarts CSWlibdvdnav CSWlibdvdread CSWfaad2 CSWlame CSWlibmad CSWlibid3tag CSWmikmod CSWlibogg CSWvorbis CSWlibmng CSWlcms CSWmpeg2dec CSWpng CSWlibsdl For Gnome-VFS: CSWfam CSWsambalib (and CSWsambalibdev) CSWkrb5lib CSWoldap CSWsasl Problems building libIDL: change CPP_PROGRAM from "cc -E" to "gcc -E" or else IDL parser won't work. ORBit: test/inhibit fails to compile. libbonobo: use of nonportable __inline__. First of many packages where I needed to run "intltoolize --force" by hand to create intltool-*.in files which aren't in CVS and weren't created by autogen.sh. GConf, gnome-mime-data: won't build with "gmake -j2" howl: libhowl needs "-lsocket -lnsl" startup-notification: change non-portable __FUNCTION__ to __func__ libgcrypt/mpi: change CCAS to "gcc" to build inline assembly routines gnome-session: should add /usr/X11/include and /usr/X11/lib to x86 build to get access to -lXrandr. gst-plugins: configure script only works with "/bin/bash". I haven't tested any of the plugins yet and so there are probably some bugs here. Mozilla 1.7.10: this was an interesting case since I was using '-Wl,-zdefs' and discovered that the file "build/unix/gnu-ld-scripts/components-mapfile" sets all symbols to local except for four exported symbols (NSGetFactory, NSGetModule, NSRegisterSelf, and NSUnregisterSelf), but no component exports anything other than NSGetModule. There's also a fairly serious bug in my build of Mozilla: whenever I try to save a file, I get an error: "/tmp/uwf1wyby.exe could not be saved, because the source file could not be read. Try again later, or contact the server administrator." The filename is random and only the extension changes. Also, epiphany, a GNOME wrapper around libgtkembedmoz.so, just crashes when I try to run it. yelp uses GCC-specific "-include" to pre-include a Mozilla header file in one place. Quite a few packages hard-code "-Wall" or some other GCC warning flags. I see now that I have about a dozen more comments to type up so I'll write up those notes in another message. Besides the mozilla save file bug, the one serious problem I have with the new GNOME 2.10 desktop is that my Applications menu is empty except for "Run Application..."! I've tried deleting my ~/.gnome*, ~/.gconf*, and ~/.nautilus directories, but I don't know enough about how the gnome panel works to understand where it's supposed to get its Applications menu items from. Since everything is installed into /opt/gnome2, it shouldn't be conflicting with anything from JDS. -- Jake Hamby This message posted from opensolaris.org
