Re: [opensource-dev] Linux viewer manage

[Alex]

On 2018-03-27 06:11, Oz Linden (Scott Lawrence) wrote:
> 
> That's dozens of changesets out of date.
> 
> I'll see what I can do about building a current one and make the
> result public.

Hi Oz,

While you are there, any chance you could refresh the fontconfig package 
for linux64? It is stale and needs a recompile (was the case when I 
checked about a week ago). version of the library itself is fine, but 
the package up on the server has incorrect dependency version references 
inside of it. I was able to fix this myself just by doing a recompile 
and the resulting package had correct dependencies. package: 
fontconfig-2.11.0-linux64-314281.tar.bz2

-- 
Kind Regards,
Alex.
___
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] Linux viewer manage

[Alex]

On 2018-03-27 03:23, Nicky Perian wrote:
> http://s3-proxy.lindenlab.com/private-builds-secondlife-com/ct2/3428/8686/viewer_manager-1.0-linux-503417.tar.bz2
> 
> Please public this. Just need to get past configure.
> 
> I know it will likely never be used. I want to keep as many files
> matching as possible.
> ___


I was able to clone the source for this and build the package on linux 
with not much effort. Easy enough from there to edit autobuild.xml and 
point it at your own package.

-- 
Kind Regards,
Alex.
___
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] Linux viewer manage

[Oz Linden (Scott Lawrence)]

On 2018-03-26 13:23 , Nicky Perian wrote:

http://s3-proxy.lindenlab.com/private-builds-secondlife-com/ct2/3428/8686/viewer_manager-1.0-linux-503417.tar.bz2

Please public this. Just need to get past configure.

I know it will likely never be used. I want to keep as many files 
matching as possible.


That's dozens of changesets out of date.

I'll see what I can do about building a current one and make the result 
public.


--
OZ LINDEN | Senior Director, Second Life Engineering
email or hangouts: o...@lindenlab.com  | Real 
Life: Scott Lawrence

LINDEN LAB | Create Virtual Experiences 
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Fri, 23 Mar 2018 09:50:12 +1000, Alex wrote:

