From sldev at free.fr Thu Jul 9 07:46:27 2015 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 9 Jul 2015 16:46:27 +0200 Subject: [opensource-dev] CEF plugin for Linux builds, a recipe Message-ID: <20150709164627.e3e40589.sldev@free.fr> Greetings, Since llceflib has been made public and I could also find Callum's viewer-cef branch on bibucket, I decided to give a try at a Linux build. ******** CHAPTER 1: an adventure (just kidding !) ********* As I anticipated, having llceflib built from the pre-built CEF3 binaries ( https://cefbuilds.com/ ) was quite easy (just a matter of writing two CMakeLists.txt files, a llceflibimpl.cpp file, a build script (since I don't use automake and the Linux stuff for it was missing anyway), and fixing some non-ISO C++ conformant lines that made gcc choke). Under three hours after I started (which includes the time it took to backport the plugin code from viewer-cef to the Cool VL Viewer), I had a successful build... What I did not anticipate, however, was that libcef.so, while it was working fine when used from the example cefclient shipped with CEF, lamentably crashed when loaded from SLPlugin/media_plugin_cef... The crash was: *** glibc detected *** /usr/local/CoolVLViewer-i686-1.26.15.0/bin/llplugin/SLPlugin: free(): invalid size: 0x08442000 *** ======= Backtrace: ========= /lib/i686/libc.so.6(+0x6cf32)[0xb722bf32] /usr/local/CoolVLViewer-i686-1.26.15.0/lib/libcef.so(+0x8fe725)[0xb3720725] The problem comes from the fact that libcef.so includes... tcmalloc !.. Of course, memory (i.e. classes, etc) allocated by SLPlugin before it loads media_plugin_cef (which itself causes libcef.so to be loaded by the dynamic linker), cannot be released afterwards (because then, SLPlugin gets infected by tcmalloc, and ends up releasing with tcmalloc's free() strucures that were allocated with the system malloc()). That's *really* a *very* stupid thing to link a custom memory allocator to a dynamic library that may be loaded at any moment (and not only at the consummer program's startup): CEF coders, shame on you ! The only solution is to rebuild libcef.so without tcmalloc (I also tried and built the Cool VL Viewer with tcmalloc, since it's one of the options I can enable with the flip of a cmake variable, but even this doesn't solve the issue, since the two tcmalloc instances got different heaps and memory pointers). After rebuilding, the new, tcmalloc-less libcef.so works just fine. All in all, and not counting the rebuilding time (building CEF from sources involves the downloading of 16Gb of sources which take several hours to compile), it took me just under 6 hours of actual work to have a functional Linux build of the Cool VL Viewer with CEF. ******** CHAPTER 2: HOWTOs ********* I will give hereafter: - For TPV developers, the pointers to ready-to-use files so to easily integrate CEF to their TPV Linux builds. - For both TPV developers and Linden Lab (the latter stubornely refusing to reuse my code without a privacy-threatening CA, even though the said code is GPL/LGPL), directions/hints/advices on how to rebuild CEF on Linux and integrate it in a Linux viewer build (directions, hints and advices don't involve any copyright issue, so LL can reuse them without a CA !... No excuse any more, LL !). A.- Ready to use stuff (for TPV developers): - llceflib pre-compiled package with Linux binary (built on a Rosa 2012 system with the following requirements for target systems: glibc v2.13 or newer, libstdc++.so.6.0.16 (gcc v4.6) or newer, libX11 v1.5.0 or newer, libXi v1.6.0 or newer (the latter two are in fact libcef.so requirements, see the chapter about runtime dependencies below). Get it from: http://sldev.free.fr/libraries/llceflib-linux-no_tcmalloc-20150709.tar.bz2 md5sum: 3dd8afe90b8460da060362fad1de85fd - Diff file, summing up all the changes I had to do to the Cool VL Viewer sources. Of course, that diff won't be directly usable as a patch file for your own viewer, but it will give you pointers and methods to what need to be changed in your own viewer. The diff file also includes the backport of Callum's viewer-cef code, with the necessary bug fixes. It also provides a new feature I implemented, allowing to switch between the WebKit and the CEF plugin in real time via the new UseCEF debug variable (i.e., after changing that variable, every newly spawn plugin uses the corresponding embedded browser). Get it from there: http://sldev.free.fr/libraries/patches/CoolVLViewer-CEF-diff.txt The diff was made against the current experimental version of the Cool VL Viewer, which sources are available (till next Saturday, after they will be updated to the next release) here: http://sldev.free.fr/sources/slviewer-src-cool_vl_viewer-1261318.tar.gz - If you wish to rebuild your own lllceflib library yourself, first make sure you got the 'ninja' build tool installed on your system as well as a recent version of cmake (3.0 or newer). Then simply download the tcmalloc-less CEF3 bundle from: http://sldev.free.fr/libraries/sources/cef_binary_3.2272.32.gbda8dc7_linux32-no_tcmalloc.tar.bz2 as well as LL's 3p-llceflib sources from: https://bitbucket.org/lindenlab/3p-llceflib/get/tip.tar.bz2 Untar 3p-llceflib, and inside its directory, untar the CEF3 bundle. Then get the following patch: http://sldev.free.fr/libraries/patches/llceflib.patch and apply it from inside 3p-llceflib directory, like so: patch -p1 -s References: <20150709164627.e3e40589.sldev@free.fr> Message-ID: Does LL even intend to migrate to CEF3 anymore? I noticed all the JIRAs relating to it were recently closed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20150709/37786d90/attachment.htm From nickyperian at gmail.com Tue Jul 14 09:22:50 2015 From: nickyperian at gmail.com (Nicky Perian) Date: Tue, 14 Jul 2015 11:22:50 -0500 Subject: [opensource-dev] Building GTK+ and friends with autobuild new tools Message-ID: R To From monty at lindenlab.com Tue Jul 14 10:17:17 2015 From: monty at lindenlab.com (Monty Brandenberg) Date: Tue, 14 Jul 2015 13:17:17 -0400 Subject: [opensource-dev] Building GTK+ and friends with autobuild new tools In-Reply-To: References: Message-ID: <55A5441D.4030309@lindenlab.com> On 7/14/2015 12:22 PM, Nicky Perian wrote: > R > To That's pretty much been my experience, too. -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! From Lance.Corrimal at eregion.de Tue Jul 14 11:37:13 2015 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 14 Jul 2015 20:37:13 +0200 Subject: [opensource-dev] Building GTK+ and friends with autobuild new tools In-Reply-To: <55A5441D.4030309@lindenlab.com> References: <55A5441D.4030309@lindenlab.com> Message-ID: <9587427.3e5BYgnbbE@kumiko> Am Dienstag, 14. Juli 2015, 13:17:17 schrieb Monty Brandenberg: > On 7/14/2015 12:22 PM, Nicky Perian wrote: > > R > > To > > That's pretty much been my experience, too. Same here, actually... I *hate* the way the latest sources ignore settings that you pass with autobuild, and insist on building ll_test even when you explicitely set LL_TEST:BOOL=FALSE, leading to a build fail due to the fact that the boost and googlemock libs have been built using the unknown gcc version that shall not be named in public(tm). It would REALLY help if there was any kind of relationship between the actual build environment that LL uses and the build environment that has been (sparsely) documented on the wiki... Even better: use centos, not debian, as the build environment, and provide a kickstart file that installs exactly what is needed. Oh wait, the linux viewer is dead. From nickyperian at gmail.com Wed Jul 22 11:08:16 2015 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 22 Jul 2015 13:08:16 -0500 Subject: [opensource-dev] Building GTK+ and friends with autobuild new tools In-Reply-To: <9587427.3e5BYgnbbE@kumiko> References: <55A5441D.4030309@lindenlab.com> <9587427.3e5BYgnbbE@kumiko> Message-ID: Removed use_prebuilt_binary(gtk-atk-pango-glib) archive. Replaced with: use_prebuilt_binary(cairo) https://bitbucket.org/kokua/3p-cairo/downloads/cairo-1.14.2-linux-201507192252.tar.bz2 use_prebuilt_binary(glib) https://bitbucket.org/kokua/3p-glib/downloads/glib-2.44.1-linux-201507131131.tar.bz2 use_prebuilt_binary(atk) https://bitbucket.org/kokua/3p-atk/downloads/atk-2.16.0-linux-201507162046.tar.bz2 use_prebuilt_binary(pixman) https://bitbucket.org/kokua/3p-pixman/downloads/pixman-0.32.6-linux-201507192238.tar.bz2 use_prebuilt_binary(harfbuzz) https://bitbucket.org/kokua/3p-harfbuzz/downloads/harfbuzz-0.9.40-linux-201507201105.tar.bz2 use_prebuilt_binary(pango) https://bitbucket.org/kokua/3p-pango/downloads/pango-1.36.8-linux-201507201400.tar.bz2 use_prebuilt_binary(gtk) https://bitbucket.org/kokua/3p-gtk/downloads/gtk-2.24.28-linux-201507211717.tar.bz2 use_prebuilt_binary(gdk-pixbuf) https://bitbucket.org/kokua/3p-gdk-pixbuf/downloads/gdk_pixbuf-2.30.8-linux-201507210933.tar.bz2 The dependencies of one to another are met using LindenLab autobuild-1.3. For gtk there is some overlinking into the system gtk that was never fully solved. The approach taken was to use a gtk download that matched the system gtk; in this case gtk-+2.0 version 2.24.28 which matched debian stretch (testing). glib is used as a base dependency for the other libraries. The libraries are built with gcc-4.9.2 as is Kokua. On Tue, Jul 14, 2015 at 1:37 PM, Lance Corrimal wrote: > Am Dienstag, 14. Juli 2015, 13:17:17 schrieb Monty Brandenberg: > > On 7/14/2015 12:22 PM, Nicky Perian wrote: > > > R > > > To > > > > That's pretty much been my experience, too. > > > Same here, actually... I *hate* the way the latest sources ignore settings > that you pass with autobuild, and insist on building ll_test even when you > explicitely set LL_TEST:BOOL=FALSE, leading to a build fail due to the fact > that the boost and googlemock libs have been built using the unknown gcc > version that shall not be named in public(tm). > > It would REALLY help if there was any kind of relationship between the > actual > build environment that LL uses and the build environment that has been > (sparsely) documented on the wiki... > > Even better: use centos, not debian, as the build environment, and provide > a > kickstart file that installs exactly what is needed. > > Oh wait, the linux viewer is dead. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20150722/d84dec0a/attachment.htm From sldev at free.fr Thu Jul 23 07:49:23 2015 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 23 Jul 2015 16:49:23 +0200 Subject: [opensource-dev] Building GTK+ and friends with autobuild new tools In-Reply-To: References: <55A5441D.4030309@lindenlab.com> <9587427.3e5BYgnbbE@kumiko> Message-ID: <20150723164923.0c2e9bb4.sldev@free.fr> On Wed, 22 Jul 2015 13:08:16 -0500, Nicky Perian wrote: > Removed use_prebuilt_binary(gtk-atk-pango-glib) archive. > > Replaced with: > glib-2.44.1-linux-201507131131.tar.bz2 I'm afraid these are way too modern libraries... My main Linux system, which runs a distribution released in 2012 (i.e. not even yet 3 years old) still uses glib v2.28... It means that any viewer built on that new a set of libraries will fail to run on all but *very* recent Linux distribution releases... > cairo-1.14.2-linux-201507192252.tar.bz2 > atk-2.16.0-linux-201507162046.tar.bz2 > pango-1.36.8-linux-201507201400.tar.bz2 > gtk-2.24.28-linux-201507211717.tar.bz2 > gdk_pixbuf-2.30.8-linux-201507210933.tar.bz2 > pixman-0.32.6-linux-201507192238.tar.bz2 Here, I got: - cairo v1.10.2 - atk v2.0.1 - pango v1.29.4 - gtk2 v2.24.10 - gdk_pixbuf v2.24 - pixman v0.22.0 Not that I'm too worried about those for my own viewer, since I got entirely rid of the GTK & ancillaries dependencies many months ago (I'm using an XUI-based, fully OS-independent (and natively non- blocking) file/directory selector, rewrote the whole copy/paste text routines and based only on Xlib, and I'm using a wrapper script calling any of Xdialog/Zenity/xmessage/etc to replace the GTK box (OSMessageBox()) used in case of viewer launch failure). But for other viewers still using GTK, the same remark as for glib holds true, I'm afraid... > use_prebuilt_binary(harfbuzz) Wazzat ??? O.O > The libraries are built with gcc-4.9.2 as is Kokua. Which, again, is an excessive system requirement on both glibc (v2.13 here) and libstdc++ versions... LL's pre-built libraries have all been compiled with gcc v4.6 and can run even on glibc v2.11 (and probably even older, but I don't have an older system to test the viewer onto :-P). You should keep using gcc v4.6.4 for building Linux libraries. For your info, my current build system for the Cool VL Viewer dates back from 2010 (gcc 4.6.4, glibc v2.11.1 and libstdc++ v6.0.16). Regards, Henri. From sldev at free.fr Thu Jul 23 08:17:29 2015 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 23 Jul 2015 17:17:29 +0200 Subject: [opensource-dev] VS2013 viewer builds and llqtwebkit Message-ID: <20150723171729.c196d680.sldev@free.fr> Greetings, I updated my viewer so that it could be built with VS2013 (in excess of VS2010), but I'm having troubles with LL's llqtwebkit library: when VS2013 attempts to link media_plugin_webkit against that library, the linker spits error messages such as: llqtwebkit.lib(llqtwebkit.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't match value '1800' in media_plugin_webkit.obj Strangely enough, and although I'm using the very pre-built llqtwebkit package that is linked to in LL's latest release viewer ("new build tools") autobuild.xml file, the library doesn't seem to have been built using VS2013... Did anyone else run into this issue (i.e. is anyone else than LL actually compiling their viewer with the "new build tools"), and/or did anyone already compile themselves llqtwebkit with VS2013 (I'd gladly borrow their binary, since I'm busy enough already with CEF3 stuff) ? Regards, Henri. From nickyperian at gmail.com Thu Jul 23 12:12:50 2015 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 23 Jul 2015 14:12:50 -0500 Subject: [opensource-dev] VS2013 viewer builds and llqtwebkit In-Reply-To: <20150723171729.c196d680.sldev@free.fr> References: <20150723171729.c196d680.sldev@free.fr> Message-ID: I haven't seen a 2013 version of llqtwebkit. I attempted with QtWebkit 4.8.5 sources and quickly ran into 2013 problems and quit. Nicky On Thu, Jul 23, 2015 at 10:17 AM, Henri Beauchamp wrote: > Greetings, > > I updated my viewer so that it could be built with VS2013 (in excess > of VS2010), but I'm having troubles with LL's llqtwebkit library: when > VS2013 attempts to link media_plugin_webkit against that library, the > linker spits error messages such as: > llqtwebkit.lib(llqtwebkit.obj) : error LNK2038: mismatch detected for > '_MSC_VER': value '1600' doesn't match value '1800' in > media_plugin_webkit.obj > > Strangely enough, and although I'm using the very pre-built llqtwebkit > package that is linked to in LL's latest release viewer ("new build > tools") autobuild.xml file, the library doesn't seem to have been built > using VS2013... > > Did anyone else run into this issue (i.e. is anyone else than LL > actually compiling their viewer with the "new build tools"), and/or > did anyone already compile themselves llqtwebkit with VS2013 (I'd > gladly borrow their binary, since I'm busy enough already with CEF3 > stuff) ? > > Regards, > > Henri. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20150723/f1f34010/attachment.htm From desmoulins.uchi at googlemail.com Thu Jul 23 12:41:12 2015 From: desmoulins.uchi at googlemail.com (Niran) Date: Thu, 23 Jul 2015 21:41:12 +0200 Subject: [opensource-dev] VS2013 viewer builds and llqtwebkit In-Reply-To: <20150723171729.c196d680.sldev@free.fr> References: <20150723171729.c196d680.sldev@free.fr> Message-ID: Strange... i haven't noticed any llwebkit issues but then again i haven't really cared in the past as webkit was always some kind of broken for me. I'll take a closer look next time i compile the Viewer. 2015-07-23 17:17 GMT+02:00 Henri Beauchamp : > Greetings, > > I updated my viewer so that it could be built with VS2013 (in excess > of VS2010), but I'm having troubles with LL's llqtwebkit library: when > VS2013 attempts to link media_plugin_webkit against that library, the > linker spits error messages such as: > llqtwebkit.lib(llqtwebkit.obj) : error LNK2038: mismatch detected for > '_MSC_VER': value '1600' doesn't match value '1800' in > media_plugin_webkit.obj > > Strangely enough, and although I'm using the very pre-built llqtwebkit > package that is linked to in LL's latest release viewer ("new build > tools") autobuild.xml file, the library doesn't seem to have been built > using VS2013... > > Did anyone else run into this issue (i.e. is anyone else than LL > actually compiling their viewer with the "new build tools"), and/or > did anyone already compile themselves llqtwebkit with VS2013 (I'd > gladly borrow their binary, since I'm busy enough already with CEF3 > stuff) ? > > Regards, > > Henri. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20150723/a74b2cb1/attachment.htm From nickyperian at gmail.com Thu Jul 23 19:47:36 2015 From: nickyperian at gmail.com (Nicky Perian) Date: Thu, 23 Jul 2015 21:47:36 -0500 Subject: [opensource-dev] Building GTK+ and friends with autobuild new tools In-Reply-To: <20150723164923.0c2e9bb4.sldev@free.fr> References: <55A5441D.4030309@lindenlab.com> <9587427.3e5BYgnbbE@kumiko> <20150723164923.0c2e9bb4.sldev@free.fr> Message-ID: Thanks for taking time to provide a thoughtful reply. I agree, it is not a viewer for older distributions. However, by packaging libstdc++ with the viewer lib/ it runs very well on debian jessie (current stable), Ubuntu 14.04 and Linux Mint 17.1 and 17.2. and several other distributions. Kokua linux 64 bit test viewer build with these libraries has been out for several weeks and there are with very few problems reports. Opensuse being one of the few. IMO if you run opensuse w/KDE you might as well install windows. Here is a code snip from one of the libraries """""""""""""""""""""""""""""""""""' case "$AUTOBUILD_PLATFORM" in "linux") # Prefer gcc-4.9 if available. if [[ -x /usr/bin/gcc-4.9 && -x /usr/bin/g++-4.9 ]]; then export CC=/usr/bin/gcc-4.9 export CXX=/usr/bin/g++-4.9 fi # Default target to 32-bit opts="${TARGET_OPTS:--m32}" # Handle any deliberate platform targeting if [ -z "$TARGET_CPPFLAGS" ]; then # Remove sysroot contamination from build environment unset CPPFLAGS else # Incorporate special pre-processing flags export CPPFLAGS="$TARGET_CPPFLAGS" fi pushd "$TOP/$SOURCE_DIR" CPPFLAGS="-I${stage}/#packages/include $TARGET_CPPFLAGS"# LDFLAGS="-L${stage}/packages/lib/release"# PKG_CONFIG_PATH=# export CPPFLAGS LDFLAGS LD_LIBRARY_PATH# LD_LIBRARY_PATH="${stage}/packages/lib/release"# PATH="${stage}/packages/include:${stage}/packages/lib/release:$PATH"# export LD_LIBRARY_PATH PATH CFLAGS="-I${stage}/packages/include -I$ATK_INCLUDE -I$CAIRO_INCLUDE -I$PANGO_INCLUDE -I$HARFBUZZ_INCLUDE -I$GDKPIXBUF_INCLUDE $opts -O3 -fPIC -DPIC"\ ./configure --prefix="$stage" make make install mkdir -p "$stage/include/gtk" cp -a gtk/*.h "$stage/include/gtk" mkdir -p "$stage/include/gdk" cp -a gdk/*.h "$stage/include/gdk" popd mv lib release mkdir -p lib mv release lib """""""""""""""""""""""" All of the gtk and friends libraries will build on gcc-4.6. Just change 4.9 to 4.6 atthe beginning of the linux sections of the script. For linux 64 bit I did use 4.6 but since I had to re-build boost, googlemock and colladadom with 4.9 I decided to just go with 4.9. Debian stretch has a package for gcc-4.6.4 through gcc-4.9.2 so it seems to me to be a good choice for the future. For instance, you can build with 4.6.4 and move up as desired. I am keeping an older version of Kokua available for older distributions. If I have complaints of Kokua not being able to run I'll reference CoolVL and Singularity as alternates to use. Regards, Nicky On Thu, Jul 23, 2015 at 9:49 AM, Henri Beauchamp wrote: > On Wed, 22 Jul 2015 13:08:16 -0500, Nicky Perian wrote: > > > Removed use_prebuilt_binary(gtk-atk-pango-glib) archive. > > > > Replaced with: > > glib-2.44.1-linux-201507131131.tar.bz2 > > I'm afraid these are way too modern libraries... My main Linux system, > which runs a distribution released in 2012 (i.e. not even yet 3 years > old) still uses glib v2.28... > It means that any viewer built on that new a set of libraries will fail > to run on all but *very* recent Linux distribution releases... > > > cairo-1.14.2-linux-201507192252.tar.bz2 > > atk-2.16.0-linux-201507162046.tar.bz2 > > pango-1.36.8-linux-201507201400.tar.bz2 > > gtk-2.24.28-linux-201507211717.tar.bz2 > > gdk_pixbuf-2.30.8-linux-201507210933.tar.bz2 > > pixman-0.32.6-linux-201507192238.tar.bz2 > > Here, I got: > - cairo v1.10.2 > - atk v2.0.1 > - pango v1.29.4 > - gtk2 v2.24.10 > - gdk_pixbuf v2.24 > - pixman v0.22.0 > > Not that I'm too worried about those for my own viewer, since I got > entirely rid of the GTK & ancillaries dependencies many months ago > (I'm using an XUI-based, fully OS-independent (and natively non- > blocking) file/directory selector, rewrote the whole copy/paste text > routines and based only on Xlib, and I'm using a wrapper script > calling any of Xdialog/Zenity/xmessage/etc to replace the GTK box > (OSMessageBox()) used in case of viewer launch failure). > > But for other viewers still using GTK, the same remark as for glib > holds true, I'm afraid... > > > use_prebuilt_binary(harfbuzz) > > Wazzat ??? O.O > > > The libraries are built with gcc-4.9.2 as is Kokua. > > Which, again, is an excessive system requirement on both glibc > (v2.13 here) and libstdc++ versions... LL's pre-built libraries > have all been compiled with gcc v4.6 and can run even on glibc v2.11 > (and probably even older, but I don't have an older system to test > the viewer onto :-P). > You should keep using gcc v4.6.4 for building Linux libraries. For > your info, my current build system for the Cool VL Viewer dates back > from 2010 (gcc 4.6.4, glibc v2.11.1 and libstdc++ v6.0.16). > > Regards, > > Henri. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20150723/e52ad614/attachment-0001.htm From sldev at free.fr Fri Jul 24 01:16:50 2015 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 24 Jul 2015 10:16:50 +0200 Subject: [opensource-dev] Building GTK+ and friends with autobuild new tools In-Reply-To: References: <55A5441D.4030309@lindenlab.com> <9587427.3e5BYgnbbE@kumiko> <20150723164923.0c2e9bb4.sldev@free.fr> Message-ID: <20150724101650.177d1ea7.sldev@free.fr> On Thu, 23 Jul 2015 21:47:36 -0500, Nicky Perian wrote: > Thanks for taking time to provide a thoughtful reply. > I agree, it is not a viewer for older distributions. I don't consider 3 years old distributions as "old" ones... If you do, then What would you say about Windows XP, Vista, or even Windows 7 ? :-D > However, by packaging libstdc++ with the viewer lib/ it runs very > well on debian jessie (current stable), Ubuntu 14.04 and Linux Mint > 17.1 and 17.2. and several other distributions. Try Ubuntu 12 (2012, i.e. 3 years old only)... Or Mandriva derivatives Mageia, Rosa, OpenMandriva, etc, most of which had their two last releases published in 2012 and 2014 (the 2014 release will work, not the 2012)... I consider that, for any given distribution, at the very least the two releases that came before the current one should be able to run my viewer. > Kokua linux 64 bit test viewer build with these libraries has been > out for several weeks and there are with very few problems reports. > Opensuse being one of the few. IMO if you run opensuse w/KDE you > might as well install windows. Pardon ?... I'd never run Windows. And no, I'm not using KDE either, but even KDE users would not drop Linux for Windoze. :-P Telling to OpenSuse users, "hey, just use Windows instead to run my viewer !" is just as lame as Linux support drop by LL... You don't want to become as lame as LL, do you ?... :-D > Here is a code snip from one of the libraries > .../... > All of the gtk and friends libraries will build on gcc-4.6. Just > change 4.9 to 4.6 atthe beginning of the linux sections of the > script. This is not *just* a problem with gcc... You need to provide pre- built glib and gtk (& ancillaries) versions which are *inferior or equal* to the ones of oldest distribution you want the viewer to run onto, else you will invariably get unresolved symbols at runtime, because neither glib nor gtk are packaged with the viewer (which therefore uses the libraries of the system it is ran onto). Also, you need to make sure that the glibc version of the system you build your pre-built libraries onto is old enough to run on the oldest targeted distribution. To give you an example, software such as Firefox, Google Earth, VirtualBox, Blender etc (i.e. software that come as, or are also available as non-distribution specific packaged binaries, just like SL viewers) can all run on a glibc v2.11 system (my oldest Linux system runs them), and perhaps even older (I won't be surprised if they can still run on a glibc 2.10 system). Regards, Henri. From nickyperian at gmail.com Fri Jul 24 03:32:37 2015 From: nickyperian at gmail.com (Nicky Perian) Date: Fri, 24 Jul 2015 05:32:37 -0500 Subject: [opensource-dev] Building GTK+ and friends with autobuild new tools In-Reply-To: <20150724101650.177d1ea7.sldev@free.fr> References: <55A5441D.4030309@lindenlab.com> <9587427.3e5BYgnbbE@kumiko> <20150723164923.0c2e9bb4.sldev@free.fr> <20150724101650.177d1ea7.sldev@free.fr> Message-ID: With vs2013 there is not an xp target. With some work I think one could be added. OSX 10.7 is no longer an SL target. Quote for a user: Firstly great job on the new NT viewer, running great on Arch Linux with nVidia v352,21 One minor issue I noticed in the console on start up is: Fontconfig error: Cannot load default config file This occurs on my Fedora 22 installation also. Getting some great FPS figures with Advanced Lighting Model enabled and dd at 256m .. 35 -50 FPS on my home sim. Thanks for all your hard work, good luck with the new viewer, please let me know if I can be of any further help. On Fri, Jul 24, 2015 at 3:16 AM, Henri Beauchamp wrote: > On Thu, 23 Jul 2015 21:47:36 -0500, Nicky Perian wrote: > > > Thanks for taking time to provide a thoughtful reply. > > I agree, it is not a viewer for older distributions. > > I don't consider 3 years old distributions as "old" ones... If you do, > then What would you say about Windows XP, Vista, or even Windows 7 ? > :-D > > > However, by packaging libstdc++ with the viewer lib/ it runs very > > well on debian jessie (current stable), Ubuntu 14.04 and Linux Mint > > 17.1 and 17.2. and several other distributions. > > Try Ubuntu 12 (2012, i.e. 3 years old only)... Or Mandriva derivatives > Mageia, Rosa, OpenMandriva, etc, most of which had their two last > releases published in 2012 and 2014 (the 2014 release will work, not > the 2012)... > > I consider that, for any given distribution, at the very least the > two releases that came before the current one should be able to run > my viewer. > > > Kokua linux 64 bit test viewer build with these libraries has been > > out for several weeks and there are with very few problems reports. > > Opensuse being one of the few. IMO if you run opensuse w/KDE you > > might as well install windows. > > Pardon ?... I'd never run Windows. And no, I'm not using KDE either, > but even KDE users would not drop Linux for Windoze. :-P > > Telling to OpenSuse users, "hey, just use Windows instead to run my > viewer !" is just as lame as Linux support drop by LL... You don't > want to become as lame as LL, do you ?... :-D > > > Here is a code snip from one of the libraries > > .../... > > All of the gtk and friends libraries will build on gcc-4.6. Just > > change 4.9 to 4.6 atthe beginning of the linux sections of the > > script. > > This is not *just* a problem with gcc... You need to provide pre- > built glib and gtk (& ancillaries) versions which are *inferior or > equal* to the ones of oldest distribution you want the viewer to run > onto, else you will invariably get unresolved symbols at runtime, > because neither glib nor gtk are packaged with the viewer (which > therefore uses the libraries of the system it is ran onto). > > Also, you need to make sure that the glibc version of the system > you build your pre-built libraries onto is old enough to run on > the oldest targeted distribution. To give you an example, software > such as Firefox, Google Earth, VirtualBox, Blender etc (i.e. > software that come as, or are also available as non-distribution > specific packaged binaries, just like SL viewers) can all run on a > glibc v2.11 system (my oldest Linux system runs them), and perhaps > even older (I won't be surprised if they can still run on a glibc > 2.10 system). > > Regards, > > Henri. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20150724/6fa3a992/attachment.htm From sldev at free.fr Fri Jul 24 05:43:48 2015 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 24 Jul 2015 14:43:48 +0200 Subject: [opensource-dev] Building GTK+ and friends with autobuild new tools In-Reply-To: References: <55A5441D.4030309@lindenlab.com> <9587427.3e5BYgnbbE@kumiko> <20150723164923.0c2e9bb4.sldev@free.fr> <20150724101650.177d1ea7.sldev@free.fr> Message-ID: <20150724144348.90118c89.sldev@free.fr> On Fri, 24 Jul 2015 05:32:37 -0500, Nicky Perian wrote: > With vs2013 there is not an xp target. With some work I think one > could be added. Yes, there's a vs2012-xp target in VS2013, but I guess you'd need to recompile all the pre-built VS2013 libraries as well, so... It doesn't remove anything about my point: even Windows 7 is well over 3 years old, and I don't see why Linux users should be treated with less respect and regard for their choice of staying with a 3 years old distribution installed on their system... > OSX 10.7 is no longer an SL target. I can't tell anything about MacOS-X, since it's for me quite an alien, strange world (as everything from Apple)... > Quote for a user: You'd need to cite much more than just one happy user's quote to counter the points I made... Your own admission about "Opensuse being one of the few [problems reports]" is just a confirmation about what I told you. You are, of course, free to ignore my advices... LL is doing it everytime and then some Linden I won't name gets all pissed off when I tell them "you know, I told you..." :-P Regards, Henri. From mike.chase at alternatemetaverse.com Fri Jul 24 07:13:59 2015 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Fri, 24 Jul 2015 10:13:59 -0400 Subject: [opensource-dev] Building GTK+ and friends with autobuild new tools In-Reply-To: <20150724101650.177d1ea7.sldev@free.fr> References: <55A5441D.4030309@lindenlab.com> <9587427.3e5BYgnbbE@kumiko> <20150723164923.0c2e9bb4.sldev@free.fr> <20150724101650.177d1ea7.sldev@free.fr> Message-ID: <55B24827.2010703@alternatemetaverse.com> On 07/24/2015 04:16 AM, Henri Beauchamp wrote: > On Thu, 23 Jul 2015 21:47:36 -0500, Nicky Perian wrote: > >> Thanks for taking time to provide a thoughtful reply. >> I agree, it is not a viewer for older distributions. > I don't consider 3 years old distributions as "old" ones... If you do, > then What would you say about Windows XP, Vista, or even Windows 7 ? > :-D Windows XP is EOL and anyone using it is asking for serious issues with security problems which won't ever be fixed. If you're running an older platform you should be grateful the vendor is willing to backport and handle security fixes. But when they call it EOL you only have yourself to blame if you continue running it and have issues. In the Linux space for most distros there is no "vendor" to even backport fixes since it community maintained in many cases. For Ubuntu if you are running an LTS release then yes its supported for a longer period. Which means you'll have the benefit of security fixes. 12.04 is April 2017. Should you upgrade to 14.04 LTS? Probably yes if only to get updates on apps that aren't simply security fixes. You can argue that a viewer should support older releases and to some degree I could agree with that. Truth is though that the hardware requirements of the viewer also change and anyone running on a machine more than a few years old isn't going to have the experience intended with the current software tech. So I personally prefer that releases target .. the actual target. Which IMO is 3-4years max. Hence as I said I think you can argue in the ubuntu case 12.04 but nothing earlier and for Windows I see absolutely zero benefit supporting Windows XP especially if its holding back support for newer releases. Just my 2 cents Mike From sldev at free.fr Sat Jul 25 06:50:15 2015 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 25 Jul 2015 15:50:15 +0200 Subject: [opensource-dev] CEF plugin for Linux builds, a recipe In-Reply-To: <20150709164627.e3e40589.sldev@free.fr> References: <20150709164627.e3e40589.sldev@free.fr> Message-ID: <20150725155015.278bf811.sldev@free.fr> Greetings, Here is an update about CEF3 for Linux (and Windows VS2010) builds. Since the (VS2013) Windows plugin moved to CEF v3.2357, so did I for the Linux plugin (it will not be said that Linux got inferior support than Windoze ! :-P). Note that rebuilding 3.2357 is even trickier than for 3.2272, mainly because of bugs in CEF3's and LLVM/clang/compiler-rt building systems. If you are definitely, irremediably, masochistic, and want to rebuild it yourself, then I wrote down a recipe, available here: http://sldev.free.fr/libraries/sources/cef-rebuild-steps.txt If you don't want to loose your time reinventing the wheel then you can just grab the rebuilt package from here: http://sldev.free.fr/libraries/sources/cef_binary_3.2357.1281.gd660177_linux32-no_tcmalloc.tar.bz2 I could also produce a VS2010 llceflib (meaning you won't need to update your TPV to use the "new build tools" for now). You will find here: http://sldev.free.fr/libraries/ the llceflib packages for both Linux and VS2010 (I'm not using a link to the packages themselves, because they might change every week, following the progresses on the CEF3 media plugin implementation). Finally, have a look here: http://sldev.free.fr/libraries/patches/ to see what needed to be modified in LL's llceflib so to implement it under Linux and make it compile under Windows with VS2010. I hereby license anything I put there as LGPL code, reusable by anyone if they so wish. Note that the llceflib version for Linux is now compiled on a clone of my usual build system for the Cool VL Viewer (I'm using a clone because I wanted to keep the original build system for non-CEF builds, so to avoid having them "poisonned" with stricter library version dependencies). That clone got the necessary updates to libX11, libXi and libnss3, so that CEF3 can be properly linked. Users of "old" (4+ years) Linux systems may still run the resulting binaries by adding to the viewer installation lib/ sub-directory a few libraries that I packaged and made available from here: http://sldev.free.fr/libraries/ See also the announcement on the Cool VL Viewer forum for details about what works and what still doesn't work in llceflib (Lindens might be interested by it too...): http://sldev.free.fr/forum/viewtopic.php?f=5&t=1543&p=7112#p7112 For people curious about how CEF3 fares when compared to QtWebKit, I released the Cool VL Viewer v1.26.15.0 today for this purpose (use the new "UseCEF" debug setting to switch between QtWebKit and CEF without even the need for a viewer restart). Henri.