User Story
As a Funtoo Linux (a Gentoo variant) 64bit user and volunteer viewer
developer, I want to build Snowstorm with the same build mode I already
use(d) for Snowglobe:
* native (i.e. 64bit)
* standalone
* out-of-source
I'd like to be able to do this for all three, Release, RelWithDebug and
Debug mode.
Rationale
This specific choice of build mode might require some explanations. (If
you don't think so, just skip this section. ;-) )
Why native (64bit)?
* Why not? (OK, that might not be a too good argument.)
* 64bit builds will also have a 64bit |bin/SLPlugin|, which, other
than the 32bit version, will be able to use my already installed
(64bit) GStreamer
o Gentoo (and thus also Funtoo) allows a "multilib" setup that
installs some important libraries in both 64bit and 32bit
versions, so that most 32bit applications can be run.
However, GStreamer isn't one of these libraries, so one
would probably need a 32bit chroot with 32bit GStreamer to
be able to use it from a 32bit |bin/SLPlugin|. That or I
could dual boot or use a VM.
* So I see when changes in the source break 64bit.
o If those can be corrected right away, whenever LL decides to
also provide 64bit binaries, the source will be ready to
build them.
Why standalone?
For those who don't know what the (confusingly named) 'standalone' build
mode implies, see Compiling the viewer (Linux) > What does 'Standalone'
mean?
<https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29#What_does_.27Standalone.27_mean.3F>
on our wiki. So why use it?
* LL provides no 64bit version of the prebuilt libraries, so when
wanting to build 64bit, I don't have much of a choice here, anyway.
* So I see whether version changes of the used libraries will break
something. Often, the code can be prepared to work well with
various versions of a library, see e.g. SNOW-737
<http://jira.secondlife.com/browse/SNOW-737>.
* So I see whether changes in the source break standalone.
o Most packagers of the Viewer for Linux distributions will
base their packages on standalone builds. So keeping
standalone flawless means making their task a bit easier.
Why out-of-source?
What is it and how do I do it? See What is an "out-of-source" build?
<http://cmake.org/Wiki/CMake_FAQ#What_is_an_.22out-of-source.22_build.3F> at
the FAQ on the CMake wiki. As for the why:
* A pristine source tree makes it easy to see your own
modifications, especially addition of yet untracked files (which
will show up in |hg status| but not |hg diff|).
* Maintain builds with different settings from a single source tree
in separate directories.
* Easy to do clean rebuilds by just deleting and re-creating the
build dir.
* Once again, to see when it is/gets broken.
Of course, I don't want to imply that everyone should build like I do.
To the contrary, the more different combinations of build settings,
operation system setup etc. are used (and thus tested and hopefully
fixed if broken), the more robust and flexible our build system and
source will become in the end.
What's already done
As some of you might know, I've been working on collecting patches and
changesets on pJIRA and SVN that allow me to build
lindenlab/viewer-development
<http://bitbucket.org/lindenlab/viewer-development> with the settings
above. I've applied them to my repository at
http://bitbucket.org/boroondas/snowstorm-development , ported/modified
them where necessary. I also had Techwolf port some of his own patches.
(Available on his repo
<https://bitbucket.org/Techwolf/viewer-development>. Thanks Techwolf!)
The final result, merged with the many changes that came from upstream
meanwhile, can be found at the current tip (i.e. rev a0292ef66668)
<http://bitbucket.org/boroondas/snowstorm-development/changeset/a0292ef66668>
of my repository.
Remaining issues
* SNOW-508 <https://jira.secondlife.com/browse/SNOW-508> (missing
|glh/glh_linear.h|)
o Can be worked around manually by just copying the file into
the right place.
o Has a proper solution (for standalone) for this been
established yet and I just missed an additional step needed
for it? If so, please let me know.
* Tests fail because the test binaries can't load the required
shared libraries
o Work around this by disabling the tests: Set |LL_TESTS| to
|FALSE|.
* When building for the first time or after cleaning the build dir,
make fails like this near the end:
> [100%] Building CXX object
> newview/CMakeFiles/secondlife-bin.dir/llappviewerlinux_api_dbus.o
> Linking CXX executable secondlife-bin
> [100%] Built target secondlife-bin
> Scanning dependencies of target copy_l_viewer_manifest
> [100%] Performing viewer_manifest copy
> Source tree: ${SRC_DIR}/indra/newview
> Artwork tree: ${SRC_DIR}/indra/newview
> Build tree: ${BUILD_DIR}/newview
> Destination tree: ${BUILD_DIR}/newview/packaged
> Option: buildtype = RelWithDebInfo
> Option: platform = linux
> Option: dest = ${BUILD_DIR}/newview/packaged
> Option: actions = ['copy']
> Option: source = ${SRC_DIR}/indra/newview
> Option: version = ('2', '1', '2', '0')
> Option: grid =
> Option: build = ${BUILD_DIR}/newview
> Option: artwork = ${SRC_DIR}/indra/newview
> Option: configuration = .
> Option: arch = x86_64
> Option: channel = Second Life Developer
> Processing ../../scripts/messages/message_template.msg =>
> app_settings/message_template.msg ... 1 files
> Processing ../../etc/message.xml => app_settings/message.xml ...
> 1 files
> Processing licenses-linux.txt => licenses.txt ... 1 files
> Processing res/ll_icon.png => secondlife_icon.png ... 1 files
> Processing client-readme.txt => README-linux.txt ... 1 files
> Processing client-readme-voice.txt => README-linux-voice.txt ...
> 1 files
> Processing client-readme-joystick.txt =>
> README-linux-joystick.txt ... 1 files
> Processing wrapper.sh => secondlife ... 1 files
> Processing handle_secondlifeprotocol.sh =>
> etc/handle_secondlifeprotocol.sh ... 1 files
> Processing register_secondlifeprotocol.sh =>
> etc/register_secondlifeprotocol.sh ... 1 files
> Processing refresh_desktop_app_entry.sh =>
> etc/refresh_desktop_app_entry.sh ... 1 files
> Processing launch_url.sh => etc/launch_url.sh ... 1 files
> Processing install.sh => None ... 1 files
> Processing secondlife-bin =>
> bin/do-not-directly-run-secondlife-bin ... 1 files
> Processing ../linux_crash_logger/linux-crash-logger =>
> bin/linux-crash-logger.bin ... 1 files
> Processing ../linux_updater/linux-updater =>
> bin/linux-updater.bin ... 1 files
> Processing ../llplugin/slplugin/SLPlugin => bin/SLPlugin ... 1 files
> Processing * => None ... 43 files
> Processing ../media_plugins/webkit/libmedia_plugin_webkit.so =>
> libmedia_plugin_webkit.so ... 1 files
> Processing
> ../media_plugins/gstreamer010/libmedia_plugin_gstreamer010.so =>
> libmedia_plugin_gstreamer.so ... 1 files
> Processing ../llcommon/libllcommon.so => lib/libllcommon.so ...
> 1 files
> Processing featuretable_linux.txt => None ... 1 files
> Processing secondlife-i686.supp => None ... 1 files
> [100%] Built target copy_l_viewer_manifest
> Scanning dependencies of target generate_breakpad_symbols
> [100%] Generating ./secondlife-symbols-linux.tar.bz2
> generate_breakpad_symbols run with args:
> ('${BUILD_DIR}/newview/packaged',
> 'do-not-directly-run-secondlife-bin SLPlugin', '*.so*',
> '${SRC_DIR}/indra/../libraries/x86_64-linux/bin/dump_syms',
> '${BUILD_DIR}/newview/./secondlife-symbols-linux.tar.bz2')
> dumping module
> '${BUILD_DIR}/newview/packaged/lib/libllcommon.so' with
> '${SRC_DIR}/indra/../libraries/x86_64-linux/bin/dump_syms'...
> Traceback (most recent call last):
> File "${SRC_DIR}/indra/newview/generate_breakpad_symbols.py",
> line 128, in <module>
> sys.exit(main(*sys.argv[1:]))
> File "${SRC_DIR}/indra/newview/generate_breakpad_symbols.py",
> line 77, in main
> for (filename,status,symbols,err) in
> itertools.imap(dump_module, list_files()):
> File "${SRC_DIR}/indra/newview/generate_breakpad_symbols.py",
> line 71, in dump_module
> child = subprocess.Popen([dump_syms_tool, m] ,
> stdout=subprocess.PIPE)
> File "/usr/lib64/python2.6/subprocess.py", line 623, in __init__
> errread, errwrite)
> File "/usr/lib64/python2.6/subprocess.py", line 1139, in
> _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
> make[2]: *** [newview/./secondlife-symbols-linux.tar.bz2] Error 1
> make[1]: ***
> [newview/CMakeFiles/generate_breakpad_symbols.dir/all] Error 2
> make: *** [all] Error 2
The resulting viewer crashes on start-up:
> 64-bit Linux detected.
> Running from ${BUILD_DIR}/newview/packaged
> which: no kde-config in
>
> (/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3:/usr/games/bin)
> Warning: Did not register secondlife:// handler with KDE:
> Directory ${HOME}/.kde4/share/kde4/services/ does not exist.
> - Installing menu entries in ${HOME}/.local/share/applications
> 2010-08-26T11:09:35Z INFO: initConfiguration: Loading settings
> file list
> ${BUILD_DIR}/newview/packaged/app_settings/settings_files.xml
> 2010-08-26T11:09:36Z WARNING: loadFromFile: Cannot find file
> ${BUILD_DIR}/newview/packaged/app_settings/settings_files.xml to
> load.
> 2010-08-26T11:09:36Z newview/llappviewer.cpp(1904) : error
> 2010-08-26T11:09:36Z ERROR: initConfiguration: Cannot load
> default configuration file
> ${BUILD_DIR}/newview/packaged/app_settings/settings_files.xml
> LogLock::LogLock: failed to get mutex for log
> [...]
> LogLock::LogLock: failed to get mutex for log
> ./secondlife: line 118: 12541 Segmentation fault
> LD_LIBRARY_PATH="`pwd`"/lib:"${LD_LIBRARY_PATH}" $LL_WRAPPER
> bin/do-not-directly-run-secondlife-bin --channel "Second Life
> Developer" --settings settings_developer.xml
> *** Bad shutdown. ***
>
> You are running the Second Life Viewer on a x86_64 platform. The
> most common problems when launching the Viewer (particularly
> 'bin/do-not-directly-run-secondlife-bin: not found' and 'error while
> loading shared libraries') may be solved by installing your Linux
> distribution's 32-bit compatibility packages.
> For example, on Ubuntu and other Debian-based Linuxes you might run:
> $ sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-kde
> ia32-libs-sdl
>
> *******************************************************
> This is a BETA release of the Second Life linux client.
> Thank you for testing!
> Please see README-linux.txt before reporting problems.
o I guess this is caused by a missing or wrong dependency
declaration. However it happens with both linear (|-j1|) and
parallel (e.g. |-j3|) builds.
o Workaround: A subsequent invocation of| make| successfully
finishes the build and leads to a working viewer.
I assume all of these issues are also present on
lindenlab/viewer-development
<http://bitbucket.org/lindenlab/viewer-development> i.e. they weren't
introduced by the changes in my repo. Please let me know when this isn't
the case.
What still needs to be done / How you can help
Reviewing and testing
I had to adapt Snowglobe patches to viewer-development that I might not
have fully understood. Also my merge-fu isn't yet beyond doubt. So
reviews of the single commits and merges would be very welcome,
especially from the original contributors of the applied changes.
Obviously, testing would help, too:
* If you have been able to build Snowglobe but not
viewer-development, test whether these changes get you any further
on the latter.
* If you have been able to build viewer-development
o test whether you're still able to do so with the changes
(Build fixes for some shouldn't break the build for others!)
o test whether there are any new runtime bugs (there shouldn't!)
Fixing the remaining issues listed above
Unless they turn out to have been introduced by the changes in my repo,
fixing them shouldn't be a requirement for the changes to be pulled
upstream, I think. However, the task(s) of fixing them should probably
be added to the Product Backlog.
Integration upstream
If I understood correctly, the first step would be to get this on of the
Teams' Product Backlog (probably Project Snowstorm's, so that'd be
Esbee's call.)
cheers
Boroondas
PS: Looks like upstream got some more changesets this morning, I'll
provide a merge ASAP.
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
