Re: [opensource-dev] Error related to libndof when trying to compile SL on Ubuntu (attempt 2)
Hi! Regarding FreeBSD.. You will not get this to work on FreeBSD without an absolute buttload of work.. For starters, autobuild would not recognize FreeBSD as a valid platform, you would need to hack it to support FreeBSD (or write your own build system). Many things would also be missing and would need implementing, like CEF and dullahan and voice support. Also, FreeBSD's OSS (open sound system) is not implemented in the viewer, so you'd probably have no sound. Then you would need to compile a metric tonne of dependent libraries for FreeBSD, or modify the build to use system wide libraries instead of trying to link against the packages ones that autobuild will try and download and link statically. I wouldnt even go there... Just Dont. lol. And yes, the linux build instructions are grossly out of date in LL's wiki. LL no longer provide a linux viewer or support it in any shape or form. A. On 2020-02-07 16:51, Andras Farkas wrote: Hello! I was watching a friend play Second Life and thought it looked cool (I'm really into MUCKs, so VR is a cool topic in general) so I decided I'd try to compile it on FreeBSD, my desktop OS. I decided to try compiling it on Ubuntu first, to examine the build process. However, I encountered an error related to libndof, as seen in the attached errout.txt Moreover, the info on the wiki related to ndof (and everything): http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux)#More_problematic_libraries_.28standalone.29 is so out of date that it isn't useful. Debian Squeeze and Lenny are ancient, and Ubuntu Lucid and Precise are too. http://apt.byteme.org.uk/ also no longer exists. And at least on Ubuntu Eoan Ermine, a package name has changed: libopenjpeg-dev --> libopenjp2-7-dev If you can let me know how to get past this error, I'd be grateful. Thanks! :D (this is the second attempt to send this, hope it works) ___ 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 Warning: no --id argument or AUTOBUILD_BUILD_ID environment variable specified; using a value from the UTC date and time (200360842), which may not be unique '/usr/bin/cmake' '-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo' '-DADDRESS_SIZE:STRING=64' '-DROOT_PROJECT_NAME:STRING=SecondLife' '-DINSTALL_PROPRIETARY=FALSE' '-G' 'Unix Makefiles' '../indra' -- Using PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig:/usr/local/share/pkgconfig -- Revision (from autobuild environment): 200360842 -- Building 'Second Life Test' Version 6.3.7.200360842 CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) llrender/CMakeLists.txt:6 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/base/CMakeLists.txt:14 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /us
[opensource-dev] Error related to libndof when trying to compile SL on Ubuntu (attempt 2)
Hello! I was watching a friend play Second Life and thought it looked cool (I'm really into MUCKs, so VR is a cool topic in general) so I decided I'd try to compile it on FreeBSD, my desktop OS. I decided to try compiling it on Ubuntu first, to examine the build process. However, I encountered an error related to libndof, as seen in the attached errout.txt Moreover, the info on the wiki related to ndof (and everything): http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux)#More_problematic_libraries_.28standalone.29 is so out of date that it isn't useful. Debian Squeeze and Lenny are ancient, and Ubuntu Lucid and Precise are too. http://apt.byteme.org.uk/ also no longer exists. And at least on Ubuntu Eoan Ermine, a package name has changed: libopenjpeg-dev --> libopenjp2-7-dev If you can let me know how to get past this error, I'd be grateful. Thanks! :D (this is the second attempt to send this, hope it works) Warning: no --id argument or AUTOBUILD_BUILD_ID environment variable specified; using a value from the UTC date and time (200360842), which may not be unique '/usr/bin/cmake' '-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo' '-DADDRESS_SIZE:STRING=64' '-DROOT_PROJECT_NAME:STRING=SecondLife' '-DINSTALL_PROPRIETARY=FALSE' '-G' 'Unix Makefiles' '../indra' -- Using PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig:/usr/local/share/pkgconfig -- Revision (from autobuild environment): 200360842 -- Building 'Second Life Test' Version 6.3.7.200360842 CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) llrender/CMakeLists.txt:6 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/base/CMakeLists.txt:14 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call first): cmake/OpenGL.cmake:11 (include) media_plugins/gstreamer010/CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.13/Modules/FindOpenGL.cmake:270 (message): Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when available. Run "cmake --help-policy CMP0072" for policy details. Use the cmake_policy command to set the policy and suppress this warning. FindOpenGL found both a legacy GL library: OPENGL_gl_LIBRARY: /usr/lib/x86_64-linux-gnu/libGL.so and GLVND libraries for OpenGL and GLX: OPENGL_opengl_LIBRARY: /usr/lib/x86_64-linux-gnu/libOpenGL.so OPENGL_glx_LIBRARY: /usr/lib/x86_64-linux-gnu/libGLX.so OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for compatibility with CMake 3.10 and below the legacy GL library will be used. Call Stack (most recent call f
Re: [opensource-dev] viewer-release vs The Penguins
On 2/6/2020 6:05, Nicky D. wrote: > The main reason why this happened is LL not wanting to have their own > Linux viewer depend on many 3Ps but rather use as much standalone > that you can find on a Linux system. That led to either snap, flatpak or > AppImage. I'm certainly interested in what you discover in containerizing the viewer. Distribution size, edge cases where things go wrong. Dropping it into a wsl2 instance on windows to see what happens... 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] viewer-release vs The Penguins
On Thu, 6 Feb 2020 12:05:17 +0100, Nicky D. wrote: > I know. I already looked at it for Firestorm. But LL won't let you > contribute this as we know due to their CA standards. I see... I was apparently mistaken by the 'vs' term in the subject of your message, and by the fact your viewer-linux sources was hosted on a private repository and not on LL's. I thought it was just a "generic Linux viewer" forked from LL's viewer-release, and as such, open to any Open Source developer's contributions (or at the very least, suggestions). > I'd really like to get rid of the GTK dependency. Even if only for > Firestorm. Like I suggested (if I'm still permitted to do that), you could also go the Qt route, which I believe would be much cleaner, easier, future-proof (GTK4 is already in the pipeline and will incur even harder breakages), and better for the end user (with Qt, as a user, you can choose the look and feel and the theme, including GTK2's if you fancy it !). > As long as we're speaking about a viewer LL might want to integrate > (debatable if it ever happens), taking contributions of others is out > of the question. Taking contribution from others without CA is > completely unthinkable. Like is unthinkable for me to sign a CA that requests personal information that go way beyond the purpose of such an agreement. LL shall respect the Law of the country of the contributor, with regard to their CA, and they simply don't. 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] viewer-release vs The Penguins
On Thu, Feb 6, 2020 at 11:45 AM Henri Beauchamp wrote: > On Tue, 4 Feb 2020 22:28:53 +0100, Nicky D. wrote: > > > it has been a while since LL released their last Linux capable viewer. To > > get things started > > again I brought 6.3.6 up to Linux support: > > https://bitbucket.org/NickyD/viewer-linux > > https://bitbucket.org/NickyD/viewer-flatpak (for the flatpak build > > scripts) > > > > As I know the chances to see a penguin fly are bigger than get a release > > from LL, I also created a flatpak that users can install and run > > (instructions below). > > I fail to see the advantage of a flatpak, when the current distribution > method (i.e. bundling libraries that are likely to lack on the user's > system, or that have been patched) do work nicely... Flatpaks are huge > and bloated with stuff that the viewer won't really need (but are just > non-essential dependencies to some libraries it uses). > > The main reason why this happened is LL not wanting to have their own Linux viewer depend on many 3Ps but rather use as much standalone that you can find on a Linux system. That led to either snap, flatpak or AppImage. Of course then due to time constraints they never picked it up. But that's the reason behind the current format. It is based on what I did for LL. > > - Uses GTK3 instead of GTK2, again to not have to compile the old GTK > > version. > > I solved the GTK dependency a looong while ago... By removing it > entirely ! > > I know. I already looked at it for Firestorm. But LL won't let you contribute this as we know due to their CA standards. I'd really like to get rid of the GTK dependency. Even if only for Firestorm. As long as we're speaking about a viewer LL might want to integrate (debatable if it ever happens), taking contributions of others is out of the question. Taking contribution from others without CA is completely unthinkable. > > - It's obviously unsupported. > > I provided and kept up to date the sources for a Linux-compatible Dullahan > since November 2015 on my site... That could count as "support", I think... > :-D > > Hehe I meant the viewer is unsupported. Everyone but LL has dullahan for Linux since ages. Then again LL has no Linux viewer since ages either. > Another thing you might want to look at is getting rid of the deprecated, > unsupported and utterly buggy dbus-glib dependency. I solved this a long > time ago by coding DBus support based on glib-gio (see llappviewerlinux.cpp > in my viewer sources): it's very clean and small code, that also does > properly work (dbus-glib got a timeout bug, unless you use a very old > version that no distro would provide any more nowadays, anyway). > > > I'm going to look at that. Thank you for the input. Again though likely going to look at it for Firestorm. ___ 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] viewer-release vs The Penguins
On Tue, 4 Feb 2020 22:28:53 +0100, Nicky D. wrote: > it has been a while since LL released their last Linux capable viewer. To > get things started > again I brought 6.3.6 up to Linux support: > https://bitbucket.org/NickyD/viewer-linux > https://bitbucket.org/NickyD/viewer-flatpak (for the flatpak build > scripts) > > As I know the chances to see a penguin fly are bigger than get a release > from LL, I also created a flatpak that users can install and run > (instructions below). I fail to see the advantage of a flatpak, when the current distribution method (i.e. bundling libraries that are likely to lack on the user's system, or that have been patched) do work nicely... Flatpaks are huge and bloated with stuff that the viewer won't really need (but are just non-essential dependencies to some libraries it uses). The alternative to both flatpaks and dynamic libraries bundling in the viewer distribution is to statically link all libraries that are likely to be missing on the user's system. That's what software like Firefox or Blender do for their pre-compiled Linux binaries distributions. > Differences in the Linux version: > - Uses SDL2 rather than SDL (so the "OS" version can be used). That's an interesting and useful change, that I'll probably pick-up for my own viewer: SDL2 is the path to the future anyway (with Wayland support, even though the latter is likely to stay inappropriate for running the viewer in the foreseeable future, since NVIDIA proprietary drivers don't support it and Open Source NVIDIA drivers are way too slow or right out incomplete). However, I would recommend to keep linking statically SDL2 to the viewer binary, since SDL2 is far from a mandatory prerequisite in many Linux distros (i.e. it is not always installed by default). > - Uses GTK3 instead of GTK2, again to not have to compile the old GTK > version. I solved the GTK dependency a looong while ago... By removing it entirely ! The viewer depends on GTK under Linux only for the text clipboard (and it is not even properly implemented with it), and for the file selector (which lacks proper threading, or causes threading bugs/slow downs when threading is attempted). My solution has been to re-code the clipboard stuff directly with Xlib primitives (with proper primary and secondary paste buffer support) and to code an XUI file selector, that also works for Windows and macOS by the way, with a code that is beautifully simple and largely OS-independent (only a few #if LL_WINDOWS here and there to deal with Windows file system peculiarities, such as with hidden files and drive volume names), since it relies on llcommon classes to deal with OS-dependent stuff. An alternative, if you want to keep an OS-dependent file selector, would be to migrate to Qt's: easier and cleaner to implement in C++... > - OpenAL instead of FMODEX, there's no way to download FMODEX anymore. > Once FMOD Studio gets into the viewer I add it to the Linux release. I got support for FMOD Studio in my viewer for a long while too. Quite easy to implement based on FMOD Ex implementation. The only loss is support for the (rarely used) OSS backend in FMOD (but OpenAL can use it, and I got both OpenAL and FMOD Studio supported in my Linux viewer). > - No KDU. I obviously don't have access to LLs version of KDU and won't > use the one I have for Firestorm. OpenJPEG does a good job anyway (pretty much as fast as KDU too, when compiled with SSE2/3 support). Just make sure to use a SL-compatible version (I use a heavily patched v1.4.0.635 personal fork, with security fixes and SSE optimizations backported from v2). Here again, OpenJPEG is best statically linked to the viewer (I even integrated its sources to the viewer sources, since they are so specific/heavily modified). > - GStreamer 1.0 instead of VLC. GStreamer being part of the OS it gets > updated by the OS (Flatpak in this case) rather than shipping some ancient > VLC version. I totally agree with you. Beside, like I already explained back in 2016 in this list, GStreamer would also be a better choice for Windows and macOS users: it only needs to be installed once and for all (i.e. no need to bundle a huge amount of libraries with the viewer, like is the case of VLC) and solves all software patent issues (users can choose what CODECs they install on their system, depending on where they live and/or how "sensitive" they are towards the patent issues). I use Gstreamer for all OSes in my viewer: never got a single complaint from any user for doing so... > - dullahan/CEF is added. So it got the usual web browser as Windows/OSX got. > - It's obviously unsupported. I provided and kept up to date the sources for a Linux-compatible Dullahan since November 2015 on my site... That could count as "support", I think... :-D Another thing you might want to look at is getting rid of the deprecated, unsupported and utterly buggy dbus-glib dependency. I solved this a long time ago by coding DBus support based on
