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
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
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 possibl
On Fri, 23 Mar 2018 09:50:12 +1000, Alex wrote:
> Well that certainly got me further! Thank you! Its' at least _trying_ to
> start dullahan_host now, but some strange behavour:
>
> alex@desktop:~/ivyviewer$ grep dullahan trace.txt | pcregrep -o1
> '.*(execve\([a-z0-9\/_\"]+),'
> execve("/usr/lo
On 2018-03-23 02:00, Henri Beauchamp wrote:
> #elif defined(__linux__)
> CefString(&settings.browser_subprocess_path) = "dullahan_host";
> #endif
>
>
> Henri.
Well that certainly got me further! Thank you! Its' at least _trying_ to
start dullahan_host now, but some strange behavour:
alex@
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 awa
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 SLPl
On 2018-03-23 01:36, Henri Beauchamp wrote:
> On Thu, 22 Mar 2018 16:31:29 +0100, Henri Beauchamp wrote:
>
>> In my viewer, SLPlugin is never passed any other argument than the
>> port,
>> so maybe these arguments you see passed are an "extension" to
>> Firestorm's
>> plugin system...
>
> In fa
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 ste
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/i
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 reso
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,
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 ques
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::
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_c
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
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
> > _ZN8d
> 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_manager26setOnStatusMessageCallbackESt8functionI
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-
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.
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
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/b
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 y
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 Dul
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://
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_plugi
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 pe
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
p
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 str
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: _ZN
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 seein
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 se
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
> (
> 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
> (0x000
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_LIR
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
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.
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 i
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 gc
> 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 whee
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 o
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
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 S
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...@lindenl
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
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/c
>
> 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...
>
T
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,
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 instal
>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 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 r
>>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
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 las
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
Ple
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
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
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
>
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 t
aware.
am i wrong?
>
> From: Henri Beauchamp
>To: opensource-dev@lists.secondlife.com
>Sent: Monday, December 10, 2012 2:36 PM
>Subject: Re: [opensource-dev] Linux boost shared libraries
>
>On Sun, 9 Dec 2012 18:32:18 -0800 (PST), Nicky Pe
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 ?...
dows and darwin?
>
> From: Monty Brandenberg
>To: opensource-dev@lists.secondlife.com
>Sent: Monday, December 10, 2012 10:56 AM
>Subject: Re: [opensource-dev] Linux boost shared libraries
>
>On 12/9/2012 9:32 PM, Nicky Perian wrote:
>>
>> W
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 th
Runs as well as any other release on FreeBSD 8.3-Release amd64 w/ f10
linuxulator.
Kind regards,
-Cinder
On 6/5/2012 12:27 PM, Oz Linden (Scott Lawrence) wrote:
> We're working on upgrading our Linux viewer build toolchain (moving to
> Debian Squeeze)...
>
> I've got a test build that I'd like s
On Wed, 6 Jun 2012 13:59:02 -0700
Christian Goetze wrote:
> I believe the main challenge is to rebuild all the third party
> dependencies in 64bit ...
Rofl - something that LL certainly isn't capable of ;)
Loads of third party viewers have done this already
however. I have never used anything el
I believe the main challenge is to rebuild all the third party
dependencies in 64bit ...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated
Oz Linden (Scott Lawrence) wrote:
> There is no plan to do this.
>
> There is also not a plan not to do it.
>
> I don't know whether or not the new build systems this was created on
> are any better set up for 64 bit building than the old one they will
> replace were (I'll find out). However, eve
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
On Tue, 05 Jun 2012 15:59:18 -0400
"Oz Linden (Scott Lawrence)" wrote:
> There is no plan to do this.
>
> There is also not a plan not to do it.
>
Sigh...wasn't this suggested thing to do...4 years ago. I know I
complained about the lack of a 64-bit builds of LL releases 2 years
ago on my bl
On Tue, 5 Jun 2012 21:31:51 +0200
Ambrosia wrote:
> Oz, as an aside..
>
> Is there a plan to ever support building non-standalone on Linux
> 64bit without installing 32bit libraries or workarounds? It can be a
> nightmare with some distributions, and being forced to compile it as
> 32bit in 2012
On Tue, 05 Jun 2012 14:27:00 -0400
"Oz Linden (Scott Lawrence)" wrote:
> I've got a test build that I'd like some Linux users to try to see
> if it works for them:
>
>
> Please respond here or directly to me (don't create Jira issues
> yet, please).
>
>
Logged into main grid with it right now
Works as expected under Ubuntu 12.04 (AMD/gnome).
Freezing bug when saving a texture
https://jira.secondlife.com/browse/VWR-28846 still present. Seems
bug-for-bug compatible to me.
2012/6/5 Oz Linden (Scott Lawrence)
> We're working on upgrading our Linux viewer build toolchain (moving to
> D
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
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..wr
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
___
On 2012-06-05 15:33 , Johnnie Carling wrote:
>> Please respond here or directly to me (don't create Jira issues yet,
>> please).
> Crashes on startup on Debian Sid (see STORM-1854)
Bug-for-bug-compatible !
___
Policies and (un)subscribe information avail
> 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
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
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 info
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.secondlif
Do you have any specific tests to run?
>
> From: Nicky Perian
>To: Oz Linden (Scott Lawrence) ; opensource-dev
>
>Sent: Tuesday, June 5, 2012 1:56 PM
>Subject: Re: [opensource-dev] Linux toolchain update... testers needed.
>
>
&g
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
> 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,
On 2011-03-28 10:53, leliel wrote:
> On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbi wrote:
>> Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
>> ha scritto:
>>
>>> Is there a Linux build of V2 of any version that doesnt exhibit the
>>> annoying multi-second pauses that freeze the UI? I find
On Mon, Mar 28, 2011 at 9:16 AM, Mike Chase
wrote:
> On 03/28/2011 10:53 AM, leliel wrote:
>>
>> On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbi wrote:
>>>
>>> Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
>>> ha scritto:
>>>
Is there a Linux build of V2 of any version that doesnt exh
On 03/28/2011 10:53 AM, leliel wrote:
> On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbi wrote:
>> Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
>> ha scritto:
>>
>>> Is there a Linux build of V2 of any version that doesnt exhibit the
>>> annoying multi-second pauses that freeze the UI? I f
On Mon, Mar 28, 2011 at 8:59 AM, Opensource Obscure
wrote:
> QA department apart, I / we should have done more testing.
> I think I remember I had seen this, but I didn't bother to properly
> investigate it / compare to other releases / file a report.
It was first reported on December 22, the sam
On Mon, Mar 28, 2011 at 17:04, Boroondas Gupte
wrote:
> On 03/28/2011 04:41 PM, Mike Chase wrote:
>
> Is there a Linux build of V2 of any version that doesnt exhibit the
> annoying multi-second pauses that freeze the UI? I find myself without
> any useable V2 viewer at present. I've tried 2.5.2
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'
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 th
On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbi wrote:
> Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
> ha scritto:
>
>> Is there a Linux build of V2 of any version that doesnt exhibit the
>> annoying multi-second pauses that freeze the UI? I find myself without
>> any useable V2 viewer at
Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
ha scritto:
> Is there a Linux build of V2 of any version that doesnt exhibit the
> annoying multi-second pauses that freeze the UI? I find myself without
> any useable V2 viewer at present. I've tried 2.5.2 and 2.6.3 and both
> still have this
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.
>
> [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/
On 12/12/10, Argent Stonecutter wrote:
> You know what would really help people get over the hump of setting up for
> building SL?
>
> A VMware appliance containing a working SL build environment, for 32 and 64
> bit Linux.
It's sort of vaguely on my TODO list, possibly including a way of
creatin
On Mon, Dec 13, 2010 at 10:28, Ambrosia wrote:
> On Mon, Dec 13, 2010 at 05:27, Mike Chase
> wrote:
>> On 12/12/2010 10:48 PM, Marc Adored wrote:
>>> Yes 32bit SLVoice can run with 64bit viewer because the viewer is not
>>> using it as a lib its a network connection between each other so none
>>>
On Mon, Dec 13, 2010 at 05:27, Mike Chase
wrote:
> On 12/12/2010 10:48 PM, Marc Adored wrote:
>> Yes 32bit SLVoice can run with 64bit viewer because the viewer is not
>> using it as a lib its a network connection between each other so none
>> of that matters.
>>
> Ok, so maybe one thing that might
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 cl
Yes 32bit SLVoice can run with 64bit viewer because the viewer is not
using it as a lib its a network connection between each other so none
of that matters.
On Sun, Dec 12, 2010 at 9:03 PM, Mike Chase
wrote:
> On 12/12/2010 04:09 PM, Argent Stonecutter wrote:
>> You know what would really help pe
On 2010-12-12, at 20:03, Mike Chase wrote:
> On 12/12/2010 04:09 PM, Argent Stonecutter wrote:
>> You know what would really help people get over the hump of setting up for
>> building SL?
>>
>> A VMware appliance containing a working SL build environment, for 32 and 64
>> bit Linux.
> Or a KVM
On 12/12/2010 04:09 PM, Argent Stonecutter wrote:
> You know what would really help people get over the hump of setting up for
> building SL?
>
> A VMware appliance containing a working SL build environment, for 32 and 64
> bit Linux.
Or a KVM/qemu image assuming the target audience is running 64
1 - 100 of 128 matches
Mail list logo