> Well that certainly got me further! Thank you! Its' at least _trying_ to 
> start dullahan_host now, but some strange behavour:
> 
> alex@desktop:~/ivyviewer$ grep dullahan trace.txt | pcregrep -o1 
> '.*(execve\([a-z0-9\/_\"]+),'
> execve("/usr/local/sbin/dullahan_host"
> execve("/usr/local/bin/dullahan_host"
> execve("/usr/sbin/dullahan_host"
> execve("/usr/bin/dullahan_host"
> execve("/sbin/dullahan_host"
> execve("/bin/dullahan_host"
> execve("/usr/games/dullahan_host"
> execve("/usr/local/games/dullahan_host"
> execve("/snap/bin/dullahan_host"
> 
> It is trying to launch it from the wrong place... lol! I am guessing I 
> have failed to set some setting for dullahan somewhere or something 
> silly like that.
> 
> Looks like I have some more debugging to do.

Instead of reinventing the wheel, have a look at my sources for the Linux
Dullahan: http://sldev.free.fr/libraries/sources/

A 'grep -ri linux cvlv-dullahan/src/*' will quickly get you on the right
track for the needed changes, and a close look at dullahan_impl::init()
will give you all the needed settings clues.

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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-23 02:00, Henri Beauchamp wrote:
> #elif defined(__linux__)
> CefString(&settings.browser_subprocess_path) = "dullahan_host";
> #endif
> 
> 
> Henri.


Well that certainly got me further! Thank you! Its' at least _trying_ to 
start dullahan_host now, but some strange behavour:

alex@desktop:~/ivyviewer$ grep dullahan trace.txt | pcregrep -o1 
'.*(execve\([a-z0-9\/_\"]+),'
execve("/usr/local/sbin/dullahan_host"
execve("/usr/local/bin/dullahan_host"
execve("/usr/sbin/dullahan_host"
execve("/usr/bin/dullahan_host"
execve("/sbin/dullahan_host"
execve("/bin/dullahan_host"
execve("/usr/games/dullahan_host"
execve("/usr/local/games/dullahan_host"
execve("/snap/bin/dullahan_host"

It is trying to launch it from the wrong place... lol! I am guessing I 
have failed to set some setting for dullahan somewhere or something 
silly like that.

Looks like I have some more debugging to do.

-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-23 02:00, Henri Beauchamp wrote:
> On Fri, 23 Mar 2018 01:48:08 +1000, Alex wrote:
> 
>> It does indeed sound like the viewer is subsequently spawning another
>> SLPlugin instead of dullahan_host, you are right. I have no idea why 
>> the
>> viewer would be doing that. From what I am aware, the viewer _should_
>> start one instance of SLPlugin and dullahan_host when its at the login
>> screen.
>> 
>> Do you have a rough idea (assuming the standard LL viewer behavior)
>> where these processes get launched from on startup (which part of the
>> viewer code)?
> 
> In fact, the viewer (and SLPlugin) code itself got no knowlegde of
> dullahan_host: the latter is launched (and gets passed arguments) by
> CEF, from a setting given in dullahan_impl.cpp, in 
> dullahan_impl::init()
> 
> My guess is that your plugin lacks a #elif defined(__linux__) and the
> corresponding CefString(&settings.browser_subprocess_path) there.
> Here is what I put in mine:
> #elif defined(__linux__)
> CefString(&settings.browser_subprocess_path) = "dullahan_host";
> #endif
> 
> Henri.

Ahhh!!! Thats going to be what it is for sure! I am missing that part in 
mine.. and it explains why I found no reference to the dullahan_host in 
my strace data.. Not even attempt to start it. It all makes sense now.

Thank you so much! I'll rebuild the plugin and the viewer and see how 
that goes.

-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Fri, 23 Mar 2018 01:48:08 +1000, Alex wrote:

> It does indeed sound like the viewer is subsequently spawning another 
> SLPlugin instead of dullahan_host, you are right. I have no idea why the 
> viewer would be doing that. From what I am aware, the viewer _should_ 
> start one instance of SLPlugin and dullahan_host when its at the login 
> screen.
> 
> Do you have a rough idea (assuming the standard LL viewer behavior) 
> where these processes get launched from on startup (which part of the 
> viewer code)?

In fact, the viewer (and SLPlugin) code itself got no knowlegde of
dullahan_host: the latter is launched (and gets passed arguments) by
CEF, from a setting given in dullahan_impl.cpp, in dullahan_impl::init()

My guess is that your plugin lacks a #elif defined(__linux__) and the
corresponding CefString(&settings.browser_subprocess_path) there.
Here is what I put in mine:

bool dullahan_impl::init(dullahan::dullahan_settings& user_settings)
{
DLNOUT("dullahan_impl::init()");

#ifdef WIN32
CefMainArgs args(GetModuleHandle(nullptr));
#else
CefMainArgs args(0, nullptr);
#endif

CefSettings settings;

// point to host application
#ifdef WIN32
CefString(&settings.browser_subprocess_path) = "dullahan_host.exe";
#elif __APPLE__
NSString* appBundlePath = [[NSBundle mainBundle] bundlePath];
CefString(&settings.browser_subprocess_path) =
[[NSString stringWithFormat:
  
@"%@/Contents/Frameworks/DullahanHelper.app/Contents/MacOS/DullahanHelper", 
appBundlePath] UTF8String];
#elif defined(__linux__)
CefString(&settings.browser_subprocess_path) = "dullahan_host";
#endif

// Do not bother with the stupid sandbox which keeps failing under Windows
// and which must be set UID root under Linux...
settings.no_sandbox = true;

.../...


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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-23 01:36, Henri Beauchamp wrote:
> On Thu, 22 Mar 2018 16:31:29 +0100, Henri Beauchamp wrote:
> 
>> In my viewer, SLPlugin is never passed any other argument than the 
>> port,
>> so maybe these arguments you see passed are an "extension" to 
>> Firestorm's
>> plugin system...
> 
> In fact, looking at the processes for a viewer on at login sceen step, 
> I get:
> 
>  4283 ?S  0:00 /bin/bash
> /usr/local/CoolVLViewer-1.26.21/cool_vl_viewer
>  4309 ?SLl0:02 ./bin/cool_vl_viewer-bin
>  4326 ?Sl 0:00
> /usr/local/CoolVLViewer-1.26.21/bin/llplugin/SLPlugin 41321
>  4330 ?S  0:00
> /usr/local/CoolVLViewer-1.26.21/bin/llplugin/dullahan_host
> --type=zygote --no-sandbox --log-file=/root/.secondlife/
> --product-version=(Dullahan:1.1.1080 [64bit] - SecondLife/1.26.21.14
> (Cool VL Viewer; default skin))  Chrome/65.0.3325.146 [64bit] -
>  4356 ?Sl 0:00
> /usr/local/CoolVLViewer-1.26.21/bin/llplugin/dullahan_host
> --type=renderer --no-sandbox --disable-gpu-compositing
> --service-pipe-token=3FECC7FC7B452E7F87FF8F85FB58EB32 --lang=en-US
> --log-file=/root/.secondlife/ --product-version=(Dullahan:1.1.1080
>  4357 ?Sl 0:00 dullahan_host --type=gpu-process
> --no-sandbox --log-file=/root/.secondlife/
> --product-version=(Dullahan:1.1.1080 [64bit] - SecondLife/1.26.21.14
> (Cool VL Viewer; default skin))  Chrome/65.0.3325.146 [64bit]
> --lang=en-US --gpu-preferences=KA
> 
> 
> So, the argument you are seeing are actually dullahan_host ones !
> 
> Could it be that your viewer launches SLPlugin instead of dullahan_host 
> ?
> 
> Henri.

Thats bizarre... Those arguments I saw in strace are what is appearing 
in your dullahan_host process.

Nobody has dullahan working on FS for Linux that I am aware of, so I am 
stepping into uncharted waters.

It does indeed sound like the viewer is subsequently spawning another 
SLPlugin instead of dullahan_host, you are right. I have no idea why the 
viewer would be doing that. From what I am aware, the viewer _should_ 
start one instance of SLPlugin and dullahan_host when its at the login 
screen.

Do you have a rough idea (assuming the standard LL viewer behavior) 
where these processes get launched from on startup (which part of the 
viewer code)?

-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Thu, 22 Mar 2018 16:31:29 +0100, Henri Beauchamp wrote:

> In my viewer, SLPlugin is never passed any other argument than the port,
> so maybe these arguments you see passed are an "extension" to Firestorm's
> plugin system...

In fact, looking at the processes for a viewer on at login sceen step, I get:

 4283 ?S  0:00 /bin/bash 
/usr/local/CoolVLViewer-1.26.21/cool_vl_viewer
 4309 ?SLl0:02 ./bin/cool_vl_viewer-bin
 4326 ?Sl 0:00 
/usr/local/CoolVLViewer-1.26.21/bin/llplugin/SLPlugin 41321
 4330 ?S  0:00 
/usr/local/CoolVLViewer-1.26.21/bin/llplugin/dullahan_host --type=zygote 
--no-sandbox --log-file=/root/.secondlife/ --product-version=(Dullahan:1.1.1080 
[64bit] - SecondLife/1.26.21.14 (Cool VL Viewer; default skin))  
Chrome/65.0.3325.146 [64bit] -
 4356 ?Sl 0:00 
/usr/local/CoolVLViewer-1.26.21/bin/llplugin/dullahan_host --type=renderer 
--no-sandbox --disable-gpu-compositing 
--service-pipe-token=3FECC7FC7B452E7F87FF8F85FB58EB32 --lang=en-US 
--log-file=/root/.secondlife/ --product-version=(Dullahan:1.1.1080 
 4357 ?Sl 0:00 dullahan_host --type=gpu-process --no-sandbox 
--log-file=/root/.secondlife/ --product-version=(Dullahan:1.1.1080 [64bit] - 
SecondLife/1.26.21.14 (Cool VL Viewer; default skin))  Chrome/65.0.3325.146 
[64bit] --lang=en-US --gpu-preferences=KA


So, the argument you are seeing are actually dullahan_host ones !

Could it be that your viewer launches SLPlugin instead of dullahan_host ?

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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Thu, 22 Mar 2018 23:39:51 +1000, Alex wrote:

> 2018-03-22T10:08:12Z llplugin/slplugin/slplugin.cpp(194) : error
> 2018-03-22T10:08:12Z ERROR: llplugin/slplugin/slplugin.cpp(194) : main: 
> port number must be numeric
> .../...
> 4589 execve("/home/alex/ivyviewer/bin/SLPlugin", 
> ["/home/alex/ivyviewer/bin/SLPlugin", "38655"], [/ 66 vars /]
> 
> 4592 execve("/home/alex/ivyviewer/bin/SLPlugin", 
> ["/home/alex/ivyviewer/bin/SLPlugin", "--type=zygote", "--lang=en-US", 
> "--log-file=/home/alex/ivyviewer/bin/debug.log", 
> "--product-version=(Dullahan:1.1.820 [64bit] - SecondLife/5.1.3.54978 
> (Firestorm-private-x64build; firestorm skin)) Chrome/59.0."...], [/ 69 
> vars /]
> 
> I am seeing SLPlugin called once correctly, with the port number it 
> expects, then it is being called a second time with data that it is not 
> expecting, thus the error condition is triggered in slplugin.cpp
> 
> I know this is a bit of a shot in the dark but can you think of any 
> possibilities why this could happen?

Hard to tell without having the sources to look at, but to me, it would
appear like an arguments quoting or missing argument issue in the command
line passed to SLPlugin...

In my viewer, SLPlugin is never passed any other argument than the port,
so maybe these arguments you see passed are an "extension" to Firestorm's
plugin system...

You'll have to follow the track in the code, starting from LLViewerMedia,
then LLPluginClassMedia, LLPluginProcessParent, LLProcessLauncher, etc...

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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-21 19:30, Henri Beauchamp wrote:
> Yes, under Linux, ld uses the provided library  and searches for
> , lib.so, lib.a, etc...
> 
> But your problem was related to a bad call in your plugin (did you read
> my message dated Wed, 21 Mar 2018 00:43:41 +0100 ?).

Hi Henri,

I saw it. Ive resolved the loading issues of the plugin not loading. I 
no longer see symbol errors.

I have no working media still which is strange. I did notice an error in 
the log which looked suspicious so hopefully I am going down the right 
path here with troubleshooting it...

I notice there are no instances of SLPlugin running when my viewer 
starts, or any instance of dullahan_host, that immediately got me 
suspicious.

This is the error I saw in the log:

2018-03-22T10:08:12Z llplugin/slplugin/slplugin.cpp(194) : error
2018-03-22T10:08:12Z ERROR: llplugin/slplugin/slplugin.cpp(194) : main: 
port number must be numeric


I've looked at the code in slplugin.cpp and see this:
#elif LL_DARWIN || LL_LINUX
 if(argc < 2)
 {
 LL_ERRS("slplugin") << "usage: " << argv[0] << " 
launcher_port" << LL_ENDL;
 }

 U32 port = 0;
 if(!LLStringUtil::convertToU32(argv[1], port))
 {
 LL_ERRS("slplugin") << "port number must be numeric" << 
LL_ENDL;
 }

So the argc count is being satisfied... and obviously some parameter is 
being sent that obviously is not numeric and throwing the error.

I ran the viewer under strace and observed some interesting behavior:


4589 execve("/home/alex/ivyviewer/bin/SLPlugin", 
["/home/alex/ivyviewer/bin/SLPlugin", "38655"], [/ 66 vars /]

4592 execve("/home/alex/ivyviewer/bin/SLPlugin", 
["/home/alex/ivyviewer/bin/SLPlugin", "--type=zygote", "--lang=en-US", 
"--log-file=/home/alex/ivyviewer/bin/debug.log", 
"--product-version=(Dullahan:1.1.820 [64bit] - SecondLife/5.1.3.54978 
(Firestorm-private-x64build; firestorm skin)) Chrome/59.0."...], [/ 69 
vars /]

I am seeing SLPlugin called once correctly, with the port number it 
expects, then it is being called a second time with data that it is not 
expecting, thus the error condition is triggered in slplugin.cpp

I know this is a bit of a shot in the dark but can you think of any 
possibilities why this could happen?

Just thought I would ask since I am all out of ideas at this point.


-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Wed, 21 Mar 2018 16:59:58 +1000, Alex wrote:

> Just a quick question about the above. In the list for 
> target_link_libraries, the first two make sense to me, but what is 'cef' 
> referring to? is it libcef.so?

Yes, under Linux, ld uses the provided library  and searches for
, lib.so, lib.a, etc...

But your problem was related to a bad call in your plugin (did you read
my message dated Wed, 21 Mar 2018 00:43:41 +0100 ?).

In media_plugin_cef.cpp, simply replace the calls to:
set*Callback(boost:bind(&MediaPluginCEF::on*Callback..., _1, ...))
with:
set*Callback(std:bind(&MediaPluginCEF::on*Callback,
  std::placeholders::_1, ...))

Or (to keep the boost interface and C++98 compatibility) use my plugin
and Dullahan versions, but you can't mix LL's C++11 Dullahan with the old
boost-wrapped calls in the CEF plugin.

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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-20 23:28, Henri Beauchamp wrote:
> Or... This could be an issue in how you linked libdullahan.a and/or
> dullahan_host... In the Dullahan Cmake file, check for the proper
> ordering in target link libraries:
> 
> target_link_libraries(dullahan_host cef_dll_wrapper cef)

Just a quick question about the above. In the list for 
target_link_libraries, the first two make sense to me, but what is 'cef' 
referring to? is it libcef.so?

-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Wed, 21 Mar 2018 09:38:07 +1000, Alex wrote:

> libmedia_plugin_cef.so:00114cd0 T 
> dullahan::setOnStatusMessageCallback(boost::function (std::string)>)
> libmedia_plugin_cef.so: U 
> dullahan::setOnStatusMessageCallback(std::function)

The problem is that the dullahan::setOnStatusMessageCallback() definition
is using  ***boost::function*** and the plugin is calling
dullahan::setOnStatusMessageCallback(***std::function***)

So, the plugin is searching for another method than the one linked together
with libdullhana.a...

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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-21 09:33, Henri Beauchamp wrote:
> 
> It lists:
> U _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE
> 
> So it indeed shows that the libdullahan.a library did not get properly
> linked to your plugin...
> 
> Henri.

Ah! You're right:

nm --print-file-name -C libmedia_plugin_cef.so | grep 
setOnStatusMessageCallback
libmedia_plugin_cef.so:0011ecf0 T 
dullahan_callback_manager::setOnStatusMessageCallback(std::function)
libmedia_plugin_cef.so:00114cd0 T 
dullahan::setOnStatusMessageCallback(boost::function)
libmedia_plugin_cef.so: U 
dullahan::setOnStatusMessageCallback(std::function)

A lot easier to read.

Would this suggest that the libdullahan.a library itself I am trying to 
link against is fine and there is a problem with the viewer build 
configuration somewhere?


-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Wed, 21 Mar 2018 08:58:55 +1000, Alex wrote:

> On 2018-03-21 07:57, monty wrote:
>
> > 'nm' that thing and see what is definition and what is reference.
> 
> I pasted the result here:
> 
> https://pastebin.com/BZyKEJf2
> 
> command used: nm --print-file-name -u libmedia_plugin_cef.so

With the -C option you would get more readable, demangled symbols...

> Lots of undefined symbols... So this means there is a reference but no 
> definition?

It lists:
U _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE

So it indeed shows that the libdullahan.a library did not get properly
linked to your plugin...

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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Wed, 21 Mar 2018 07:32:08 +1000, Alex wrote:

> On 2018-03-21 04:10, Henri Beauchamp wrote:
> > But only twice... I get it listed thrice in my plugin...
> > strings 
> > /usr/local/CoolVLViewer-1.26.21/bin/llplugin/media_plugin_cef.so |
> > grep _ZN8dullahan26setOnStatusMessageCallback
> > _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE
> > _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE
> > _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE
> > 
> > (there's "boost" because I "re-boostified" Dullhan's interface for
> > C++98 compatibility).
> 
> Ah. But in the case of boost and dullahan, it was making use of header 
> only parts of boost right?

Yes, only templates from the three boost/function.hpp, boost/bind.hpp and
boost/move/unique_ptr.hpp headers are used.

> Relinking libcef twice didnt help sadly.. I gave up for the night and 
> went to sleep hehe. Do you have any ideas what else might be causing it?

Beside a linking problem (either in libdullahan.a itself or in the plugin),
I'm short of ideas...


> On 3/20/2018 17:32, Alex wrote:
>
> > Interesting that that symbol is defined 3 times in your library.
> 
> 'nm' that thing and see what is definition and what is reference.

AFAIK, nm only lists exported symbols (i.e. the entries for the
definitions), not their invocations from another linked module (the
references).

nm -C /usr/local/CoolVLViewer-1.26.21/bin/llplugin/media_plugin_cef.so | grep 
setOnStatusMessageCallback
000ed710 T 
dullahan_callback_manager::setOnStatusMessageCallback(std::function)
000e4090 T dullahan::setOnStatusMessageCallback(boost::function)

These correspond to the two definitions of the homonymous methods in
the Dullahan's library classes 'dullahan' and 'dullahan_callback_manager',
but nm does not list the call to dullahan::setOnStatusMessageCallback()
from media_plugin_cef.cpp, which should correspond to the third string
in media_plugin_cef.so.

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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

> On 2018-03-21 07:57, monty wrote:
>> 'nm' that thing and see what is definition and what is reference.

nm --print-file-name libmedia_plugin_cef.so | grep 
setOnStatusMessageCallback
libmedia_plugin_cef.so:0011ecf0 T 
_ZN25dullahan_callback_manager26setOnStatusMessageCallbackESt8functionIFvSsEE
libmedia_plugin_cef.so:00114cd0 T 
_ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE
libmedia_plugin_cef.so: U 
_ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE

-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-21 07:57, monty wrote:
> On 3/20/2018 17:32, Alex wrote:
>> 
>> Interesting that that symbol is defined 3 times in your library.
>> 
> 
> 'nm' that thing and see what is definition and what is reference.

I pasted the result here:

https://pastebin.com/BZyKEJf2

command used: nm --print-file-name -u libmedia_plugin_cef.so

Lots of undefined symbols... So this means there is a reference but no 
definition?



-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[monty]

On 3/20/2018 17:32, Alex wrote:
> 
> Interesting that that symbol is defined 3 times in your library.
> 

'nm' that thing and see what is definition and what is reference.

___
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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-21 04:10, Henri Beauchamp wrote:
> But only twice... I get it listed thrice in my plugin...
> strings 
> /usr/local/CoolVLViewer-1.26.21/bin/llplugin/media_plugin_cef.so |
> grep _ZN8dullahan26setOnStatusMessageCallback
> _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE
> _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE
> _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE
> 
> (there's "boost" because I "re-boostified" Dullhan's interface for
> C++98 compatibility).

Ah. But in the case of boost and dullahan, it was making use of header 
only parts of boost right?

Relinking libcef twice didnt help sadly.. I gave up for the night and 
went to sleep hehe. Do you have any ideas what else might be causing it? 
:)

Interesting that that symbol is defined 3 times in your library.

-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Tue, 20 Mar 2018 22:30:14 +1000, Alex wrote:

> On 2018-03-20 22:00, Alex wrote:
> > 2018-03-20T11:53:39Z WARNING: LLPluginInstance::load: apr_dso_load of
> > /home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so failed with
> > error 20019 , additional info string:
> > /home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so: undefined
> > symbol: _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE
> > 
> > Any ideas what might be behind this one?
> 
> Something I noticed:
> 
> alex@desktop:~/ivyviewer/bin/llplugin$ strings libmedia_plugin_cef.so | 
> grep ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE
> _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE
> _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE
> 
> The symbol is there...

But only twice... I get it listed thrice in my plugin...
strings /usr/local/CoolVLViewer-1.26.21/bin/llplugin/media_plugin_cef.so |
grep _ZN8dullahan26setOnStatusMessageCallback
_ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE
_ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE
_ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE

(there's "boost" because I "re-boostified" Dullhan's interface for
C++98 compatibility).

So, it looks indeed like a linking issue even though:

On Tue, 20 Mar 2018 23:20:59 +1000, Alex wrote:
 
> gcc/g++ version 4.9.4
> GNU ld (GNU Binutils for Ubuntu) 2.29.1

Using the same versions here, for personal builds, with no issue
whatsoever.

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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-20 23:28, Henri Beauchamp wrote:
> On Tue, 20 Mar 2018 14:15:09 +0100, Henri Beauchamp wrote:
> 
>> Looks fine to me... Putting the blame on a buggy ld, you could try 
>> this
>> trick (specifying libcef.so twice for linking) in CEFPlugin.cmake:
> 
> Or... This could be an issue in how you linked libdullahan.a and/or
> dullahan_host... In the Dullahan Cmake file, check for the proper
> ordering in target link libraries:
> 
> target_link_libraries(dullahan_host cef_dll_wrapper cef)

The ordering in the dullahan cmake file looks the same as above :)

I'll try the trick with linking libcef twice and see what happens :)

Thank you :)



-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Tue, 20 Mar 2018 14:15:09 +0100, Henri Beauchamp wrote:

> Looks fine to me... Putting the blame on a buggy ld, you could try this
> trick (specifying libcef.so twice for linking) in CEFPlugin.cmake:

Or... This could be an issue in how you linked libdullahan.a and/or
dullahan_host... In the Dullahan Cmake file, check for the proper
ordering in target link libraries:

target_link_libraries(dullahan_host cef_dll_wrapper cef)


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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-20 23:15, Henri Beauchamp wrote:
> What is your Linux build system ?

Ubuntu 17.10 64 bit

gcc/g++ version 4.9.4
GNU ld (GNU Binutils for Ubuntu) 2.29.1

-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Tue, 20 Mar 2018 22:48:05 +1000, Alex wrote:

> I couldn't spot a problem in either of those files, but my eyes might 
> have missed something.
> 
> Does anything stand out at you:
> 
> https://pastebin.com/c7wRQik8 (indra/cmake/CEFPlugin.cmake)
> https://pastebin.com/ZhytizN8 (indra/media_plugins/cef/CMakeLists.txt)

Looks fine to me... Putting the blame on a buggy ld, you could try this
trick (specifying libcef.so twice for linking) in CEFPlugin.cmake:

.../...
elseif (LINUX)
  set(CEF_PLUGIN_LIBRARIES
  ${ARCH_PREBUILT_DIRS_RELEASE}/libcef.so
  -Wl,-whole-archive
  ${ARCH_PREBUILT_DIRS_RELEASE}/libcef_dll_wrapper.a
  ${ARCH_PREBUILT_DIRS_RELEASE}/libdullahan.a
  -Wl,-no-whole-archive
  ${ARCH_PREBUILT_DIRS_RELEASE}/libcef.so
  )
endif (WINDOWS)

What is your Linux build system ?

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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-20 22:33, Henri Beauchamp wrote:
> 
> Apparently a failure to properly link libdullahan.a to your plugin
> (the library should be statically linked and so apr_dso_load() should
> not search for this method symbol at all)...
> 
> Still something wrong in indra/cmake/CEFPlugin.cmake, or perhaps a
> failure to specify the $CEF_PLUGIN_LIBRARIES in
> indra/media_plugins/cef/CMakeLists.txt
> 
> Watch out for (similar) lines in it:
> 
> set(media_plugin_cef_LINK_LIBRARIES
>   ${LLPLUGIN_LIBRARIES}
>   ${MEDIA_PLUGIN_BASE_LIBRARIES}
>   ${CEF_PLUGIN_LIBRARIES}
>   ${LLCOMMON_LIBRARIES}
>   ${PLUGIN_API_LIBRARIES}
> )
> 
> Henri.

I couldn't spot a problem in either of those files, but my eyes might 
have missed something.

Does anything stand out at you:

https://pastebin.com/c7wRQik8 (indra/cmake/CEFPlugin.cmake)
https://pastebin.com/ZhytizN8 (indra/media_plugins/cef/CMakeLists.txt)



-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Tue, 20 Mar 2018 22:30:14 +1000, Alex wrote:

> The symbol is there... I'm not seeing any 'not found' errors when I 
> check that plugin with ldd.

Depending on your ld version (old ones are very sensitive to the library
link order), this could be an issue with not linking the libraries in the
proper order...

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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Tue, 20 Mar 2018 22:00:36 +1000, Alex wrote:

> Well, I am a little closer :)
> 
> I have a different error now.
> 
> 2018-03-20T11:53:39Z WARNING: LLPluginInstance::load: apr_dso_load of 
> /home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so failed with 
> error 20019 , additional info string: 
> /home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so: undefined 
> symbol: _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE
> 
> Any ideas what might be behind this one?

Apparently a failure to properly link libdullahan.a to your plugin
(the library should be statically linked and so apr_dso_load() should
not search for this method symbol at all)...

Still something wrong in indra/cmake/CEFPlugin.cmake, or perhaps a
failure to specify the $CEF_PLUGIN_LIBRARIES in
indra/media_plugins/cef/CMakeLists.txt

Watch out for (similar) lines in it:

set(media_plugin_cef_LINK_LIBRARIES
  ${LLPLUGIN_LIBRARIES}
  ${MEDIA_PLUGIN_BASE_LIBRARIES}
  ${CEF_PLUGIN_LIBRARIES}
  ${LLCOMMON_LIBRARIES}
  ${PLUGIN_API_LIBRARIES}
)

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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-20 22:00, Alex wrote:
> 2018-03-20T11:53:39Z WARNING: LLPluginInstance::load: apr_dso_load of
> /home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so failed with
> error 20019 , additional info string:
> /home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so: undefined
> symbol: _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE
> 
> Any ideas what might be behind this one?

Something I noticed:

alex@desktop:~/ivyviewer/bin/llplugin$ strings libmedia_plugin_cef.so | 
grep ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE
_ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE
_ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE

The symbol is there... I'm not seeing any 'not found' errors when I 
check that plugin with ldd.

I have no idea what it might be. Strange.


-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-20 20:34, Henri Beauchamp wrote:
> Yes, obviously, libcef.so did not get linked with your plugin...
> 
> Check your indra/cmake/CEFPlugin.cmake: the library names changed 
> there,
> from libllceflib.a to libdullahan.a. Note also the bit of vodoo magic
> needed under Linux to avoid seeing ld "optimizing out" the functions 
> that
> are needed in libcef_dll_wrapper.a and libdullahan.a. It should look 
> like
> this (note the -Wl,-[no-]whole-archive options):
> 
> if (LINUX)
>   set(CEF_PLUGIN_LIBRARIES
>   -Wl,-whole-archive
>   ${ARCH_PREBUILT_DIRS_RELEASE}/libcef_dll_wrapper.a
>   ${ARCH_PREBUILT_DIRS_RELEASE}/libdullahan.a
>   -Wl,-no-whole-archive
>   ${ARCH_PREBUILT_DIRS_RELEASE}/libcef.so
>   )
> endif ()
> 
> Henri.

Well, I am a little closer :)

I have a different error now.

2018-03-20T11:53:39Z WARNING: LLPluginInstance::load: apr_dso_load of 
/home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so failed with 
error 20019 , additional info string: 
/home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so: undefined 
symbol: _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE

Any ideas what might be behind this one?

-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-20 20:34, Henri Beauchamp wrote:
> 
> Yes, obviously, libcef.so did not get linked with your plugin...
> 
> Check your indra/cmake/CEFPlugin.cmake: the library names changed 
> there,
> from libllceflib.a to libdullahan.a. Note also the bit of vodoo magic
> needed under Linux to avoid seeing ld "optimizing out" the functions 
> that
> are needed in libcef_dll_wrapper.a and libdullahan.a. It should look 
> like
> this (note the -Wl,-[no-]whole-archive options):
> 
> if (LINUX)
>   set(CEF_PLUGIN_LIBRARIES
>   -Wl,-whole-archive
>   ${ARCH_PREBUILT_DIRS_RELEASE}/libcef_dll_wrapper.a
>   ${ARCH_PREBUILT_DIRS_RELEASE}/libdullahan.a
>   -Wl,-no-whole-archive
>   ${ARCH_PREBUILT_DIRS_RELEASE}/libcef.so
>   )
> endif ()
> 
> Henri.

Ah!! Yes! That will do it... I just checked that cmake file and that 
section was wrong (and missing things). I'll try another rebuild with 
that. I have a feeling thats going to fix it! Now how can I send you a 
nice bottle of wine? :D

Thank you so much! appreciate it!

-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Tue, 20 Mar 2018 19:58:49 +1000, Alex wrote:

> This is what I get:
> alex@desktop:~/ivyviewer$ LD_LIBRARY_PATH="./lib:$LD_LIBRARY_PATH" ldd 
> ./bin/llplugin/libmedia_plugin_cef.so
>  linux-vdso.so.1 =>  (0x7ffcedd68000)
>  librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 
> (0x7f07a805e000)
>  libaprutil-1.so.0 => ./lib/libaprutil-1.so.0 
> (0x7f07a7e15000)
>  libapr-1.so.0 => ./lib/libapr-1.so.0 (0x7f07a7be5000)
>  libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
> (0x7f07a785f000)
>  libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 
> (0x7f07a7509000)
>  libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
> (0x7f07a72f2000)
>  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x7f07a70d3000)
>  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 
> (0x7f07a6cf3000)
>  /lib64/ld-linux-x86-64.so.2 (0x7f07a867)
>  libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 
> (0x7f07a6aee000)
>  libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 
> (0x7f07a68b6000)
>  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 
> (0x7f07a66b2000)
> 
> alex@desktop:~/ivyviewer$ find . -name 'libcef.so'
> ./lib/libcef.so
> 
> I would have expected to see a 'not found' in the ldd output if it had 
> not been copied or it was sitting somewhere outside of LD_LIBRARY_PATH. 
> Is it likely has gotten screwed up during the link of 
> libmedia_plugin_cef.so?

Yes, obviously, libcef.so did not get linked with your plugin...

Check your indra/cmake/CEFPlugin.cmake: the library names changed there,
from libllceflib.a to libdullahan.a. Note also the bit of vodoo magic
needed under Linux to avoid seeing ld "optimizing out" the functions that
are needed in libcef_dll_wrapper.a and libdullahan.a. It should look like
this (note the -Wl,-[no-]whole-archive options):

if (LINUX)
  set(CEF_PLUGIN_LIBRARIES
  -Wl,-whole-archive
  ${ARCH_PREBUILT_DIRS_RELEASE}/libcef_dll_wrapper.a
  ${ARCH_PREBUILT_DIRS_RELEASE}/libdullahan.a
  -Wl,-no-whole-archive
  ${ARCH_PREBUILT_DIRS_RELEASE}/libcef.so
  )
endif ()

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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

> Hi Henri!
> 
> Thank you for responding.
> 
> This is what I get:
> alex@desktop:~/ivyviewer$ LD_LIBRARY_PATH="./lib:$LD_LIBRARY_PATH" ldd
> ./bin/llplugin/libmedia_plugin_cef.so
>  linux-vdso.so.1 =>  (0x7ffcedd68000)
>  librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> (0x7f07a805e000)
>  libaprutil-1.so.0 => ./lib/libaprutil-1.so.0
> (0x7f07a7e15000)
>  libapr-1.so.0 => ./lib/libapr-1.so.0 (0x7f07a7be5000)
>  libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f07a785f000)
>  libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
> (0x7f07a7509000)
>  libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7f07a72f2000)
>  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f07a70d3000)
>  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> (0x7f07a6cf3000)
>  /lib64/ld-linux-x86-64.so.2 (0x7f07a867)
>  libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1
> (0x7f07a6aee000)
>  libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
> (0x7f07a68b6000)
>  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x7f07a66b2000)
> 
> alex@desktop:~/ivyviewer$ find . -name 'libcef.so'
> ./lib/libcef.so
> 
> I would have expected to see a 'not found' in the ldd output if it had
> not been copied or it was sitting somewhere outside of LD_LIBRARY_PATH.
> Is it likely has gotten screwed up during the link of
> libmedia_plugin_cef.so?

Interestingly if I run ldd against a pre dullahan era instance of FS:

alex@desktop:~/fs_avx2/bin/llplugin$ ldd libmedia_plugin_cef.so
 linux-vdso.so.1 =>  (0x7fff637d2000)
 libllceflib.so => not found
 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 
(0x7f341b9ed000)
 libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 
(0x7f341b7c2000)
 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f341b43c000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 
(0x7f341b0e6000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f341aecf000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 
(0x7f341aaef000)
 /lib64/ld-linux-x86-64.so.2 (0x7f341bffd000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f341a8d)

The 'not found' is probably just due to LD_LIBRARY_PATH not being set. 
But at least the dependency is there! In my problematic install it seems 
the dependency is completely missing!

I'm guessing something has gone bad during the link of 
libmedia_plugin_cef

Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Alex]

On 2018-03-20 19:35, Henri Beauchamp wrote:
> On Tue, 20 Mar 2018 10:24:24 +0100, Henri Beauchamp wrote:
> 
>> On Tue, 20 Mar 2018 10:22:43 +0100, Henri Beauchamp wrote:
>> 
>> > LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd ./path 
>> > bin/llplugin/libmedia_plugin_cef.so
>> 
>> I meant:
>> LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd 
>> ./bin/llplugin/libmedia_plugin_cef.so
> 
> And without the typos in "library", it actually is:
> LD_LIBRARY_PATH="./lib:$LD_LIBRARY_PATH" ldd
> ./bin/llplugin/libmedia_plugin_cef.so
> 
> * drinks a cup of strong expresso, slaps his face twice and re-reads 
> thrice *
> Should be OK, this time...
> 
> 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

Hi Henri!

Thank you for responding.

This is what I get:
alex@desktop:~/ivyviewer$ LD_LIBRARY_PATH="./lib:$LD_LIBRARY_PATH" ldd 
./bin/llplugin/libmedia_plugin_cef.so
 linux-vdso.so.1 =>  (0x7ffcedd68000)
 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 
(0x7f07a805e000)
 libaprutil-1.so.0 => ./lib/libaprutil-1.so.0 
(0x7f07a7e15000)
 libapr-1.so.0 => ./lib/libapr-1.so.0 (0x7f07a7be5000)
 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f07a785f000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 
(0x7f07a7509000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f07a72f2000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f07a70d3000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 
(0x7f07a6cf3000)
 /lib64/ld-linux-x86-64.so.2 (0x7f07a867)
 libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 
(0x7f07a6aee000)
 libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 
(0x7f07a68b6000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 
(0x7f07a66b2000)

alex@desktop:~/ivyviewer$ find . -name 'libcef.so'
./lib/libcef.so

I would have expected to see a 'not found' in the ldd output if it had 
not been copied or it was sitting somewhere outside of LD_LIBRARY_PATH. 
Is it likely has gotten screwed up during the link of 
libmedia_plugin_cef.so?

Kind Regards,
Alex.

-- 
Kind Regards,
Alex.
___
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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Tue, 20 Mar 2018 10:24:24 +0100, Henri Beauchamp wrote:

> On Tue, 20 Mar 2018 10:22:43 +0100, Henri Beauchamp wrote:
> 
> > LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd ./path 
> > bin/llplugin/libmedia_plugin_cef.so
> 
> I meant:
> LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd 
> ./bin/llplugin/libmedia_plugin_cef.so

And without the typos in "library", it actually is:
LD_LIBRARY_PATH="./lib:$LD_LIBRARY_PATH" ldd 
./bin/llplugin/libmedia_plugin_cef.so

* drinks a cup of strong expresso, slaps his face twice and re-reads thrice *
Should be OK, this time...

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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Tue, 20 Mar 2018 10:22:43 +0100, Henri Beauchamp wrote:

> LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd ./path 
> bin/llplugin/libmedia_plugin_cef.so

I meant:
LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd 
./bin/llplugin/libmedia_plugin_cef.so

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] Linux x64 - libmedia_plugin_cef.so error

[Henri Beauchamp]

On Tue, 20 Mar 2018 18:45:54 +1000, Alex wrote:

> I am working to try and get a Linux version of the FS viewer running and 
> I have been successful for the most part after fixing a bunch of build 
> issues.. however I seem to have an issue with CEF failing in the new 
> viewer, this can be seen in the logs:
> 
> 2018-03-20T07:44:13Z WARNING: LLPluginInstance::load: apr_dso_load of 
> /home/alex/fsivy/bin/llplugin/libmedia_plugin_cef.so failed with error 
> 20019 , additional info string: 
> /home/alex/fsivy/bin/llplugin/libmedia_plugin_cef.so: undefined symbol: 
> AtomicOps_Internalx86CPUFeatures
> 
> Some Googling reveals that AtomicOps_Internalx86CPUFeatures is part of 
> CEF? Has something gone wrong with linking somewhere?
> 
> What might have gone wrong for this to happen? I am out of ideas as to 
> what it might be. Any thoughts appreciated.

When typed from a terminal pointing in your viewer directory, what does

LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd ./path 
bin/llplugin/libmedia_plugin_cef.so

tells you ?

If it can't find libcef.so, then it would explain it...

Make sure your viewer_manifest.py script does properly copy all the CEF
libraries, binaries and resources in the right places.

Also, you will find a working Dullahan Linux plugin on the Cool VL Viewer
site (in http://sldev.free.fr/libraries/ ), as well as the corresponding
sources (in http://sldev.free.fr/libraries/sources/ ). Note however that
this is a modified version with extended parameters for CEF (to learn how to
use them, have a look at indra/media_plugins/libvlc/media_plugin_libvlc.cpp
in the sources for the Cool VL Viewer v1.26.21.x). This plugin can also be
used to compile the viewer with a non C++11 compliant compiler (e.g. with
gcc v4.6, even though you will still need to link the viewer to a version
of libstdc++.so v6.0.19 or newer (shipped with gcc v4.8 or newer), since
this is what libcef.so expects), unlike LL's version.

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

Re: [opensource-dev] Linux

[Henri Beauchamp]

On Fri, 2 Feb 2018 13:33:22 -0600, Nicky Perian wrote:

> Having read the comments on viewer-release repo and your comment concerning
> ABI mismatch I want to submit the following:
> 
> I have put together in a VM Debian / stretch. My past linux builds have
> been on Ubuntu 14.04 and 16.04 using gcc-4.8 and 4.9.

To ensure compatibility with 4/5 years old systems (which seems to me like
quite a reasonnable premise), the problem are:

- Most of these systems are still using gcc v4.x (and, most important,
  its associated libstdc++ library using the old ABI) and all the
  LL-supplied libraries should therefore be compiled with either gcc v4.x
  (x = 7 to 9, given, alas, 4.6 is not fully C++11 compliant and cannot
  compile stuff like CEF), *or* have the _GLIBCXX_USE_CXX11_ABI=0 define
  set so that the old C++ ABI is used (the same define should then also be
  set in the viewer sources via the 00-Common.cmake file for gcc v5+ and
  clang).

- The glibc version of the build system must not be too high (v2.19 looks
  like the newest version found on such systems). In fact, the older the
  glibc version, the better and the broadest the compatibility (old
  pre-built libraries were compatible with glibc v2.13+).

- The glib v2.0 version should also be the oldest possible, since glib is
  used by CEF and other pre-built libraries. Using a build system with too
  recent a glib library would also result in missing symbols or mismatches.

In fact, the gcc version matters less (thanks to the_GLIBCXX_USE_CXX11_ABI=0
trick you can use with gcc v5+ versions to retain compatibility) than the
versions of *glibc* and *glib2*.

Since CEF is now the most demanding library about the build system
dependencies (with glibc v2.19 and glib v2.46 on the CEF build system,
namely Ubuntu 14.04 LTS), I suggest we stick with those for now.

FYI, the current stable release of the Cool VL Viewer builds with gcc v4.6
to v7.3 (probably with gcc v8.0 as well) and clang v3.8 to v6.0RC1 (and
probably with v3.6 and 3.7 too) and the builds I release (built on a
modified Rosa 2012 distro) run on pretty much any post-2012 distro.
I am planning to adopt Rosa 2014.1 for my next build system (I already
built Dullahan, both 32 and 64 bits on it) for the experimental Cool VL
Viewer release and the next stable one.

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] Linux

[Nicky Perian]

> Stretch has neither gcc-4.9 nor libpngl2. Both of these are in jessie. Adding 
> wheezy to sources.list then apt-get update and apt-get install will place 
> these in stretch then, comment out the lines about jessie in sources.list and 
> apt-get update again. Don’t  apt-get upgrade with the wheezy lines active.  
> Building non Alex Ivy code went fine with this setup.

Should be Jessie!!!


> On Feb 2, 2018, at 1:33 PM, Nicky Perian  wrote:
> 
> Having read the comments on viewer-release repo and your comment concerning 
> ABI mismatch I want to submit the following:
> 
> I have put together in a VM Debian / stretch. My past linux builds have been 
> on Ubuntu 14.04 and 16.04 using gcc-4.8 and 4.9.
> 
> Stretch has neither gcc-4.9 nor libpngl2. Both of these are in wheezy. Adding 
> wheezy to sources.list then apt-get update and apt-get install will place 
> these in stretch then, comment out the lines about wheezy in sources.list and 
> apt-get update again. Don’t  apt-get upgrade with the wheezy lines active.  
> Building non Alex Ivy code went fine with this setup.
> 
> Ubuntu is a good choice also and has the advantage of being able to build a 
> VM quicker.
> 
> I don’t think repo commit comments is the right place to discuss future 
> development.
> 
> 
> 
> 
> 
> 
>> On Jan 26, 2018, at 3:31 AM, Henri Beauchamp  wrote:
>> 
>> On Fri, 26 Jan 2018 01:34:09 +0100, Henri Beauchamp wrote:
>> 
>> 
>>> However, it might be a problem with Dullahan, since CEF is now compiled with
>>> Ubuntu 16.04 LTS,
>> 
>> Scratch that !
>> 
>> On the CEF build Wiki, they cite 14.04, but the link points to a page that
>> itself points to 16.04... So, if to believe the Wiki text, Ubuntu 14.04 is
>> used to build the latest CEF...
>> 
>> Ubuntu 14.04 uses gcc v4.8 and glibc 2.19, just like Debian Jessie (either
>> of those two could then be the Linux build system of choice).
>> 
>> 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
> 

___
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] Linux

[Nicky Perian]

Having read the comments on viewer-release repo and your comment concerning ABI 
mismatch I want to submit the following:

I have put together in a VM Debian / stretch. My past linux builds have been on 
Ubuntu 14.04 and 16.04 using gcc-4.8 and 4.9.

Stretch has neither gcc-4.9 nor libpngl2. Both of these are in wheezy. Adding 
wheezy to sources.list then apt-get update and apt-get install will place these 
in stretch then, comment out the lines about wheezy in sources.list and apt-get 
update again. Don’t  apt-get upgrade with the wheezy lines active.  Building 
non Alex Ivy code went fine with this setup.

Ubuntu is a good choice also and has the advantage of being able to build a VM 
quicker.

I don’t think repo commit comments is the right place to discuss future 
development.




 

> On Jan 26, 2018, at 3:31 AM, Henri Beauchamp  wrote:
> 
> On Fri, 26 Jan 2018 01:34:09 +0100, Henri Beauchamp wrote:
> 
> 
>> However, it might be a problem with Dullahan, since CEF is now compiled with
>> Ubuntu 16.04 LTS,
> 
> Scratch that !
> 
> On the CEF build Wiki, they cite 14.04, but the link points to a page that
> itself points to 16.04... So, if to believe the Wiki text, Ubuntu 14.04 is
> used to build the latest CEF...
> 
> Ubuntu 14.04 uses gcc v4.8 and glibc 2.19, just like Debian Jessie (either
> of those two could then be the Linux build system of choice).
> 
> 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

___
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] Linux

[Henri Beauchamp]

On Fri, 26 Jan 2018 01:34:09 +0100, Henri Beauchamp wrote:


> However, it might be a problem with Dullahan, since CEF is now compiled with
> Ubuntu 16.04 LTS,

Scratch that !

On the CEF build Wiki, they cite 14.04, but the link points to a page that
itself points to 16.04... So, if to believe the Wiki text, Ubuntu 14.04 is
used to build the latest CEF...

Ubuntu 14.04 uses gcc v4.8 and glibc 2.19, just like Debian Jessie (either
of those two could then be the Linux build system of choice).

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] Linux

[Henri Beauchamp]

On Tue, 23 Jan 2018 09:09:22 -0500, Oz Linden (Scott Lawrence) wrote:

> On 2018-01-23 07:05 , Nicky Perian wrote:
> > Which version of Debian does LL plan to use? Stretch is at stable.
> 
> I had been planning on Jessie, but this took longer than I hoped, so 
> yeah we'll go for Stretch.

Debian Stretch uses gcc v6.3 and glibc v2.24, which are quite new and will
cause pre-built libraries to be unusable on distros with gcc v5 or older...

Debian Jessie uses gcc v4.8 (which does not have the new C++ ABI, but this
can be fixed when compiling with v5+ gcc against libraries built with the
old ABI by defining _GLIBCXX_USE_CXX11_ABI=0) and glibc v2.19, which should
make it compatible with all reasonably recent distros (post-2014)...
However, it might be a problem with Dullahan, since CEF is now compiled with
Ubuntu 16.04 LTS, which uses gcc v5.4 (new ABI, so when compiled with gcc 4.8,
you won't be able to link Dullahan against the pre-built CEF) and glibc v2.23...

An alternative would be to use Ubuntu 16.04 LTS as a build system. All distros
with gcc v5 and newer would then be compatible with the builds, and no issue
to fear with CEF.

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] Linux

[Oz Linden (Scott Lawrence)]

On 2018-01-23 07:05 , Nicky Perian wrote:

Which version of Debian does LL plan to use? Stretch is at stable.


I had been planning on Jessie, but this took longer than I hoped, so 
yeah we'll go for Stretch.


--
OZ LINDEN | Senior Director, Second Life Engineering
email or hangouts: o...@lindenlab.com  | Real 
Life: Scott Lawrence

LINDEN LAB | Create Virtual Experiences 
___
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] Linux

[Oz Linden (Scott Lawrence)]

On 2017-01-30 12:41 , Nicky D. wrote:

For the time being, we expect that it will be based on the current system,
modified to use system libraries rather than autobuild packages that build a
static executable (some packages will be used in our builds for proprietary
components).  I'm not sure that answers your question...


This is the old Squeeze based Debian?

No, we're going to leapfrog to Jessie for this.


Granted, *.deb is a much used package manager for debian and derived
distros. Will any other distro package managers be developed? I assume the
answer is no so, will OS developer submissions of other package manager
formats be accepted?

Let's worry about getting one to work... if we're wildly successful with
that and there's a good reason to do something else, we'll discuss it.

I'm not sure yet what to make out of this change, as we possible need
to see a deb to see
about some of the consequences. Just a few thoughts:

- Standalone is afaik broken since a long time, for example there is
missing FindXXX.cmake
files for various packages.

- As far as I know are there no system packages for (at least) glod,
colladadom, breakpad and cef.

- Some distributions only ship openjpeg2, not 1.4 or 1.5 (for example
I cannot find anything older than 2
for Debian Wheezy). Possibly this can be worked around with non
standard deb repositories in apt.conf.

- Compiling the deb eg on Squeeze and trying to install it on
something Wheezy based could lead to
interesting results, due to the dependent packages from the Squeeze
system being recorded in the deb.
(Or compiling on Wheezy and installing on Jessie and so on).

- VLC: Henri pointed out a few times, that the VLC api is not exactly
stable between releases.

- Boost will be interesting


Well, if it was easy it wouldn't be any fun, would it?

--
OZ LINDEN | Engineering Director, Second Life
email or hangouts: o...@lindenlab.com  | Real 
Life: Scott Lawrence

LINDEN LAB | Create Virtual Experiences 
___
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] Linux

[Henri Beauchamp]

On Mon, 30 Jan 2017 18:41:07 +0100, Nicky D. wrote:

> - Standalone is afaik broken since a long time, for example there is
> missing FindXXX.cmake files for various packages.

Many such files are actually part of the cmake package or added by the
devel packages of some libraries.
See: /usr/share/cmake/Modules/Find*

> - As far as I know are there no system packages for (at least) glod,
> colladadom, breakpad and cef.
> 
> - Some distributions only ship openjpeg2, not 1.4 or 1.5 (for example
> I cannot find anything older than 2
> for Debian Wheezy). Possibly this can be worked around with non
> standard deb repositories in apt.conf.
> 
> - Compiling the deb eg on Squeeze and trying to install it on
> something Wheezy based could lead to
> interesting results, due to the dependent packages from the Squeeze
> system being recorded in the deb.
> (Or compiling on Wheezy and installing on Jessie and so on).

I resolved the "STANDALONE" (now "SYSTEMLIBS") issue for my viewer by
making it so that libraries that are not likely to be present in distros,
or not properly patched for SL viewers, or simply incompatible, are still
downloaded as the pre-built viewer libraries (i.e. the resulting viewer
binary is linked against a mix of commonly available system libraries and
exotic/patched pre-built libraries). It more or less works, i.e. it works
on my system (PCLinuxOS) but one of my users encountered an issue with
this method recently (probably because of his distro's curl library,
which I will probably mark as "use-pre-built-curl-only" in future
releases).

Your best bet is however to keep building the viewer using the pre-built
libraries and packaging it together with them (/usr/games/YourViewerName
is a good candidate for the packaged build destination).

> - VLC: Henri pointed out a few times, that the VLC api is not exactly
> stable between releases.

Gstreamer would be better... I would have pointed you to the archived
messages on this list in which I went to great extents to explain
everything in details, but the archive is currently down...

> - Boost will be interesting

You cannot currently using system boost libraries: they lack LL's custom
coroutine stuff...

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] Linux

[Nicky D.]

>
> For the time being, we expect that it will be based on the current system,
> modified to use system libraries rather than autobuild packages that build a
> static executable (some packages will be used in our builds for proprietary
> components).  I'm not sure that answers your question...
>

This is the old Squeeze based Debian?

> Granted, *.deb is a much used package manager for debian and derived
> distros. Will any other distro package managers be developed? I assume the
> answer is no so, will OS developer submissions of other package manager
> formats be accepted?
>
> Let's worry about getting one to work... if we're wildly successful with
> that and there's a good reason to do something else, we'll discuss it.

I'm not sure yet what to make out of this change, as we possible need
to see a deb to see
about some of the consequences. Just a few thoughts:

- Standalone is afaik broken since a long time, for example there is
missing FindXXX.cmake
files for various packages.

- As far as I know are there no system packages for (at least) glod,
colladadom, breakpad and cef.

- Some distributions only ship openjpeg2, not 1.4 or 1.5 (for example
I cannot find anything older than 2
for Debian Wheezy). Possibly this can be worked around with non
standard deb repositories in apt.conf.

- Compiling the deb eg on Squeeze and trying to install it on
something Wheezy based could lead to
interesting results, due to the dependent packages from the Squeeze
system being recorded in the deb.
(Or compiling on Wheezy and installing on Jessie and so on).

- VLC: Henri pointed out a few times, that the VLC api is not exactly
stable between releases.

- Boost will be interesting
___
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] Linux

[Oz Linden (Scott Lawrence)]

On 2017-01-29 20:39 , Nicky Perian wrote:

Questions:

Will LL use a build system that can be updated as opposed to the 
current out of date system? Hopefully, the build system will be a 
standard off the shelf that everyone can install and without any mix 
and match specials.
For the time being, we expect that it will be based on the current 
system, modified to use system libraries rather than autobuild packages 
that build a static executable (some packages will be used in our builds 
for proprietary components).  I'm not sure that answers your question...



Will there be LL developed QA procedures for the linux builds?
We'll use the same QA we've always used for Linux (not as much as we do 
for other platforms)


Granted, *.deb is a much used package manager for debian and derived 
distros. Will any other distro package managers be developed? I assume 
the answer is no so, will OS developer submissions of other package 
manager formats be accepted?
Let's worry about getting one to work... if we're wildly successful with 
that and there's a good reason to do something else, we'll discuss it.


--
OZ LINDEN | Engineering Director, Second Life
email or hangouts: o...@lindenlab.com  | Real 
Life: Scott Lawrence

LINDEN LAB | Create Virtual Experiences 
___
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] Linux

[Henri Beauchamp]

On Sun, 29 Jan 2017 20:54:42 -0500, Monty Brandenberg wrote:

> On 1/29/2017 8:39 PM, Nicky Perian wrote:
> 
> > Will LL use a build system that can be updated as opposed to the current
> > out of date system? Hopefully, the build system will be a standard off
> > the shelf that everyone can install and without any mix and match specials.
> 
> The "one, true Linux?"
> 
> /me reaches for box of popcorn...

/me steals popcorn in Monty's box, and speaks with a mouthful.

/me chewing, "Ya know..."
/me gulps, "Excuse me..."

All it takes is writing a shell script allowing to build your viewer.
Then packagers just have to invoke that script via whatever package
build system you use (rpm, deb, ebuild, you name it).

/me steals another handful of popcorn and points at his viewer sources

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] Linux

[Nicky Perian]

>The "one, true Linux?"
No not at all. Just something better.
A few years ago Oz published a detailed recipe for your build system that
was an original work by Donald Kjer. I can't find the reference atm but i
would bet there isn't anyone besides
Don that would be able to redo it from a blank box.



On Sun, Jan 29, 2017 at 7:54 PM, Monty Brandenberg 
wrote:

> On 1/29/2017 8:39 PM, Nicky Perian wrote:
>
> > Will LL use a build system that can be updated as opposed to the current
> > out of date system? Hopefully, the build system will be a standard off
> > the shelf that everyone can install and without any mix and match
> specials.
>
> The "one, true Linux?"
>
> /me reaches for box of popcorn...
>
> ___
> 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] Linux

[Monty Brandenberg]

On 1/29/2017 8:39 PM, Nicky Perian wrote:

> Will LL use a build system that can be updated as opposed to the current
> out of date system? Hopefully, the build system will be a standard off
> the shelf that everyone can install and without any mix and match specials.

The "one, true Linux?"

/me reaches for box of popcorn...

___
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] linux viewer building

[Nicky Perian]

>>Has anyone built 2.8.10 from source on debian squeeze? If so, how did it go?

Smooth as silk. I wish the viewer would compile and install that simply.
Using 2.8.2 resulted in a problem late in the process when the version was 
trying to be set.




>
> From: Nicky Perian 
>To: "opensource-dev@lists.secondlife.com" 
>; "kokua-...@lists.kokuaviewer.org" 
> 
>Sent: Saturday, May 4, 2013 9:15 AM
>Subject: [opensource-dev] linux viewer building
> 
>
>
>LL has placed a cmake minimum required version of 2.8.8. debian squeeze has 
>2.8.2 as a default install and 2.8.7 available from squeeze backports.
>
>
>I have the string compare fix from nickyD / firestorm and reducing to a 
>minimum required version in indra/CMakeLists.txt did not reveal any build 
>errors.
>
>
>cmake is to version 2.8.10 and has the sources for download.
>
>
>Has anyone built 2.8.10 from source on debian squeeze? If so, how did it go?
>
>
>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
>
>___
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] linux viewer building

[Lance Corrimal]

Am Samstag, 4. Mai 2013, 07:15:58 schrieb Nicky Perian:
> LL has placed a cmake minimum required version of 2.8.8. debian squeeze has
> 2.8.2 as a default install and 2.8.7 available from squeeze backports.


...isn't that incompatible with their own build environment, which was still 
debian 5 last time I looked?


cheers,
LC
___
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] Linux boost shared libraries

[Monty Brandenberg]

On 12/11/2012 5:36 PM, Henri Beauchamp wrote:

> The JIRA became useless to developers and users alike...

Not useless, _streamlined_!  *cough*


___
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] Linux boost shared libraries

[Henri Beauchamp]

On Tue, 11 Dec 2012 13:02:51 -0500, Monty Brandenberg wrote:

> filed:  https://jira.secondlife.com/browse/BUG-1056

"Permission Violation"

The JIRA became useless to developers and users alike...
___
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] Linux boost shared libraries

