From lists.secondlife.com at trap.wereanimal.net Thu Jul 3 13:27:33 2014 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Thu, 3 Jul 2014 16:27:33 -0400 Subject: [opensource-dev] Fw: [git] Include Jira Ticket Number in Commits, Please! Message-ID: <20140703162733.7f8cd56b@laptop> Begin forwarded message: Date: Wed, 02 Jul 2014 11:32:09 -0700 From: OnLive Jira Watcher Subject: [git] Include Jira Ticket Number in Commits, Please! This notice is to remind you that you need to include valid Jira ticket numbers in all of your Git commits! We encountered the following problems in your recent commits. Commits with no reference to any jira tickets: https://github.onlive.com/Engineering/ol-secondlife/commit/3a5fae14 Clean up and rework FMOD.cmake and FindFMOD.cmake FMOD.cmake: Move include(Prebuilt) to prebuilt section. It is only used for prebuilt anyway. set(FMOD_FIND_REQUIRED ON) due to FMOD variable is use elsewhere in cmake files. This behaviour is the same as openal. Remove redudent error messages and code due to above. Rework the logic to be more cleaner. Clean up whitespace. FindFMOD.cmake Remove redudent paths as cmake allready uses them as default. Use PATH_SUFFIXES instead. The above will result in cmake looking in a lot more places and can handle custom build setups better. Change FMOD to FMOD_FOUND. FMOD should not be change withen cmake. Whitespace cleanup. -- https://github.onlive.com/Engineering/ol-secondlife/commit/ef220319 Allow the passing of addational fmod lib names via FMOD_NAMES from the build envorment. This will allow one to pass via command line custom fmod lib names. ie: -DFMOD_NAMES:STRING:"fmod-4.44" ----- Commits which reference invalid Jira ticket numbers that don't exist or have already been closed: https://github.onlive.com/Engineering/ol-secondlife/commit/999f782a SNOW-746: Finished Google BreakPad cmake for standalone (transplanted from 5a7ee78d029e973084e28d0d23a7233e0d976dca) --HG-- extra : transplant_source : Z%7E%E7%8D%02%9E%970%84%E2%8D%0D%23%A7%23%3E%0D%97m%CA -- https://github.onlive.com/Engineering/ol-secondlife/commit/a6def839 VWR-20893: "class Linux_x86_64Manifest" missing from viewer_manifest.py Breaking linux 64-bit build. (transplanted from 111a293c0e1c9062b1aa83dda7cf28aa22754930) --HG-- extra : transplant_source : %11%1A%29%3C%0E%1C%90b%B1%AA%83%DD%A7%CF%28%AA%22uI0 -- https://github.onlive.com/Engineering/ol-secondlife/commit/5ff89857 SNOW-599/SNOW-747: Pulseaudio should be optional on Linux. ----- Please be more careful in future commits. For information about installing the local onlive git hooks, which can help you remember, see https://wiki.onlive.com/display/DOCS/OnLive+Git+Hooks From kf6kjg at gmail.com Thu Jul 3 21:14:19 2014 From: kf6kjg at gmail.com (Ricky) Date: Thu, 3 Jul 2014 21:14:19 -0700 Subject: [opensource-dev] Fw: [git] Include Jira Ticket Number in Commits, Please! In-Reply-To: <20140703162733.7f8cd56b@laptop> References: <20140703162733.7f8cd56b@laptop> Message-ID: Techwolf trying to get SL on OnLive or something? An interesting idea - I wonder how badly the viewer would bog their servers with full draw distance in an avvie-loaded continent! On Thu, Jul 3, 2014 at 1:27 PM, wrote: > > > Begin forwarded message: > > Date: Wed, 02 Jul 2014 11:32:09 -0700 > From: OnLive Jira Watcher > Subject: [git] Include Jira Ticket Number in Commits, Please! > > > This notice is to remind you that you need to include valid Jira ticket > numbers in all of your Git commits! > > We encountered the following problems in your recent commits. > > Commits with no reference to any jira tickets: > > https://github.onlive.com/Engineering/ol-secondlife/commit/3a5fae14 > Clean up and rework FMOD.cmake and FindFMOD.cmake > FMOD.cmake: > Move include(Prebuilt) to prebuilt section. It is only used for > prebuilt anyway. set(FMOD_FIND_REQUIRED ON) due to FMOD variable is > use elsewhere in cmake files. This behaviour is the same as openal. > Remove redudent error messages and code due to above. Rework the > logic to be more cleaner. Clean up whitespace. > FindFMOD.cmake > Remove redudent paths as cmake allready uses them as default. > Use PATH_SUFFIXES instead. The above will result in cmake looking in > a lot more places and can handle custom build setups better. Change > FMOD to FMOD_FOUND. FMOD should not be change withen cmake. > Whitespace cleanup. -- > https://github.onlive.com/Engineering/ol-secondlife/commit/ef220319 > Allow the passing of addational fmod lib names via FMOD_NAMES from the > build envorment. This will allow one to pass via command line custom > fmod lib names. ie: -DFMOD_NAMES:STRING:"fmod-4.44" ----- Commits > which reference invalid Jira ticket numbers that don't exist or have > already been closed: > > https://github.onlive.com/Engineering/ol-secondlife/commit/999f782a > SNOW-746: Finished Google BreakPad cmake for standalone > (transplanted from 5a7ee78d029e973084e28d0d23a7233e0d976dca) > > --HG-- > extra : transplant_source : > Z%7E%E7%8D%02%9E%970%84%E2%8D%0D%23%A7%23%3E%0D%97m%CA -- > https://github.onlive.com/Engineering/ol-secondlife/commit/a6def839 > VWR-20893: "class Linux_x86_64Manifest" missing from viewer_manifest.py > Breaking linux 64-bit build. (transplanted from > 111a293c0e1c9062b1aa83dda7cf28aa22754930) > > --HG-- > extra : transplant_source : > %11%1A%29%3C%0E%1C%90b%B1%AA%83%DD%A7%CF%28%AA%22uI0 -- > https://github.onlive.com/Engineering/ol-secondlife/commit/5ff89857 > SNOW-599/SNOW-747: Pulseaudio should be optional on Linux. > ----- > > Please be more careful in future commits. > > For information about installing the local onlive git hooks, which can > help you remember, see > https://wiki.onlive.com/display/DOCS/OnLive+Git+Hooks > _______________________________________________ > 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/20140703/6229bb1b/attachment.htm From darien.caldwell at gmail.com Fri Jul 4 14:17:54 2014 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Fri, 4 Jul 2014 14:17:54 -0700 Subject: [opensource-dev] Fw: [git] Include Jira Ticket Number in Commits, Please! In-Reply-To: References: <20140703162733.7f8cd56b@laptop> Message-ID: http://community.secondlife.com/t5/Featured-News/Introducing-SL-Go-from-OnLive/ba-p/2528009 SL has been on Onlive for awhile now. I guess they have a special fork of the client for running on their servers. On Thu, Jul 3, 2014 at 9:14 PM, Ricky wrote: > Techwolf trying to get SL on OnLive or something? An interesting idea - I > wonder how badly the viewer would bog their servers with full draw distance > in an avvie-loaded continent! > > > On Thu, Jul 3, 2014 at 1:27 PM, > wrote: > >> >> >> Begin forwarded message: >> >> Date: Wed, 02 Jul 2014 11:32:09 -0700 >> From: OnLive Jira Watcher >> Subject: [git] Include Jira Ticket Number in Commits, Please! >> >> >> This notice is to remind you that you need to include valid Jira ticket >> numbers in all of your Git commits! >> >> We encountered the following problems in your recent commits. >> >> Commits with no reference to any jira tickets: >> >> https://github.onlive.com/Engineering/ol-secondlife/commit/3a5fae14 >> Clean up and rework FMOD.cmake and FindFMOD.cmake >> FMOD.cmake: >> Move include(Prebuilt) to prebuilt section. It is only used for >> prebuilt anyway. set(FMOD_FIND_REQUIRED ON) due to FMOD variable is >> use elsewhere in cmake files. This behaviour is the same as openal. >> Remove redudent error messages and code due to above. Rework the >> logic to be more cleaner. Clean up whitespace. >> FindFMOD.cmake >> Remove redudent paths as cmake allready uses them as default. >> Use PATH_SUFFIXES instead. The above will result in cmake looking in >> a lot more places and can handle custom build setups better. Change >> FMOD to FMOD_FOUND. FMOD should not be change withen cmake. >> Whitespace cleanup. -- >> https://github.onlive.com/Engineering/ol-secondlife/commit/ef220319 >> Allow the passing of addational fmod lib names via FMOD_NAMES from the >> build envorment. This will allow one to pass via command line custom >> fmod lib names. ie: -DFMOD_NAMES:STRING:"fmod-4.44" ----- Commits >> which reference invalid Jira ticket numbers that don't exist or have >> already been closed: >> >> https://github.onlive.com/Engineering/ol-secondlife/commit/999f782a >> SNOW-746 >> : >> Finished Google BreakPad cmake for standalone >> (transplanted from 5a7ee78d029e973084e28d0d23a7233e0d976dca) >> >> --HG-- >> extra : transplant_source : >> Z%7E%E7%8D%02%9E%970%84%E2%8D%0D%23%A7%23%3E%0D%97m%CA -- >> https://github.onlive.com/Engineering/ol-secondlife/commit/a6def839 >> VWR-20893 >> : >> "class Linux_x86_64Manifest" missing from viewer_manifest.py >> Breaking linux 64-bit build. (transplanted from >> 111a293c0e1c9062b1aa83dda7cf28aa22754930) >> >> --HG-- >> extra : transplant_source : >> %11%1A%29%3C%0E%1C%90b%B1%AA%83%DD%A7%CF%28%AA%22uI0 -- >> https://github.onlive.com/Engineering/ol-secondlife/commit/5ff89857 >> SNOW-599/SNOW-747 >> : >> Pulseaudio should be optional on Linux. >> ----- >> >> Please be more careful in future commits. >> >> For information about installing the local onlive git hooks, which can >> help you remember, see >> https://wiki.onlive.com/display/DOCS/OnLive+Git+Hooks >> _______________________________________________ >> 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 >> > > > _______________________________________________ > 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/20140704/103e70ca/attachment.htm From oz at lindenlab.com Thu Jul 10 10:03:27 2014 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 10 Jul 2014 13:03:27 -0400 Subject: [opensource-dev] Library Refresh viewer Message-ID: <53BEC75F.3090803@lindenlab.com> As many of you have seen, Monty has recently updated the versions of several of the libraries we use in the viewer. We've now published a Project viewer with those changes: https://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#Second_Life_Project_Refresh_Channel Any testing you can do with that viewer would be a big help. The viewer repository for that is: https://bitbucket.org/monty_linden/viewer-library-refresh And there are notes on the library changes, with pointers to the repositories at in 3rd Party Library Upgrade - Full Release Notes . -- *Scott Lawrence* | /Technical Director, Second Life/ Skype ozlinden | Second Life Oz Linden Linden Lab| Makers of Shared Creative Spaces Check out what we're working on! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140710/0cd48f3c/attachment.htm From sldev at free.fr Tue Jul 15 07:59:27 2014 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 15 Jul 2014 16:59:27 +0200 Subject: [opensource-dev] Library Refresh viewer In-Reply-To: <53BEC75F.3090803@lindenlab.com> References: <53BEC75F.3090803@lindenlab.com> Message-ID: <20140715165927.a70155d5.sldev@free.fr> On Thu, 10 Jul 2014 13:03:27 -0400, Oz Linden (Scott Lawrence) wrote: > As many of you have seen, Monty has recently updated the versions of > several of the libraries we use in the viewer. We've now published a > Project viewer with those changes: > > https://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#Second_Life_Project_Refresh_Channel > > Any testing you can do with that viewer would be a big help. When checking for the system libraries that the viewer depends on, on my main Linux system (Rosa Marathon 2012), I get this: # LD_LIBRARY_PATH="`pwd`/lib:$LD_LIBRARY_PATH" ldd bin/do-not-directly-run-secondlife-bin | sort | grep -v Second_Life_Project_Refresh libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb3bd6000) libbz2.so.1 => /usr/lib/libbz2.so.1 (0xb665a000) <--- (1) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb3c03000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb3a0c000) libc.so.6 => /lib/i686/libc.so.6 (0xb6683000) libdl.so.2 => /lib/libdl.so.2 (0xb69e5000) libffi.so.5 => /usr/lib/libffi.so.5 (0xb6653000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb69af000) <--- (3) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb76a2000) <--- (3) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb6800000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb3e11000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb6e79000) libgio-2.0.so.0 => /lib/libgio-2.0.so.0 (0xb3cbc000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xb74f5000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb736a000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7482000) libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0xb3ba3000) libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0xb75ed000) libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0xb6e76000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb6a15000) /lib/ld-linux.so.2 (0xb77cd000) libm.so.6 => /lib/i686/libm.so.6 (0xb681e000) libnvidia-glcore.so.340.24 => /usr/lib/libnvidia-glcore.so.340.24 (0xb407d000) libnvidia-tls.so.340.24 => /usr/lib/tls/libnvidia-tls.so.340.24 (0xb6610000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb3e6d000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb3eb8000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb3ba8000) libpcre.so.0 => /usr/lib/libpcre.so.0 (0xb6615000) <--- (3) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb391f000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb39bb000) <--- (2) libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb7736000) libresolv.so.2 => /lib/libresolv.so.2 (0xb39a2000) librt.so.1 => /lib/i686/librt.so.1 (0xb7698000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6848000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7230000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb3a08000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb404a000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb3e40000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb3e44000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb3e3b000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb3a01000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb406a000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb3e35000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb3e68000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb3e58000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb3a56000) <--- (2) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb3e4f000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb3bf7000) libz.so.1 => /usr/lib/libz.so.1 (0xb666b000) <--- (3) linux-gate.so.1 => (0xb77cc000) The "<---" indicate issues with libraries that should (or would better not) not appear, since static versions were linked to the viewer at compile time, with: (1) may be only consumed by /usr/lib/libfreetype.so.6 (2) consumed by the system's GTK+ v2 libraries (3) unknown, probably multiple consumers. Some dependencies are second level ones that result from the fact that the v3 viewer still uses the GTK+ libraries, but may still cause issues, such as with libpng (v1.2 on the system, v1.6 in the statically linked library used by the viewer: this is often the cause for crashes in the GTK+ file selector), thus why I got rid of that GTK+ dependency in the Cool VL Viewer... Once the new libraries adopted and code changes backported to the Cool VL Viewer, I get this list of dependencies: # LD_LIBRARY_PATH="`pwd`/lib:$LD_LIBRARY_PATH" ldd bin/cool_vl_viewer-bin | sort | grep -v CoolVLViewer libbz2.so.1 => /usr/lib/libbz2.so.1 (0xb41bf000) <--- (1) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb41f4000) libc.so.6 => /lib/i686/libc.so.6 (0xb6bb2000) libdl.so.2 => /lib/libdl.so.2 (0xb6e64000) libffi.so.5 => /usr/lib/libffi.so.5 (0xb6bab000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6f21000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb438b000) <--- (3) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb6d2f000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xb75a8000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb741e000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7535000) libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0xb76a1000) libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0xb6f1e000) /lib/ld-linux.so.2 (0xb7776000) libm.so.6 => /lib/i686/libm.so.6 (0xb6d4c000) libnvidia-glcore.so.340.24 => /usr/lib/libnvidia-glcore.so.340.24 (0xb45d5000) libnvidia-tls.so.340.24 => /usr/lib/tls/libnvidia-tls.so.340.24 (0xb6b68000) libpcre.so.0 => /usr/lib/libpcre.so.0 (0xb6b6d000) <--- (3) libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb6e94000) librt.so.1 => /lib/i686/librt.so.1 (0xb76ef000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6d76000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb72e4000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb41f0000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb45a2000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb41e9000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb45c2000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb423e000) <--- (3) libz.so.1 => /usr/lib/libz.so.1 (0xb41d1000) <--- (3) linux-gate.so.1 => (0xb7775000) That's much better (thanks to the absence of the old GTK+ v2 stuff), but there are still issues with libfreetype (and associated libbz2), libz, libxml2 and (new when compared to binaries compiled with the old set of libraries), with libpcre (which used to be distributed with the viewer, in its lib/ directory). Note that I did not point the libfontconfig.so.1 line because I don't distribute it with the Cool VL Viewer package (including it in the viewer's lib/ directory caused issues for some users in the past, and libfontconfig is pretty much an universal pre-requisite on any Linux distro, meaning it's always present in /usr/lib). This raises the question whether or not using static libraries to compile the viewer, for the ones that might conflict with their dynamic counterparts that get loaded at runtime anyway (especially libpcre, libxml2 and libz)... Henri. From sldev at free.fr Tue Jul 15 09:52:01 2014 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 15 Jul 2014 18:52:01 +0200 Subject: [opensource-dev] Source for the Experience Tools project viewer Message-ID: <20140715185201.3a26f7c4.sldev@free.fr> Greetings, Could we please get public access to the Experience Tools project viewer ? The repository is listed in https://wiki.secondlife.com/wiki/Linden_Lab_Official:Viewer_Source_Repositories but it's a private repo... Henri. From monty at lindenlab.com Tue Jul 15 10:30:18 2014 From: monty at lindenlab.com (Monty Brandenberg) Date: Tue, 15 Jul 2014 13:30:18 -0400 Subject: [opensource-dev] Library Refresh viewer In-Reply-To: <20140715165927.a70155d5.sldev@free.fr> References: <53BEC75F.3090803@lindenlab.com> <20140715165927.a70155d5.sldev@free.fr> Message-ID: <53C5652A.4080207@lindenlab.com> On 7/15/2014 10:59 AM, Henri Beauchamp wrote: > This raises the question whether or not using static libraries to > compile the viewer, for the ones that might conflict with their > dynamic counterparts that get loaded at runtime anyway (especially > libpcre, libxml2 and libz)... Yes, it does raise the question. I talk about this in the new doc file indra/cmake/00-COMPILE-LINK-RUN.txt (lousy name but collates to the top in my locale). With Linux, I'm stuck with a flat symbol resolution process at startup. I am managing this a bit in ZLIB.cmake and PNG.cmake with --whole-archive options forcing the new libraries to be authoritative. That leaves open the question of backwards incompatibility for shared libraries built against an old version of an API getting symbols resolved with a new API . I don't have a magic solution for that. There is plenty of potential here for incompatibility even with C APIs. Both zlib and libpng have a history of structure non-opacity. But the approach is to test for compatibility and then try to deal with actual problems as they arise. None of the solutions here is particularly attractive but ensuring that run-time version is not less than compile-time version gives us a chance. m -- 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 sldev at free.fr Tue Jul 15 11:01:21 2014 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 15 Jul 2014 20:01:21 +0200 Subject: [opensource-dev] Library Refresh viewer In-Reply-To: <53C5652A.4080207@lindenlab.com> References: <53BEC75F.3090803@lindenlab.com> <20140715165927.a70155d5.sldev@free.fr> <53C5652A.4080207@lindenlab.com> Message-ID: <20140715200121.c81ba742.sldev@free.fr> On Tue, 15 Jul 2014 13:30:18 -0400, Monty Brandenberg wrote: > None of the solutions here is particularly attractive but ensuring > that run-time version is not less than compile-time version gives > us a chance. Agreed, but then we should make sure to compile the viewer against a version that is sufficiently "old" so that every currently used Linux distro got the same or a newer version installed... For example, in Linux Rosa 2012 case (a relatively recent distro, that will be kept mainted till 2017), libpcre.so.0 (PCRE v7.xx) is the system library. In this case, won't it be safer to use PCRE 7 instead of v8 for the static libarry linked to the viewer pre-built libraries (AFAIK, it's only libcolladadom) ?... Henri. From monty at lindenlab.com Tue Jul 15 11:23:24 2014 From: monty at lindenlab.com (Monty Brandenberg) Date: Tue, 15 Jul 2014 14:23:24 -0400 Subject: [opensource-dev] Library Refresh viewer In-Reply-To: <20140715200121.c81ba742.sldev@free.fr> References: <53BEC75F.3090803@lindenlab.com> <20140715165927.a70155d5.sldev@free.fr> <53C5652A.4080207@lindenlab.com> <20140715200121.c81ba742.sldev@free.fr> Message-ID: <53C5719C.9090605@lindenlab.com> On 7/15/2014 2:01 PM, Henri Beauchamp wrote: > Agreed, but then we should make sure to compile the viewer against > a version that is sufficiently "old" so that every currently used > Linux distro got the same or a newer version installed... For > example, in Linux Rosa 2012 case (a relatively recent distro, that > will be kept mainted till 2017), libpcre.so.0 (PCRE v7.xx) is the > system library. In this case, won't it be safer to use PCRE 7 > instead of v8 for the static libarry linked to the viewer pre-built > libraries (AFAIK, it's only libcolladadom) ?... When colladadom became a static library, the viewer actually lost a link-time dependency on pcre. It's still in the link, a dependency may come back should the colladadom compilation units that reference it be used in the future. But right now, this is a non-problem. If actual problems can be demonstrated on a supported platform, a library downgrade is one of the solutions available. Haven't needed to do that yet. -- 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 sldev at free.fr Tue Jul 15 15:01:00 2014 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 16 Jul 2014 00:01:00 +0200 Subject: [opensource-dev] Library Refresh viewer In-Reply-To: <53C5719C.9090605@lindenlab.com> References: <53BEC75F.3090803@lindenlab.com> <20140715165927.a70155d5.sldev@free.fr> <53C5652A.4080207@lindenlab.com> <20140715200121.c81ba742.sldev@free.fr> <53C5719C.9090605@lindenlab.com> Message-ID: <20140716000100.0a553bf9.sldev@free.fr> On Tue, 15 Jul 2014 14:23:24 -0400, Monty Brandenberg wrote: > If actual problems can be demonstrated on a supported platform, > a library downgrade is one of the solutions available. Haven't > needed to do that yet. Yes, so far, no problem detected here with the Cool VL Viewer when using the new libraries (but this viewer doesn't use GTK+ and some GTK+ related conflicts may exist in other viewers: in particular, people using the oxygen-gtk theme engine should try and see if they don't get a crash with the GTK file selector when selecting PNG images...). But I just noticed this (apparently harmless) new warning, appearing in the stderr stream (i.e. only seen when the viewer is ran from a terminal): QObject::startTimer: QTimer can only be used with threads started with QThread It also appears with LL's Second_Life_Refresh viewer. Henri. From monty at lindenlab.com Tue Jul 15 16:18:00 2014 From: monty at lindenlab.com (Monty Brandenberg) Date: Tue, 15 Jul 2014 19:18:00 -0400 Subject: [opensource-dev] Library Refresh viewer In-Reply-To: <20140716000100.0a553bf9.sldev@free.fr> References: <53BEC75F.3090803@lindenlab.com> <20140715165927.a70155d5.sldev@free.fr> <53C5652A.4080207@lindenlab.com> <20140715200121.c81ba742.sldev@free.fr> <53C5719C.9090605@lindenlab.com> <20140716000100.0a553bf9.sldev@free.fr> Message-ID: <53C5B6A8.5090206@lindenlab.com> On 7/15/2014 6:01 PM, Henri Beauchamp wrote: > But I just noticed this (apparently harmless) new warning, appearing > in the stderr stream (i.e. only seen when the viewer is ran from a > terminal): > QObject::startTimer: QTimer can only be used with threads started with QThread > > It also appears with LL's Second_Life_Refresh viewer. Qt is generally unhappy running in SLplugin. :-) Soooooo many warnings flying out stderr whenever the viewer is run from command line. -- 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 sldev at free.fr Wed Jul 16 07:01:53 2014 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 16 Jul 2014 16:01:53 +0200 Subject: [opensource-dev] Source for the Experience Tools project viewer In-Reply-To: <20140715185201.3a26f7c4.sldev@free.fr> References: <20140715185201.3a26f7c4.sldev@free.fr> Message-ID: <20140716160153.fa3383c9.sldev@free.fr> Thanks for having made the repository public ! :-) I just started the backport an can already see two bugs: In indra.l, the XP_ERROR_* constants should return integers, not strings... Granted, viewer side script compilation is deprecated, but since the code is still there, it should nonetheless be correct (or removed entirely). In llcompilequeue.cpp: LLScriptQueueData::mHost is never initialized, and the getInvItemAsset() call using it in LLFloaterCompileQueue::requestAsset() therefore passes an empty LLHost... Henri.