Re: [opensource-dev] Error related to libndof when trying to compile SL on Ubuntu (attempt 2)
On 2020-02-07 20:52, Henri Beauchamp wrote: > [rant] > You can thank LL for not providing support for Linux; while they > benefit > for free from all the work done by GNU/Linux developers and while SL > won't even exist without their work (especially on the server side of > things, but even the viewer is using a shitload of Open Source > components > that have been primarily developed under and for GNU/Linux). > That's how LL is repaying the Open Source community when they could > just "devote" one developer to simply reuse the work TPV developers did > for Linux, and provide a Linux supported viewer. > > Hell ! I've been maintaining (and vastly improving) my own viewer (and > not just for Linux) for the past 13 years, alone, and only on part of > my > sparse free time: don't tell me a programmer at LL cannot maintain a > Linux viewer: all what it would take them (once their viewer is brought > on par with TPVs' Linux support) is just a couple of hours of work *per > week* ! > [/rant] Agreed 100% Though I have given up hope of LL ever changing their stance (based on some recent events). I wont say anymore because the temptation to also start a rant of my own on the subject is there. I think you pretty much covered it. Maybe one day pigs will fly and LL will go back to providing a Linux viewer. A. ___ 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] 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:
[opensource-dev] Python and autobuild
Hi Guys, This question is directed at the Lab. Python 2.7 becomes EOL as of Jan 1st 2020. Which is not far away. Is there any work underway to make autobuild compatible with Python 3? -- 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] SL server issues in the past 4 months
Hi Oz, Perhaps the SL grid status page should list teleports as in a degraded state rather than fully operational. TPV's are being blamed for this issue by many users. Listing a service "operational" also implies fully operational with no issues. On 2019-04-09 00:49, Oz Linden (Scott Lawrence) wrote: > On 2019-04-08 09:27 , Henri Beauchamp wrote: > >> In the hope my observations will help you guys to get things back on >> track (because it's getting really badly needed). > > Thank you Henri. > > We are very much aware of these problems and trying hard to correct them, but > I believe you may have added some useful insights; I've forwarded your > message to the two teams I have attacking them. > > -- > OZ LINDEN | Senior Director, Second Life Engineering > email: o...@lindenlab.com | Scott Lawrence [1] > LINDEN LAB | Create Virtual Experiences [2] > ___ > 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 -- Kind Regards, Alex. Links: -- [1] https://www.linkedin.com/in/scottdlawrence/ [2] https://www.lindenlab.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] compiling viewer-release on linux
On 2018-08-09 06:25, Cinder Roxley wrote: > autobuild configure -c ReleaseOS You are building with the proprietary libs. > You need to build an opensource autobuild target: > ___ Ty :) Is there a way to have the viewer use FMOD by default instead of alsa? I have provisioned FMOD and it only gets used if I uncomment a line in the startup script: export LL_BAD_OPENAL_DRIVER=x That will make the viewer use FMOD and it works perfectly. Is editing the script the only way to make it default? Cheers, A.___ 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] compiling viewer-release on linux
Hi All,
I am being brave and giving this a go..
Can someone explain this:
checking llappearance_utility
downloading llappearance_utility:
http://s3-proxy.lindenlab.com/private-builds-secondlife-com/hg/repo/p64_viewer-llappearance-utility/rev/317266/arch/Linux/installer/llappearance_utility-0.0.1-linux-317266.tar.bz2
to
/var/tmp/alex/install.cache/llappearance_utility-0.0.1-linux-317266.tar.bz2
error: HTTP Error 401: Unauthorized
Is this actually needed? If I grep through the sources, I find only
linux references to llappearanceutility - nothing for windows, mac..
And for LLAppearanceUtility.cmake (which gets included by
CMakeLists.txt) it seems relevant only for linux? Why?
# -*- cmake -*-
include(Prebuilt)
include(Boost)
# Linux proprietary build only
if (INSTALL_PROPRIETARY)
if(LINUX)
use_prebuilt_binary(llappearance_utility)
set(LLAPPEARANCEUTILITY_SRC_DIR
${LIBS_PREBUILT_DIR}/llappearanceutility/src)
set(LLAPPEARANCEUTILITY_BIN_DIR
${CMAKE_BINARY_DIR}/llappearanceutility)
endif (LINUX)
endif (INSTALL_PROPRIETARY)
Assuming its not needed, how can I drop the requirement for this during
the configure phase of the build?
--
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
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
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 x64 - libmedia_plugin_cef.so error
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
> 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
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
[opensource-dev] Linux x64 - libmedia_plugin_cef.so error
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
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