[Monty Brandenberg]

filed:  https://jira.secondlife.com/browse/BUG-1056

___
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] Linux boost shared libraries

[Henri Beauchamp]

On Mon, 10 Dec 2012 16:25:37 -0800 (PST), Nicky Perian wrote:

> At the sldev meeting earlier it was stated that unicode processing with boost
> regex was problematic unless a shared boost lib was included. Here:
> http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/unicode.html
> it appears that the static lib compiled/linked with ICU is unicode aware.

Yes, it is if the boost library was built on a system with ICU installed. Here 
is
the relevant info for how to build boost::regex with Unicode support:

http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/install.html#boost_regex.install.building_with_unicode_and_icu_support

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] Linux boost shared libraries

[Monty Brandenberg]

On 12/10/2012 7:25 PM, Nicky Perian wrote:
> At the sldev meeting earlier it was stated that unicode processing with
> boost regex was problematic unless a shared boost lib was included.
> Here: 
> http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/unicode.html
> it appears that the static lib compiled/linked with ICU is unicode aware.

I think we need some unit/integration tests to probe what we're
trying to achieve with ::regex.  Grumble.


___
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] Linux boost shared libraries

[Nicky Perian]

At the sldev meeting earlier it was stated that unicode processing with boost 
regex was problematic unless a shared boost lib was included. 
Here: http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/unicode.html
it appears that the static lib compiled/linked with ICU is unicode aware.

