Re: [opensource-dev] library refresh viewer

[Nicky Perian]

Dumbness on my part, it was a package of the 1.52 boost to build 64 bit version.
It is headers only so likely not even required.




On Wednesday, August 13, 2014 12:37 PM, Monty Brandenberg  
wrote:
 

>
>
>On 8/12/2014 7:26 PM, Nicky Perian wrote:
>
>> 1. boost--
>> Is the openssl that is populated in 3p-boost-update the same version as
>> the one used by the viewer?
>> I'm thinking it comes from boost.
>
>No openssl distributed by Boost, just the asio library using it
>and SL shouldn't be using asio.  Asio also doesn't build any
>binary artifacts, other than test cases, so no symbol dependencies.
>When used, it will pick up whatever version is found in the build
>environment.
>
>-- 
>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!
>___
>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

Re: [opensource-dev] library refresh viewer

[Monty Brandenberg]

On 8/12/2014 7:26 PM, Nicky Perian wrote:
> 1. boost--
> Is the openssl that is populated in 3p-boost-update the same version as
> the one used by the viewer?
> I'm thinking it comes from boost.

No openssl distributed by Boost, just the asio library using it
and SL shouldn't be using asio.  Asio also doesn't build any
binary artifacts, other than test cases, so no symbol dependencies.
When used, it will pick up whatever version is found in the build
environment.

-- 
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!
___
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

[opensource-dev] library refresh viewer

[Nicky Perian]

1. boost--
Is the openssl that is populated in 3p-boost-update the same version as the one 
used by the viewer?
I'm thinking it comes from boost.

2. Kokua is built with gcc-4.7. linux 32 Slplugin.exe would not link with boost 
built with gcc-4.6.
Built boost with gcc-4.7 and there was no longer a link issue. But, stock SL 
viewer will not
build on gcc-4.7 anyway so, it will be sometime before LL sees that issue.

3. For TPV dev's using gcc-4.7 Kokua's archive for linux 32 bit boost (gcc-4.7) 
is at:
https://bitbucket.org/kokua/3p-boost-update/downloads


Nicky
___
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

Re: [opensource-dev] Library Refresh viewer

[Henri Beauchamp]

On Thu, 07 Aug 2014 01:51:58 -0400, Monty Brandenberg wrote:

> Checking in to see if anyone is seeing problems with the new
> libraries.  Crash reports have been mostly quiet and as
> expected.  No lurking horrors yet?

No problem whatsoever here: running the new library set under Linux
with the Cool VL Viewer for almost 4 weeks already, and Cool VL
Viewer users running the same set under both Linux and Windows for
almost three weeks... No bug report so far.

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

Re: [opensource-dev] Library Refresh viewer

[Monty Brandenberg]

Checking in to see if anyone is seeing problems with the new
libraries.  Crash reports have been mostly quiet and as
expected.  No lurking horrors yet?

m


___
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

Re: [opensource-dev] Library Refresh viewer

[Monty Brandenberg]

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.  :-)  Soo 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!
___
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

Re: [opensource-dev] Library Refresh viewer

[Henri Beauchamp]

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.
___
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

Re: [opensource-dev] Library Refresh viewer

[Monty Brandenberg]

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!
___
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

Re: [opensource-dev] Library Refresh viewer

[Henri Beauchamp]

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.
___
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

Re: [opensource-dev] Library Refresh viewer

[Monty Brandenberg]

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!
___
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

Re: [opensource-dev] Library Refresh viewer

[Henri Beauchamp]

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 (0xb680)
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 
(0xb661)
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 (0xb723)
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 (0xb3e4)
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

[opensource-dev] Library Refresh viewer

[Oz Linden (Scott Lawrence)]

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! 
___
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