[opensource-dev] Linux Command Line run with out package

[Nicky Perian]

On windows the viewer can be built with _DPACKAGE:BOOL=OFF then with the 
short-cut properties Start in set to C:\Program 
Files\viewer-release\indra\newview;
you can then start the viewer.

I don’t recall how that is done with  linux build.

I think it is done with parameter passing.

Can someone refresh my memory?

Thanks,
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

[opensource-dev] Linux 64 build

[Nicky Perian]

Has anyone seen this before and know how to resolve it?

[  5%] Building CXX object llcommon/CMakeFiles/llcommon.dir/llallocator.cpp.o
In file included from 
/usr/include/x86_64-linux-gnu/c++/6/bits/c++config.h:507:0,
 from /usr/include/c++/6/cstring:41,
 from 
/home/nicky/kokua-sl-gcc6/indra/llcommon/linden_common.h:50,
 from 
/home/nicky/kokua-sl-gcc6/indra/llcommon/llallocator.cpp:27:
/usr/include/x86_64-linux-gnu/c++/6/bits/os_defines.h:44:19: error: missing 
binary operator before token "("
 #if __GLIBC_PREREQ(2,15) && defined(_GNU_SOURCE)

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

[opensource-dev] Linux viewer manage

[Nicky Perian]

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.