am i wrong?



>
> From: Henri Beauchamp 
>To: opensource-dev@lists.secondlife.com 
>Sent: Monday, December 10, 2012 2:36 PM
>Subject: Re: [opensource-dev] Linux boost shared libraries
> 
>On Sun, 9 Dec 2012 18:32:18 -0800 (PST), Nicky Perian wrote:
>
>> What is the reason for the switch to boost shared libraries?
>> 
>> The other platforms seem to perform without issue using boost static 
>> libraries. 
>
>Apart from adding 20Mb of shared libraries (boost regexp) to the viewer
>package ?... There's strictly no good reason !
>
>I vote for getting back to static libraries (the few regex functions that
>get statically linked only take a few kilobytes in the viewer binary, when
>the boost regex shared lib is enormous and 99% of it is usless to the
>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
>
>
>___
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] Linux boost shared libraries

[Henri Beauchamp]

On Sun, 9 Dec 2012 18:32:18 -0800 (PST), Nicky Perian wrote:

> What is the reason for the switch to boost shared libraries?
> 
> The other platforms seem to perform without issue using boost static 
> libraries. 

Apart from adding 20Mb of shared libraries (boost regexp) to the viewer
package ?... There's strictly no good reason !

I vote for getting back to static libraries (the few regex functions that
get statically linked only take a few kilobytes in the viewer binary, when
the boost regex shared lib is enormous and 99% of it is usless to the
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] Linux boost shared libraries

[Nicky Perian]

Yes, 3.4.3
No problem with LL v-d(1.52) or v-b(1.48). I build a 64 bit viewer for kokua 
and built it w/o the *.so but, did not link icu to the viewer. It built and 
runs Ok "i think". Just may not have reached the code where it it is needed. 
From Oz meeting this morning the shared libs are for boost regex. But, I still 
don't understand the need. The static libs are built against icu so the icu 
functions should be in boost regex *.a. The viewer is linked to the static so 
why is shared needed?   And, if shared are needed for linux why are they not 
needed for windows and darwin?



>
> From: Monty Brandenberg 
>To: opensource-dev@lists.secondlife.com 
>Sent: Monday, December 10, 2012 10:56 AM
>Subject: Re: [opensource-dev] Linux boost shared libraries
> 
>On 12/9/2012 9:32 PM, Nicky Perian wrote:
>>
>> What is the reason for the switch to boost shared libraries?
>>
>> The other platforms seem to perform without issue using boost static
>> libraries.
>
>In 3.4.3?  That change was picked up as part of some shared work
>in Boost packaging.  Not certain what the technical motivation
>was.  Are you seeing a problem as a result?
>
>(I expect it will likely revert on a future refresh of Boost,
>probably 1.52 but no promises there.)
>
>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
>
>
>___
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] Linux boost shared libraries