___
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(_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(_subprocess_path) there.
> Here is what I put in mine:
> #elif defined(__linux__)
> CefString(_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(_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(_subprocess_path) = "dullahan_host.exe";
#elif __APPLE__
NSString* appBundlePath = [[NSBundle mainBundle] bundlePath];
CefString(_subprocess_path) =
[[NSString stringWithFormat:
  
@"%@/Contents/Frameworks/DullahanHelper.app/Contents/MacOS/DullahanHelper", 
appBundlePath] UTF8String];
#elif defined(__linux__)
CefString(_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

[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(::on*Callback..., _1, ...))
with:
set*Callback(std:bind(::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

[opensource-dev] Linux x64 - libmedia_plugin_cef.so error

[Alex]

Hi Guys,

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.

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

[opensource-dev] Linux x64 questions

[Alex]

Hi All,

Just spotted a message that goes back to last month, by Henri, I want to
quote something that was said and ask a question:

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

Which version of CEF are you proposing everyone works with Henri? Is it
something recent? I am hoping we can move away from the dinosaur
versions of CEF that I see in some TPV's for Linux 64 (I am talking Pre
Ivy viewer here) as I am not sure what the story is with CEF versions
and Linux 64 with the current viewer code.

So how are people now building the viewer (or trying to build) it on
Linux x64?

I am guessing some are using the standalone procedure (now known as a
USESYSLIB version) since I have been told by someone that an end goal is
to produce a debian package file and have the viewer utilize system
libraries for a lot of things (therefore moving away from using a number
of prebuilt and statically linked libraries (hooray, about time, so many
of those libraries are ancient)).

Has the overall procedure for making a native system library version on
linux 64 changed?? What procedure used to work for me (admittedly a
while back now) no longer works. I am using the code from the Firestorm
LGPL repo.. It used to be, for me at least, on Linux, for a native
system library version, you could build a whole bunch of dependent
libraries and put them over in /usr/local (glod, collada and some
others) and these would be picked up by the build process. This no
longer seems to be the case. What I have observed:

* syslib build now tries to copy slvoice binaries+libs into the staging
area of the build and falls over This NEVER used to happen with a
systemlib build. The build would work fine. You would just have no voice
capability in the resulting viewer until you copied the files yourself
from the slvoice package into the right places.

* as a hack, I commented out the stuff that tries to copy the vivox
files.. build gets a little further, however it tells me it couldnt find
glod... Which I do have installed in /usr/local (built it myself) --
this is why I am making the deduction that the build process is not
paying attention to /usr/local anymore for its library search path.

Has the procedure for a syslib version changed drastically at some point
or has someone gone and ripped out the guts for linux syslib version
(ie: lots of things now missing in various cmake files etc)?

Would appreciate any insight people may have.

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

[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

[opensource-dev] Linux

[Nicky Perian]

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




___
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

[opensource-dev] Linux

[Nicky Perian]

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.

Will there be LL developed QA procedures for the linux builds?

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?

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 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 nickyper...@yahoo.com
To: opensource-dev@lists.secondlife.com 
opensource-dev@lists.secondlife.com; kokua-...@lists.kokuaviewer.org 
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

[opensource-dev] linux viewer building

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

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

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

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

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

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

[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 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 mo...@lindenlab.com
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

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

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 sl...@free.fr
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

[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

[opensource-dev] Linux boost shared libraries

[Nicky Perian]

What is the reason for the switch to boost shared libraries?

The other platforms seem to perform without issue using boost static libraries. ___
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) o...@lindenlab.com

 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.

[Ron Rogers Jr.]

On Tue, 05 Jun 2012 14:27:00 -0400
Oz Linden (Scott Lawrence) o...@lindenlab.com 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.

[Ron Rogers Jr.]

On Tue, 5 Jun 2012 21:31:51 +0200
Ambrosia chaoss...@gmail.com 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 15:59:18 -0400
Oz Linden (Scott Lawrence) o...@lindenlab.com 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.

[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) o...@lindenlab.com 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.

[Carlo Wood]

On Wed, 6 Jun 2012 13:59:02 -0700
Christian Goetze c...@miaow.com 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 ca...@alinoe.com
___
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 nickyper...@yahoo.com
To: Oz Linden (Scott Lawrence) o...@lindenlab.com; opensource-dev 
opensource-dev@lists.secondlife.com 
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) o...@lindenlab.com
To: opensource-dev opensource-dev@lists.secondlife.com 
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.

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

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

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

[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: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.

[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 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

[opensource-dev] Linux build without the pausing behaviour

[Mike Chase]

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.

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

[Francesco Rabbi]

Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
mike.ch...@alternatemetaverse.com 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 without the pausing behaviour

[leliel]

On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbi syt...@gmail.com wrote:
 Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
 mike.ch...@alternatemetaverse.com 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

[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 syt...@gmail.com wrote:

 Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
 mike.ch...@alternatemetaverse.com 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

[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
https://jira.secondlife.com/browse/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
https://jira.secondlife.com/browse/STORM-809?focusedCommentId=241064page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-241064
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

[Opensource Obscure]

On Mon, Mar 28, 2011 at 17:04, Boroondas Gupte
slli...@boroon.dasgupta.ch 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

[leliel]

On Mon, Mar 28, 2011 at 8:59 AM, Opensource Obscure
opensourceobsc...@gmail.com 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

[Mike Chase]

On 03/28/2011 10:53 AM, leliel wrote:
 On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbisyt...@gmail.com  wrote:
 Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
 mike.ch...@alternatemetaverse.com  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 9:16 AM, Mike Chase
mike.ch...@alternatemetaverse.com wrote:
 On 03/28/2011 10:53 AM, leliel wrote:

 On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbisyt...@gmail.com  wrote:

 Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
 mike.ch...@alternatemetaverse.com  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

[Oz Linden (Scott Lawrence)]

On 2011-03-28 10:53, leliel wrote:
 On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbisyt...@gmail.com  wrote:
 Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
 mike.ch...@alternatemetaverse.com  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 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 nickyd...@yahoo.com
# Date 1298143658 -3600
# Node ID ab363082f660e186ce0bfef8bf455b6d932c2663
# Parent  07163388fcb99b292843648c6256946cc622976f
Do not add jsonpath/include/json as an include director. Instead use jsonpath/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.0q=;;
___
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
https://bitbucket.org/jenn_linden/viewer-vs2010/changeset/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
https://bitbucket.org/jenn_linden/viewer-vs2010/changeset/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

[opensource-dev] Linux build error: missing binary operator before token ( (was: Hacking up to Visual Studio 2010 ...)

[Boroondas Gupte]

On 02/18/2011 01:56 AM, Oz Linden (Scott Lawrence) wrote:
 [...]

 Then check out:

 https://bitbucket.org/oz_linden/viewer-autobuild2010

 cd into the top level of that directory, and run:

 autobuild configure -c OpenSourceRelWithDebInfo

 autobuild configure -c OpenSourceRelWithDebInfo

 and let me know if it works (and if not, see if you can figure out why
 not).  On our build farm, I'm getting an error:

 _[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.

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

[opensource-dev] [linux] /usr/bin/ld: error: unsupported symbol binding

[Aleric Inglewood]

If you are using linux and get this error while compiling the viewer:

  /usr/bin/ld: error: unsupported symbol binding

(or, for that matter:

  /usr/bin/gold: error: unsupported symbol binding

then you are using ld.gold version 2.20.x.
You need to upgrade it to 2.21.

If you are using debian then you can get that
from experimental (but only if you know what
you're doing ;) .. don't upgrade your whole
system to experimental by accident!), as follows:

To /etc/apt/preferences add:

Package: *
Pin: release a=testing
Pin-Priority: 990

where 'testing' is YOUR CURRENT RELEASE! So,
replace it if you are not using testing.
This preference is to avoid that you upgrade
your whole system: it will prefer 'testing' or
whatever you use over the rest.

Next, add to /etc/apt/sources.list an entry
for experimental:

deb http://ftp.nl.debian.org/debian/ experimental main contrib non-free
deb-src http://ftp.nl.debian.org/debian/ experimental main contrib non-free

replace ftp.nl.debian.org with your own favourite
debian server.

Run apt-get update to get the info from
this new entry. Now you could try

apt-cache policy binutils

To see that it would NOT upgrade your binutils
because of the preferences ;).

Next, you can upgrade /usr/bin/gold with:

sudo apt-get install -t experimental binutils

I only tried this on testing though. If you have
an older distribution it might want to upgrade
more than just binutils. If that's the case then
don't do it.

Please note that if you'd install binutils-gold
(which is on experimental) then that will
remove your nvidia kernel module because
that is not compatible with ld.gold. You don't
want that ;).  However, just upgrading binutils
is ok, and then use LDFLAGS=-Wl,-use-gold
as before to cause the viewer compilation to
use gold.

Aleric

PS I used the same /etc/apt preferences and
/etc/apt/sources.list to get my nvidia driver
from experimental. As root:

update-pciids
apt-get install module-assistant
apt-get install -t experimental nvidia-kernel-source
m-a prepare
m-a clean nvidia
m-a a-i nvidia
apt-get install -t experimental nvidia-glx
depmod -a
modprobe nvidia

which gives me 260.19.21which supports
my video card, while testing still has the old
195.36.31that does not support it.
___
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
mike.ch...@alternatemetaverse.com 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

[Ambrosia]

On Mon, Dec 13, 2010 at 10:28, Ambrosia chaoss...@gmail.com wrote:
 On Mon, Dec 13, 2010 at 05:27, Mike Chase
 mike.ch...@alternatemetaverse.com 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

[Aidan Thornton]

On 12/12/10, Argent Stonecutter secret.arg...@gmail.com 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