[Monty Brandenberg]

On 12/9/2012 9:32 PM, Nicky Perian wrote:
>
> What is the reason for the switch to boost shared libraries?
>
> The other platforms seem to perform without issue using boost static
> libraries.

In 3.4.3?  That change was picked up as part of some shared work
in Boost packaging.  Not certain what the technical motivation
was.  Are you seeing a problem as a result?

(I expect it will likely revert on a future refresh of Boost,
probably 1.52 but no promises there.)

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] Linux toolchain update... testers needed.

[Cinder Roxley]

Runs as well as any other release on FreeBSD 8.3-Release amd64 w/ f10 
linuxulator.

Kind regards,
-Cinder

On 6/5/2012 12:27 PM, Oz Linden (Scott Lawrence) wrote:
> We're working on upgrading our Linux viewer build toolchain (moving to
> Debian Squeeze)...
>
> I've got a test build that I'd like some Linux users to try to see if it
> works for them:
>
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/don_viewer-development/rev/257957/arch/Linux/installer/SecondLife-i686-3.3.3.257957.tar.bz2
>
> Please respond here or directly to me (don't create Jira issues yet,
> please).

___
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] Linux toolchain update... testers needed.

[Carlo Wood]

On Wed, 6 Jun 2012 13:59:02 -0700
Christian Goetze  wrote:

> I believe the main challenge is to rebuild all the third party
> dependencies in 64bit ...

Rofl - something that LL certainly isn't capable of ;)
Loads of third party viewers have done this already
however. I have never used anything else than a native
64-bit build, ever since I started using SL.

-- 
Carlo Wood 
___
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] Linux toolchain update... testers needed.

[Christian Goetze]

I believe the main challenge is to rebuild all the third party
dependencies in 64bit ...
___
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] Linux 64bit non-standalone (was: Linux toolchain update... testers needed.)

[Armin Weatherwax]

Oz Linden (Scott Lawrence) wrote:

> There is no plan to do this.
>
> There is also not a plan not to do it.
>
> I don't know whether or not the new build systems this was created on
> are any better set up for 64 bit building than the old one they will
> replace were (I'll find out).  However, even if they are, doing the
> work to rebuild and retest all the components and the viewer itself
> is not a priority for Linden Lab.  If it happens that the build
> systems are already going to be 64 bit capable, and some open source
> developer (or team) wants to take on doing the job, I can coordinate
> the requisite access.

I'm building Linux 64bit non-standalone viewers since 2 1/2 years now, 
in gerneral once all libraries where in place there has been most of 
the time no extra work - its just a Linux version with different 
libraries. Looking at the download couter, a bit more than half of all 
Imprudence Linux users are using the 64bit version).

The patch I'm using for autobuild is trivial 
https://bitbucket.org/ArminW/autobuild-kokua/changeset/d653428ae98e - 
to build 64bit export AUTOBUILD_PLATFORM_OVERRIDE=linux64  ("linux64" 
is inherited from viewer 1 time, there have been some package 
references in the install.xml file).
Adding a linux64 project to the viewer isn't that much of a difference, 
see for example Boroondas draft repository:  
https://bitbucket.org/boroondas/viewer-development-linux64-draft .
I added also a linux64 project to many of the 3p libslibrary, though not 
yet all of them,  see https://bitbucket.org/ArminW . Probably some bits 
and pieces would need changing if someone wants to prepare versions for 
LL use, but for sure for that purpose they can already save a lot of 
time in the way they are now. If someone or a team wants to take the 
job of getting them through the codereview process I'm glad to 
contribute my work as is.

Armin

___
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] Linux toolchain update... testers needed.

[Chico Hersey]

fuck off take me off your list

-Original Message-
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Ron Rogers
Jr.
Sent: Wednesday, June 06, 2012 11:00 AM
To: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Linux toolchain update... testers needed.

On Tue, 05 Jun 2012 15:59:18 -0400
"Oz Linden (Scott Lawrence)"  wrote:


> There is no plan to do this.
> 
> There is also not a plan not to do it.
> 

Sigh...wasn't this suggested thing to do...4 years ago.  I know I complained
about the lack of a 64-bit builds of LL releases 2 years ago on my blog.


> I don't know whether or not the new build systems this was created on 
> are any better set up for 64 bit building than the old one they will 
> replace were (I'll find out).

It's 2012, they had better have a 64 bit Linux installed.

> However, even if they are,
> doing the work to rebuild and retest all the components and the viewer 
> itself is not a priority for Linden Lab.

What is LL's priority, then.  Linux users tend to be early adopter/tech
evangelists.  Wouldn't it be a good idea to make such users happy by making
SL easier and less annoying to install for them.  I know if a 64-bit build
showed up, I'd certainly be crowing about it on the blog and praising the
Lindens for doing so.

CronoCloud


___
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] Linux toolchain update... testers needed.

[Ron Rogers Jr.]

On Tue, 05 Jun 2012 15:59:18 -0400
"Oz Linden (Scott Lawrence)"  wrote:


> There is no plan to do this.
> 
> There is also not a plan not to do it.
> 

Sigh...wasn't this suggested thing to do...4 years ago.  I know I
complained about the lack of a 64-bit builds of LL releases 2 years
ago on my blog.


> I don't know whether or not the new build systems this was created
> on are any better set up for 64 bit building than the old one they
> will replace were (I'll find out). 

It's 2012, they had better have a 64 bit Linux installed.

> However, even if they are,
> doing the work to rebuild and retest all the components and the
> viewer itself is not a priority for Linden Lab.  

What is LL's priority, then.  Linux users tend to be early
adopter/tech evangelists.  Wouldn't it be a good idea to make such
users happy by making SL easier and less annoying to install for
them.  I know if a 64-bit build showed up, I'd certainly be crowing
about it on the blog and praising the Lindens for doing so.

CronoCloud


signature.asc
Description: PGP signature
___
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] Linux toolchain update... testers needed.

[Ron Rogers Jr.]

On Tue, 5 Jun 2012 21:31:51 +0200
Ambrosia  wrote:

> Oz, as an aside..
> 
> Is there a plan to ever support building non-standalone on Linux
> 64bit without installing 32bit libraries or workarounds? It can be a
> nightmare with some distributions, and being forced to compile it as
> 32bit in 2012 just feels..wrong.

Soft Linden told me that he suggested 64-bit back in 2008, given the
state of 32-bit compatibility in 64-bit distros.  Also said Linux was
a tiny segment and most Linux users were running 32-bit.  (ubuntu
SL users having twice the number of other distro users...combined)

I suggested that one of the reasons for some SL Linux users running
32 was the fact that it's a pain in the ass to get SL releases running
on 64-bit.  And it's annoying to no end that I have to install 32 bit
flash just so I can have flash on web-on-a-prim work.

CronoCloud


signature.asc
Description: PGP signature
___
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] Linux toolchain update... testers needed.

[Ron Rogers Jr.]

On Tue, 05 Jun 2012 14:27:00 -0400
"Oz Linden (Scott Lawrence)"  wrote:

> I've got a test build that I'd like some Linux users to try to see
> if it works for them:
> 
> 
> Please respond here or directly to me (don't create Jira issues
> yet, please).
> 
>

Logged into main grid with it right now on Fedora 17 64-bit. it
doesn't seem to have that strange neck glitch issue I've reported for
3.3.3-258xxx on up.

Second Life 3.3.3 (257957) May 24 2012 17:25:24 (Second Life
Development)
Release Notes

You are at 259515.0, 211842.0, 29.5 in Pantucket located at
sim5859.agni.lindenlab.com (216.82.15.88:13001)
Second Life Server 12.06.04.258754
Release Notes

CPU: AMD Athlon(tm) II X2 240 Processor (2800 MHz)
Memory: 3011 MB
OS Version: Linux 3.3.7-1.fc17.x86_64 #1 SMP Mon May 21 22:32:19 UTC
2012 x86_64
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GT 220/PCIe/SSE2

OpenGL Version: 3.3.0 NVIDIA 295.53


CronoCloud


signature.asc
Description: PGP signature
___
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] Linux toolchain update... testers needed.

[Tano Toll]

Works as expected under Ubuntu 12.04 (AMD/gnome).

Freezing bug when saving a texture
https://jira.secondlife.com/browse/VWR-28846 still present. Seems
bug-for-bug compatible to me.



2012/6/5 Oz Linden (Scott Lawrence) 

> We're working on upgrading our Linux viewer build toolchain (moving to
> Debian Squeeze)...
>
> I've got a test build that I'd like some Linux users to try to see if it
> works for them:
>
>
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/don_viewer-development/rev/257957/arch/Linux/installer/SecondLife-i686-3.3.3.257957.tar.bz2
>
> Please respond here or directly to me (don't create Jira issues yet,
> please).
>
> ___
> 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] Linux toolchain update... testers needed.

[Sodovan Torok]

Xubuntu 12.04 (32-bit) on early Acer Aspire One (2G ram, Intel 945GME 
chipset -- intel DRI driver in i915 mode, Atom N270).

Installed properly, ran, logged in to last location, teleported to home, 
poked inventory to start loading. WiFi hotspot cut out, and I got the 
proper "you have been logged out" behavior from the viewer. Clean shutdown.

Smoke test shows no obvious differences from the standard release on 
this system.

Sodo



On 12-06-05 02:27 PM, Oz Linden (Scott Lawrence) wrote:
> We're working on upgrading our Linux viewer build toolchain (moving to
> Debian Squeeze)...
>
> I've got a test build that I'd like some Linux users to try to see if it
> works for them:
>
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/don_viewer-development/rev/257957/arch/Linux/installer/SecondLife-i686-3.3.3.257957.tar.bz2
>
> Please respond here or directly to me (don't create Jira issues yet,
> please).
>
> ___
> 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] Linux toolchain update... testers needed.

[Oz Linden (Scott Lawrence)]

On 2012-06-05 15:31 , Ambrosia wrote:
> Oz, as an aside..
>
> Is there a plan to ever support building non-standalone on Linux 64bit
> without installing 32bit libraries or workarounds? It can be a
> nightmare with some distributions, and being forced to compile it as
> 32bit in 2012 just feels..wrong.
> Pretty much all that blocks it is a lack of differentiation between
> 32bit and 64bit Linux in Autobuild, and offering prebuilt libs that
> got compiled under 64bit once that's in place.

There is no plan to do this.

There is also not a plan not to do it.

I don't know whether or not the new build systems this was created on 
are any better set up for 64 bit building than the old one they will 
replace were (I'll find out).  However, even if they are, doing the work 
to rebuild and retest all the components and the viewer itself is not a 
priority for Linden Lab.  If it happens that the build systems are 
already going to be 64 bit capable, and some open source developer (or 
team) wants to take on doing the job, I can coordinate the requisite access.

___
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] Linux toolchain update... testers needed.

[Lance Corrimal]

Am Dienstag, 5. Juni 2012, 15:07:45 schrieb Oz Linden:
> On 2012-06-05 14:56 , Nicky Perian wrote:
> > Logged to aditi w/o issue
> 
> What I'm after is ... does this work on the flavor of Linux you are
> running, and what flavor is that?


Works on openSUSE 12.1 64bit.

bye,
LC

___
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] Linux toolchain update... testers needed.

[Oz Linden (Scott Lawrence)]

On 2012-06-05 15:33 , Johnnie Carling wrote:
>> Please respond here or directly to me (don't create Jira issues yet,
>> please).
> Crashes on startup on Debian Sid (see STORM-1854)

Bug-for-bug-compatible !
___
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] Linux toolchain update... testers needed.

[Johnnie Carling]

> Please respond here or directly to me (don't create Jira issues yet,
> please).

Crashes on startup on Debian Sid (see STORM-1854)
___
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] Linux toolchain update... testers needed.

[Ambrosia]

Oz, as an aside..

Is there a plan to ever support building non-standalone on Linux 64bit
without installing 32bit libraries or workarounds? It can be a
nightmare with some distributions, and being forced to compile it as
32bit in 2012 just feels..wrong.
Pretty much all that blocks it is a lack of differentiation between
32bit and 64bit Linux in Autobuild, and offering prebuilt libs that
got compiled under 64bit once that's in place.

--Chalice Yao

On Tue, Jun 5, 2012 at 9:07 PM, Oz Linden (Scott Lawrence)
 wrote:
> On 2012-06-05 14:56 , Nicky Perian wrote:
>> Logged to aditi w/o issue
>
> What I'm after is ... does this work on the flavor of Linux you are
> running, and what flavor is that?
>
> ___
> 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] Linux toolchain update... testers needed.

[Zi Ree]

Am Dienstag, 5. Juni 2012, 21:07:45 schrieb Oz Linden (Scott Lawrence):

> What I'm after is ... does this work on the flavor of Linux you are
> running, and what flavor is that?

Runs perfectly under openSUSE 11.4.

Zi
___
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] Linux toolchain update... testers needed.

[Oz Linden (Scott Lawrence)]

On 2012-06-05 14:56 , Nicky Perian wrote:
> Logged to aditi w/o issue

What I'm after is ... does this work on the flavor of Linux you are 
running, and what flavor is that?

___
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] Linux toolchain update... testers needed.

[Nicky Perian]

Do you have any specific tests to run?



>
> From: Nicky Perian 
>To: Oz Linden (Scott Lawrence) ; opensource-dev 
> 
>Sent: Tuesday, June 5, 2012 1:56 PM
>Subject: Re: [opensource-dev] Linux toolchain update... testers needed.
> 
>
>Logged to aditi w/o issue
>
>
>Second Life 3.3.3 (257957) May 24 2012 17:25:24 (Second Life Development)
>Release Notes
>
>
>You are at 255426.0, 256396.0, 32.9 in Morris located at 
>sim7028.aditi.lindenlab.com (216.82.40.145:12035)
>Second Life Server 12.04.30.255166
>Release Notes
>
>
>CPU: Intel(R) Core(TM) i5 CPU         650  @ 3.20GHz (3201 MHz)
>Memory: 7932 MB
>OS Version: Linux 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64
>Graphics Card Vendor: ATI Technologies Inc.
>Graphics Card: ATI Radeon HD 5450    
>
>
>OpenGL Version: 4.2.11566 Compatibility Profile Context
>
>
>libcurl Version: libcurl/7.21.1 OpenSSL/1.0.0d zlib/1.2.5 c-ares/1.7.1
>J2C Decoder Version: KDU v6.4.1
>Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.11.753 / OpenAL Community / 
>OpenAL Soft: PulseAudio Software
>Qt Webkit Version: 4.7.1 (version number hard-coded)
>Voice Server Version: Vivox 3.2.0002.10426
>
>
>Built with GCC version 40103
>Packets Lost: 0/2662 (0.0%)
>
>
>
>>
>> From: Oz Linden (Scott Lawrence) 
>>To: opensource-dev  
>>Sent: Tuesday, June 5, 2012 1:27 PM
>>Subject: [opensource-dev] Linux toolchain update... testers needed.
>> 
>>We're working on upgrading our Linux viewer build toolchain (moving to 
>>Debian Squeeze)...
>>
>>I've got a test build that I'd like some Linux users to try to see if it 
>>works for them:
>>
>>http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/don_viewer-development/rev/257957/arch/Linux/installer/SecondLife-i686-3.3.3.257957.tar.bz2
>>
>>Please respond here or directly to me (don't create Jira issues yet, 
>>please).
>>
>>___
>>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] Linux toolchain update... testers needed.

[Nicky Perian]

Logged to aditi w/o issue

Second Life 3.3.3 (257957) May 24 2012 17:25:24 (Second Life Development)
Release Notes

You are at 255426.0, 256396.0, 32.9 in Morris located at 
sim7028.aditi.lindenlab.com (216.82.40.145:12035)
Second Life Server 12.04.30.255166
Release Notes

CPU: Intel(R) Core(TM) i5 CPU         650  @ 3.20GHz (3201 MHz)
Memory: 7932 MB
OS Version: Linux 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: ATI Radeon HD 5450    

OpenGL Version: 4.2.11566 Compatibility Profile Context

libcurl Version: libcurl/7.21.1 OpenSSL/1.0.0d zlib/1.2.5 c-ares/1.7.1
J2C Decoder Version: KDU v6.4.1
Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.11.753 / OpenAL Community / 
OpenAL Soft: PulseAudio Software
Qt Webkit Version: 4.7.1 (version number hard-coded)
Voice Server Version: Vivox 3.2.0002.10426

Built with GCC version 40103
Packets Lost: 0/2662 (0.0%)



>
> From: Oz Linden (Scott Lawrence) 
>To: opensource-dev  
>Sent: Tuesday, June 5, 2012 1:27 PM
>Subject: [opensource-dev] Linux toolchain update... testers needed.
> 
>We're working on upgrading our Linux viewer build toolchain (moving to 
>Debian Squeeze)...
>
>I've got a test build that I'd like some Linux users to try to see if it 
>works for them:
>
>http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/don_viewer-development/rev/257957/arch/Linux/installer/SecondLife-i686-3.3.3.257957.tar.bz2
>
>Please respond here or directly to me (don't create Jira issues yet, 
>please).
>
>___
>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] linux build errors

[Nicky D.]

> anyone else receiving this and is there a workaround?

It had been once discussed on the mailinglist. That code is really a bit
hackerish and would need some love.

One of the (still hacked) workarounds can be found here
https://bitbucket.org/NickyD/viewer-development/changeset/0c2cb53f7

Cheers,
   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] Linux build without the pausing behaviour

[Oz Linden (Scott Lawrence)]

On 2011-03-28 10:53, leliel wrote:
> On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbi  wrote:
>> Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
>>   ha scritto:
>>
>>> Is there a Linux build of V2 of any version that doesnt exhibit the
>>> annoying multi-second pauses that freeze the UI?  I find myself without
>>> any useable V2 viewer at present.  I've tried 2.5.2 and 2.6.3 and both
>>> still have this issue.
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-autobuild2010/latest.html
>

That branch is expected to merge back to viewer-development later this 
week, so the fix should be in the beta next week and the general release 
the week after next.


___
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] Linux build without the pausing behaviour

[leliel]

On Mon, Mar 28, 2011 at 9:16 AM, Mike Chase
 wrote:
> On 03/28/2011 10:53 AM, leliel wrote:
>>
>> On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbi  wrote:
>>>
>>> Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
>>>   ha scritto:
>>>
 Is there a Linux build of V2 of any version that doesnt exhibit the
 annoying multi-second pauses that freeze the UI?  I find myself without
 any useable V2 viewer at present.  I've tried 2.5.2 and 2.6.3 and both
 still have this issue.
>>
>>
>> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-autobuild2010/latest.html
>>
> Is this a special build with the fix?  I hjave 2.6.3 which still exhibits
> the problem.  And yes I'd agree with others. I've seen this problem reported
> for quite some time yet no fix seems to make it into the released builds.

It's the autobuild development branch which has several updated libs
including a fixed libcurl.
___
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] Linux build without the pausing behaviour

[Mike Chase]

On 03/28/2011 10:53 AM, leliel wrote:
> On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbi  wrote:
>> Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
>>   ha scritto:
>>
>>> Is there a Linux build of V2 of any version that doesnt exhibit the
>>> annoying multi-second pauses that freeze the UI?  I find myself without
>>> any useable V2 viewer at present.  I've tried 2.5.2 and 2.6.3 and both
>>> still have this issue.
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-autobuild2010/latest.html
>
Is this a special build with the fix?  I hjave 2.6.3 which still 
exhibits the problem.  And yes I'd agree with others. I've seen this 
problem reported for quite some time yet no fix seems to make it into 
the released builds.

Mike

___
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] Linux build without the pausing behaviour

[leliel]

On Mon, Mar 28, 2011 at 8:59 AM, Opensource Obscure
 wrote:
> QA department apart, I / we should have done more testing.
> I think I remember I had seen this, but I didn't bother to properly
> investigate it / compare to other releases / file a report.

It was first reported on December 22, the same day the bug was
introduced. And was subsequently acknowledged by several Lindens in
late December and early January. Yet the bug still made it through 3
releases and counting. I don't think we as a community are the ones
that dropped the ball here.
___
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] Linux build without the pausing behaviour

[Opensource Obscure]

On Mon, Mar 28, 2011 at 17:04, Boroondas Gupte
 wrote:
> On 03/28/2011 04:41 PM, Mike Chase wrote:
>
> Is there a Linux build of V2 of any version that doesnt exhibit the
> annoying multi-second pauses that freeze the UI?  I find myself without
> any useable V2 viewer at present.  I've tried 2.5.2 and 2.6.3 and both
> still have this issue.

I'm currently using the Autobuild development release which has been
mentioned above. Note that in this build some other important features
are broken, at least for me (I don't get any HTTP content). I still use it
because the performances degradation in 2.5 is too annoying to me.


> I guess you're seeing the effects of STORM-809?
>
> How in the world did this every get past QA?  It really renders the
> viewer unusable.
>
> The effect of doing blocking domain name lookup is probably less noticeable
> the faster the internet connection is. If you even have a local nameserver
> which has most queried domains cached, you would hardly see any difference.
> (Note that this was even mentioned as a workaround.)

I installed pdns but Second Life performances didn't improve much.
Geography may have a role here...I have a ~200ms ping time
(minimum) when connecting to Second Life servers. This is common
to all users connecting from Italy, as far as I can tell.


> So it could be that the QA department has such a caching nameserver, at
> least somewhere in their LAN, and thus didn't notice this.

Good point. I suggest they make sure they are NOT using such
a caching system, if it can hide issues as big as this one.

QA department apart, I / we should have done more testing.
I think I remember I had seen this, but I didn't bother to properly
investigate it / compare to other releases / file a report.

-- 
Opensource Obscure
http://twitter.com/oobscure - http://opensourceobscure.com/lol
___
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] Linux build without the pausing behaviour

[Boroondas Gupte]

On 03/28/2011 04:41 PM, Mike Chase wrote:
> Is there a Linux build of V2 of any version that doesnt exhibit the 
> annoying multi-second pauses that freeze the UI?  I find myself without 
> any useable V2 viewer at present.  I've tried 2.5.2 and 2.6.3 and both 
> still have this issue.
I guess you're seeing the effects of STORM-809
?

> How in the world did this every get past QA?  It really renders the 
> viewer unusable.
The effect of doing blocking domain name lookup is probably less
noticeable the faster the internet connection is. If you even have a
local nameserver which has most queried domains cached, you would hardly
see any difference. (Note that this was even mentioned

as a workaround.)

So it could be that the QA department has such a caching nameserver, at
least somewhere in their LAN, and thus didn't notice this.

Boroondas
___
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] Linux build without the pausing behaviour

[Discrete Dreamscape]

It's due to libcurl, noted in STORM-809, and supposedly fixed (in the
autobuild repo)? If someone can verify that, maybe you can build it and
solve your problem, otherwise you'll have to build your own libcurl to drop
in. Another alternative seems to be maintaining your own DNS server/cache,
but that's pretty unnecessary IMO.

On Mon, Mar 28, 2011 at 10:50 AM, Francesco Rabbi  wrote:

> Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
>  ha scritto:
>
> > Is there a Linux build of V2 of any version that doesnt exhibit the
> > annoying multi-second pauses that freeze the UI?  I find myself without
> > any useable V2 viewer at present.  I've tried 2.5.2 and 2.6.3 and both
> > still have this issue.
> >
> > How in the world did this every get past QA?  It really renders the
> > viewer unusable. I've been using Imprudence the last few days which is
> > nice but a huge shift in UI and I've actually gotten both used to and
> > productive with the V2 paradigm.
>
> Can you explain better the kind of pause? I don't notice sort of...
>
>
>
> --
> Sent by iPhone
> ___
> 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] Linux build without the pausing behaviour

[leliel]

On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbi  wrote:
> Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
>  ha scritto:
>
>> Is there a Linux build of V2 of any version that doesnt exhibit the
>> annoying multi-second pauses that freeze the UI?  I find myself without
>> any useable V2 viewer at present.  I've tried 2.5.2 and 2.6.3 and both
>> still have this issue.

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-autobuild2010/latest.html

>> How in the world did this every get past QA?  It really renders the
>> viewer unusable. I've been using Imprudence the last few days which is
>> nice but a huge shift in UI and I've actually gotten both used to and
>> productive with the V2 paradigm.

I've been wondering that myself.

> Can you explain better the kind of pause? I don't notice sort of...

STORM-809
___
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] Linux build without the pausing behaviour

[Francesco Rabbi]

Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
 ha scritto:

> Is there a Linux build of V2 of any version that doesnt exhibit the
> annoying multi-second pauses that freeze the UI?  I find myself without
> any useable V2 viewer at present.  I've tried 2.5.2 and 2.6.3 and both
> still have this issue.
>
> How in the world did this every get past QA?  It really renders the
> viewer unusable. I've been using Imprudence the last few days which is
> nice but a huge shift in UI and I've actually gotten both used to and
> productive with the V2 paradigm.

Can you explain better the kind of pause? I don't notice sort of...



-- 
Sent by iPhone
___
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] Linux build error: missing binary operator before token "("

[Boroondas Gupte]

On 02/19/2011 08:30 PM, Nicky D. wrote:
>> [...]
>> [19:13:30]: [LogScan] /usr/include/bits/huge_val.h:30:20: error: missing
>> binary operator before token "("
>> [...]
> Tried it today, getting that too. Huge slew of errors.
>
> Even though this looks intimidating, the reason is really simple.
>
> In OZ's version of json there is a file features.h in
> ../include/json/. Metaphorical
> speaking there he laid the bomb.
> It is then trigged in cmake/JsonCpp.cmake and newview/CMakeList.txt
>
> JsonCpp.cmake  sets JSONCPP_INCLUDE_DIRS to ${LIBS_PREBUILD_DIR)/include/json.
> newview/CMakeList.txt adds JSONCPP_INCLUDE_DIRS to the system include dirs.
>
> Now the the problem with gcc is, that adding include dirs with -I
> makes them be searched
> before the system include dirs.
> And there our little bomb goes off. Because now the compiler findes
> the features.h file
> first in ../include/json. When it fact it needs the system one from
> /usr/include/features.h.
That analysis looks correct, so go ask Oz about that Eternal Glory he
offered on IRC. :-)

> One solution might be to use the -I- switch or -iquote for new gcc
> versions. But lucky
> enough there is a trivially simple fix, just use
> ${LIBS_PREBUILD_DIR)/include for
> JSONCPP_INCLUDE_DIRS.
>
> I attached a patch that does just this.
I just tested, and reverting eeb812d81330

(the changeset that switched to the new json download) works as a
workaround, too. Though, I guess your change is the preferred way to fix
this issue, because

   1. there probably was a reason for updating jsoncpp
   2. the other jsoncpp headers in the package also have very generic
  names, so using the containing dir as a way of namespacing will
  probably avoid further conflicts in the future


> Standalone builds might need
> some extra hackery,
> I did not try one of those yet.
Since 7690f4cb5e81
, the
jsoncpp include was probably broken for standalone anyway. (Can't test,
as standalone fails due to other (unrelated) errors.)

Cheers,
Boroondas
___
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] Linux build error: missing binary operator before token "(" (was: Hacking up to Visual Studio 2010 ...)

[Nicky D.]

> [19:13:30]: LogScan (1s)
> [19:13:30]: [LogScan] from /usr/include/c++/4.1.3/cmath:53,
> [19:13:30]: [LogScan] from
> /var/opt/teamcity/checkout/L-oz_viewer-autobuild2010/latest/indra/llcommon/linden_common.h:48,
> [19:13:30]: [LogScan] from
> /var/opt/teamcity/checkout/L-oz_viewer-autobuild2010/latest/indra/newview/tests/lldateutil_test.cpp:26:
> [19:13:30]: [LogScan] /usr/include/bits/huge_val.h:28:18: error: missing
> binary operator before token "("
> [19:13:30]: [LogScan] /usr/include/bits/huge_val.h:30:20: error: missing
> binary operator before token "("
>
> With "build" in the second command instead of "configure", I'm getting the
> same error, though not just for /usr/include/bits/huge_val.h but many more
> system headers, too.
>

Tried it today, getting that too. Huge slew of errors.

Even though this looks intimidating, the reason is really simple.

In OZ's version of json there is a file features.h in
../include/json/. Metaphorical
speaking there he laid the bomb.
It is then trigged in cmake/JsonCpp.cmake and newview/CMakeList.txt

JsonCpp.cmake  sets JSONCPP_INCLUDE_DIRS to ${LIBS_PREBUILD_DIR)/include/json.
newview/CMakeList.txt adds JSONCPP_INCLUDE_DIRS to the system include dirs.

Now the the problem with gcc is, that adding include dirs with -I
makes them be searched
before the system include dirs.
And there our little bomb goes off. Because now the compiler findes
the features.h file
first in ../include/json. When it fact it needs the system one from
/usr/include/features.h.

One solution might be to use the -I- switch or -iquote for new gcc
versions. But lucky
enough there is a trivially simple fix, just use
${LIBS_PREBUILD_DIR)/include for
JSONCPP_INCLUDE_DIRS.

I attached a patch that does just this. Standalone builds might need
some extra hackery,
I did not try one of those yet.

Cheers,
   Nicky
# HG changeset patch
# User Nicky 
# Date 1298143658 -3600
# Node ID ab363082f660e186ce0bfef8bf455b6d932c2663
# Parent  07163388fcb99b292843648c6256946cc622976f
Do not add /include/json as an include director. Instead use /include.
Otherwise include/json/features.h will mask /usr/include/features.

diff -r 07163388fcb9 -r ab363082f660 indra/cmake/JsonCpp.cmake
--- a/indra/cmake/JsonCpp.cmake	Fri Feb 18 12:50:16 2011 -0500
+++ b/indra/cmake/JsonCpp.cmake	Sat Feb 19 20:27:38 2011 +0100
@@ -18,5 +18,5 @@
   elseif (LINUX)
 set(JSONCPP_LIBRARIES libjson_linux-gcc-4.3.2_libmt)
   endif (WINDOWS)
-  set(JSONCPP_INCLUDE_DIRS ${LIBS_PREBUILT_DIR}/include/json)
+  set(JSONCPP_INCLUDE_DIRS ${LIBS_PREBUILT_DIR}/include)
 endif (STANDALONE)
diff -r 07163388fcb9 -r ab363082f660 indra/newview/lltranslate.cpp
--- a/indra/newview/lltranslate.cpp	Fri Feb 18 12:50:16 2011 -0500
+++ b/indra/newview/lltranslate.cpp	Sat Feb 19 20:27:38 2011 +0100
@@ -33,7 +33,7 @@
 #include "llversioninfo.h"
 #include "llviewercontrol.h"
 
-#include "reader.h"
+#include "json/reader.h"
 
 // These two are concatenated with the language specifiers to form a complete Google Translate URL
 const char* LLTranslate::m_GoogleURL = "http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=";;
___
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] Linux 64bit and gstreamer

[Aidan Thornton]

On 12/12/10, Argent Stonecutter  wrote:
> You know what would really help people get over the hump of setting up for
> building SL?
>
> A VMware appliance containing a working SL build environment, for 32 and 64
> bit Linux.

It's sort of vaguely on my TODO list, possibly including a way of
creating all the prebuilt library bundles needed to make an actual SL
release. There are certain practical and licensing issues, though.
Also, being able to actually run Second Life within the VM could be
fun...
___
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] Linux 64bit and gstreamer

[Ambrosia]

On Mon, Dec 13, 2010 at 10:28, Ambrosia  wrote:
> On Mon, Dec 13, 2010 at 05:27, Mike Chase
>  wrote:
>> On 12/12/2010 10:48 PM, Marc Adored wrote:
>>> Yes 32bit SLVoice can run with 64bit viewer because the viewer is not
>>> using it as a lib its a network connection between each other so none
>>> of that matters.
>>>
>> Ok, so maybe one thing that might be considered for a 64 bit build is to
>> build the core client 64bit but do the voice and SLPlugin stuff as
>> 32bit.  Can the build scripts be taught to do that? It seems building
>> standalone with such a config would produce a fully functional client
>> (all the pieces would work).
>>
>> Mike
>
> I personally would also be interested in the opposite as well.
> I hate building standalone (Come on LL, why can't you provide 64bit
> prebuilds? It's not like 64bit OSes are exotic anymore), so on my
> 64bit Debian system, I build a 32bit client with the necessary libs
> installed in /*/lib32/ (as opposed to, say, a pure chroot)
>
> Naturally this makes media playback fail due to there being no 32bit
> gstreamer libs installed, and getting those properly setup with all
> dependencies can be a nightmare. A 32bit SLPlugin build communicating
> with the 64bit client would solve that.

Er, I meant a 64bit SLPlugin communicating with the 32bit client, in
my case, of course. :3
___
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] Linux 64bit and gstreamer

[Ambrosia]

On Mon, Dec 13, 2010 at 05:27, Mike Chase
 wrote:
> On 12/12/2010 10:48 PM, Marc Adored wrote:
>> Yes 32bit SLVoice can run with 64bit viewer because the viewer is not
>> using it as a lib its a network connection between each other so none
>> of that matters.
>>
> Ok, so maybe one thing that might be considered for a 64 bit build is to
> build the core client 64bit but do the voice and SLPlugin stuff as
> 32bit.  Can the build scripts be taught to do that? It seems building
> standalone with such a config would produce a fully functional client
> (all the pieces would work).
>
> Mike

I personally would also be interested in the opposite as well.
I hate building standalone (Come on LL, why can't you provide 64bit
prebuilds? It's not like 64bit OSes are exotic anymore), so on my
64bit Debian system, I build a 32bit client with the necessary libs
installed in /*/lib32/ (as opposed to, say, a pure chroot)

Naturally this makes media playback fail due to there being no 32bit
gstreamer libs installed, and getting those properly setup with all
dependencies can be a nightmare. A 32bit SLPlugin build communicating
with the 64bit client would solve that.
___
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] Linux 64bit and gstreamer

[Mike Chase]

On 12/12/2010 10:48 PM, Marc Adored wrote:
> Yes 32bit SLVoice can run with 64bit viewer because the viewer is not
> using it as a lib its a network connection between each other so none
> of that matters.
>
Ok, so maybe one thing that might be considered for a 64 bit build is to 
build the core client 64bit but do the voice and SLPlugin stuff as 
32bit.  Can the build scripts be taught to do that? It seems building 
standalone with such a config would produce a fully functional client 
(all the pieces would work).

Mike

> On Sun, Dec 12, 2010 at 9:03 PM, Mike Chase
>   wrote:
>> On 12/12/2010 04:09 PM, Argent Stonecutter wrote:
>>> You know what would really help people get over the hump of setting up for 
>>> building SL?
>>>
>>> A VMware appliance containing a working SL build environment, for 32 and 64 
>>> bit Linux.
>> Or a KVM/qemu image assuming the target audience is running 64bit Linux.
>>
>> On a related note, the voice components are proprietary.  Is it possible
>> to get them to work?  Can you use a 32 voice and SLPlugin component with
>> the 64bit application?
>>
>> Mike
>>
>> ___
>> 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] Linux 64bit and gstreamer

[Marc Adored]

Yes 32bit SLVoice can run with 64bit viewer because the viewer is not
using it as a lib its a network connection between each other so none
of that matters.

On Sun, Dec 12, 2010 at 9:03 PM, Mike Chase
 wrote:
> On 12/12/2010 04:09 PM, Argent Stonecutter wrote:
>> You know what would really help people get over the hump of setting up for 
>> building SL?
>>
>> A VMware appliance containing a working SL build environment, for 32 and 64 
>> bit Linux.
> Or a KVM/qemu image assuming the target audience is running 64bit Linux.
>
> On a related note, the voice components are proprietary.  Is it possible
> to get them to work?  Can you use a 32 voice and SLPlugin component with
> the 64bit application?
>
> Mike
>
> ___
> 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] Linux 64bit and gstreamer

[Argent Stonecutter]

On 2010-12-12, at 20:03, Mike Chase wrote:
> On 12/12/2010 04:09 PM, Argent Stonecutter wrote:
>> You know what would really help people get over the hump of setting up for 
>> building SL?
>> 
>> A VMware appliance containing a working SL build environment, for 32 and 64 
>> bit Linux.

> Or a KVM/qemu image assuming the target audience is running 64bit Linux.

VMware Player runs just fine under 64 bit Linux. I have a number of users using 
that combination for their meagre Windows needs.

Really, an OVF image would be best, so it can be run under any VM.

___
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] Linux 64bit and gstreamer

[Mike Chase]

On 12/12/2010 04:09 PM, Argent Stonecutter wrote:
> You know what would really help people get over the hump of setting up for 
> building SL?
>
> A VMware appliance containing a working SL build environment, for 32 and 64 
> bit Linux.
Or a KVM/qemu image assuming the target audience is running 64bit Linux.

On a related note, the voice components are proprietary.  Is it possible 
to get them to work?  Can you use a 32 voice and SLPlugin component with 
the 64bit application?

Mike

___
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