From: Raf B. <raf...@gm...> - 2011-11-14 18:31:50
|
Hi all I've just recently been able to install player and stage on my system, after been helped out at this mailing list. I now find myself in a new problem, that is the shared libraries cannot be loaded. Richard Vaughan advised me http://old.nabble.com/Stage-install-error-tp32665566p32841906.html here that I had to take a look at README.txt - I ended up going through the information in INSTALL.txt. Here, it is stated that the location of the libraries must be added to certain paths. I'm rather sure I did this correctly. If I echo the different paths, I get this result: $ echo $LD_LIBRARY_PATH /usr/local/lib64 $ echo $STAGEPATH /usr/local/lib64 $ echo $PLAYERPATH /usr/local/lib64 (yes, I have a 64-bit OS) Of course, I also must be able to run the player and stage commands. Asking which to the bash gives this: $ which stage /usr/local/bin/stage $ which player /usr/local/bin/player Lastly, I checked whether the missing libraries (libstage.so.4.0.0 and libplayerdrivers.so.3.0). Now, in the folder /usr/local/lib64/ these files are located: liblododriver.so liblododriver.so.3.0 liblododriver.so.3.0.2 liblodo.so liblodo.so.3.0 liblodo.so.3.0.2 libplayercommon.so libplayercommon.so.3.0 libplayercommon.so.3.0.2 libplayercore.so libplayercore.so.3.0 libplayercore.so.3.0.2 libplayerc.so libplayerc++.so libplayerc.so.3.0 libplayerc++.so.3.0 libplayerc.so.3.0.2 libplayerc++.so.3.0.2 libplayerdrivers.so libplayerdrivers.so.3.0 libplayerdrivers.so.3.0.2 libplayerinterface.so libplayerinterface.so.3.0 libplayerinterface.so.3.0.2 libplayerjpeg.so libplayerjpeg.so.3.0 libplayerjpeg.so.3.0.2 libplayerreplace.so libplayerreplace.so.3.0 libplayerreplace.so.3.0.2 libplayertcp.so libplayertcp.so.3.0 libplayertcp.so.3.0.2 libplayerudp.so libplayerudp.so.3.0 libplayerudp.so.3.0.2 libplayerwkb.so libplayerwkb.so.3.0 libplayerwkb.so.3.0.2 libpmap.so libpmap.so.3.0 libpmap.so.3.0.2 libstage.so libstage.so.4.0.0 libwavefront_standalone.so libwavefront_standalone.so.3.0 libwavefront_standalone.so.3.0.2 pkgconfig python2.7 Stage-4.0 As far I understand these things, I should be able to use the stage and player commands to open the world samples. It's at that point I get this error, however, stating that the shared libraries cannot be loaded since there's no such file or directory. I hope I'm not asking too silly a question. Thanks for considering the problem. Raf -- View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32842463.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: Rich M. <jp...@gm...> - 2011-11-14 22:12:33
|
> -----Original Message----- > From: Raf Berkvens [mailto:raf...@gm...] > Sent: Monday, November 14, 2011 1:32 PM > To: pla...@li... > Subject: [Playerstage-users] stage: error while loading shared > libraries: libstage.so.4.0.0 > > > Hi all > > I've just recently been able to install player and stage on my system, > after > been helped out at this mailing list. I now find myself in a new > problem, > that is the shared libraries cannot be loaded. Richard Vaughan advised > me > http://old.nabble.com/Stage-install-error-tp32665566p32841906.html here > that I had to take a look at README.txt - I ended up going through the > information in INSTALL.txt. > > === snip === > > As far I understand these things, I should be able to use the stage and > player commands to open the world samples. It's at that point I get > this > error, however, stating that the shared libraries cannot be loaded > since > there's no such file or directory. > > I hope I'm not asking too silly a question. Thanks for considering the > problem. > Raf Does the thread at http://old.nabble.com/Player-Plugin-Driver%3A-libtool%3A-Undefined-Symbol-tt 32478974.html resemble your problem at all? Rich |
From: Raf B. <raf...@gm...> - 2011-11-15 07:26:06
|
No, I think not. Where in that thread the result of 'player *.cfg' are multiple errors and directly depended on libtool, mine is a single error depended on player and stage libraries. The output of the ldd command proposed in that thread might however be helpful in resolving the porblem: /usr/local/bin$ ldd stage linux-vdso.so.1 => (0x00007fff419c4000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f7902642000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f790242a000) libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f7902204000) libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f7901f97000) libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0x00007f7901c86000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f7901a72000) libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x00007f790185d000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f7901627000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f7901423000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7901206000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7901002000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f7900cc9000) libstage.so.4.0.0 => not found libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007f7900abf000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f79007b7000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7900533000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f790031d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f78fff7d000) libnvidia-tls.so.280.13 => /usr/lib/nvidia-current/tls/libnvidia-tls.so.280.13 (0x00007f78ffd7a000) libnvidia-glcore.so.280.13 => /usr/lib/nvidia-current/libnvidia-glcore.so.280.13 (0x00007f78fdf2e000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f78fdd25000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f78fda8d000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f78fd882000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f78fd657000) /lib64/ld-linux-x86-64.so.2 (0x00007f790288e000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f78fd43b000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f78fd237000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f78fd031000) /usr/local/bin$ ldd player linux-vdso.so.1 => (0x00007fffcd3fe000) libplayerdrivers.so.3.0 => not found libplayercore.so.3.0 => not found libplayercommon.so.3.0 => not found libplayertcp.so.3.0 => not found libplayerudp.so.3.0 => not found libplayerinterface.so.3.0 => not found libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f91b59a1000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f91b569a000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f91b5483000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f91b50e4000) /lib64/ld-linux-x86-64.so.2 (0x00007f91b5be5000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f91b4e60000) In my opinion, this supports the idea that there is some PATH variable missing to point the binaries to the folder of the libraries, i.e. /usr/local/lib64. Rich Mattes-2 wrote: > > Does the thread at > http://old.nabble.com/Player-Plugin-Driver%3A-libtool%3A-Undefined-Symbol-tt32478974.html > resemble your problem at all? > > Rich > -- View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32845856.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: Rich M. <jp...@gm...> - 2011-11-15 18:23:21
|
> -----Original Message----- > From: Raf Berkvens [mailto:raf...@gm...] > Sent: Tuesday, November 15, 2011 2:26 AM > To: pla...@li... > Subject: Re: [Playerstage-users] stage: error while loading shared > libraries: libstage.so.4.0.0 > > > No, I think not. Where in that thread the result of 'player *.cfg' are > multiple errors and directly depended on libtool, mine is a single > error > depended on player and stage libraries. > > The output of the ldd command proposed in that thread might however be > helpful in resolving the porblem: > /usr/local/bin$ ldd stage > > In my opinion, this supports the idea that there is some PATH variable > missing to point the binaries to the folder of the libraries, i.e. > /usr/local/lib64. > A copy/paste of the error messages would be helpful. My first inclination is that the LD_LIBRARY_PATH is set incorrectly, but it seems like you've fixed that. You might have missed the PKG_CONFIG_PATH when you configured Stage, which means that Stage wouldn't have found Player and built stageplugin.so. But without seeing the error, it could be anything. Rich |
From: Raf B. <raf...@gm...> - 2011-11-16 07:37:24
|
The exact Stage error: $ stage simple.world stage: error while loading shared libraries: libstage.so.4.0.0: cannot open shared object file: No such file or directory The exact Player error: $ player simple.cfg player: error while loading shared libraries: libplayerdrivers.so.3.0: cannot open shared object file: No such file or directory Echoing $PKG_CONFIG_PATH returns empty, indeed. I thought I had done that sometime, but then again I've been installing and uninstalling this many times I might have missed it. Would it explain the error when trying player, too? There is a pkgconfig entry in /usr/local/lib64/ though; that's where the *.so.*'s are. Rich Mattes-2 wrote: > > A copy/paste of the error messages would be helpful. My first inclination > is that the LD_LIBRARY_PATH is set incorrectly, but it seems like you've > fixed that. You might have missed the PKG_CONFIG_PATH when you configured > Stage, which means that Stage wouldn't have found Player and built > stageplugin.so. But without seeing the error, it could be anything. > > Rich > -- View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32852989.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: Richard V. <va...@sf...> - 2011-11-17 05:06:15
|
On Tue, Nov 15, 2011 at 23:37, Raf Berkvens <raf...@gm...> wrote: > $ player simple.cfg > player: error while loading shared libraries: libplayerdrivers.so.3.0: > cannot open shared object file: No such file or directory > Echoing $PKG_CONFIG_PATH returns empty, indeed. I thought I had done that pkg-config is only relevant at build time. This is a matter of run-time library path configuration: a normal UNIX software thing, and not specific to P/S. Have you read the instructions in the README files for Player and Stage that explain how to set up your environment? Bear in mind that the runtime library paths may be different on your machine (e.g. recent distros have changed their minds about how to handle 64-bit libraries). - rtv |
From: Rich M. <jp...@gm...> - 2011-11-16 16:39:26
|
> -----Original Message----- > From: Raf Berkvens [mailto:raf...@gm...] > Sent: Wednesday, November 16, 2011 2:37 AM > To: pla...@li... > Subject: Re: [Playerstage-users] stage: error while loading shared > libraries: libstage.so.4.0.0 > > > The exact Stage error: > $ stage simple.world > stage: error while loading shared libraries: libstage.so.4.0.0: cannot > open > shared object file: No such file or directory > > The exact Player error: > $ player simple.cfg > player: error while loading shared libraries: libplayerdrivers.so.3.0: > cannot open shared object file: No such file or directory > > Echoing $PKG_CONFIG_PATH returns empty, indeed. I thought I had done > that > sometime, but then again I've been installing and uninstalling this > many > times I might have missed it. Would it explain the error when trying > player, > too? > > There is a pkgconfig entry in /usr/local/lib64/ though; that's where > the > *.so.*'s are. > This is definitely a problem that LD_LIBRARY_PATH should solve. Doing $ export LD_LIBRARY_PATH=/usr/local/lib64 $ player simple.cfg results in the same error? Rich |
From: Raf B. <raf...@gm...> - 2011-11-17 07:36:44
|
Both last replies proved useful in me reviewing the PATHs. I had missed a crucial slash before the paths... so it was 'usr/local/lib64' instead of '/usr/local/lib64'. Thanks for having me retry this. Now stage runs fine, that is I see a map and a robot riding over it. Player gives me a new error: $ player simple.cfg Registering driver Player v.3.0.2 * Part of the Player/Stage/Gazebo Project [http://playerstage.sourceforge.net]. * Copyright (C) 2000 - 2009 Brian Gerkey, Richard Vaughan, Andrew Howard, * Nate Koenig, and contributors. Released under the GNU General Public License. * Player comes with ABSOLUTELY NO WARRANTY. This is free software, and you * are welcome to redistribute it under certain conditions; see COPYING * for details. error : Failed to load plugin stageplugin. error : libtool reports error: file not found error : plugin search path: /usr/local/lib64:/home/raf/playerstage_download/Stage-4.0.0-src/worlds:.:/usr/local/lib/ error : failed to load plugin: stageplugin error : failed to parse config file simple.cfg driver blocks I suspect that player and stage weren't linked correctly? So the easiest fix would be to reinstall again? Raf Rich Mattes-2 wrote: > > This is definitely a problem that LD_LIBRARY_PATH should solve. Doing > > $ export LD_LIBRARY_PATH=/usr/local/lib64 > $ player simple.cfg > > results in the same error? > > Rich > -- View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32860190.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: Rich M. <jp...@gm...> - 2011-11-18 13:14:02
|
> -----Original Message----- > From: Raf Berkvens [mailto:raf...@gm...] > Sent: Thursday, November 17, 2011 2:37 AM > To: pla...@li... > Subject: Re: [Playerstage-users] stage: error while loading shared > libraries: libstage.so.4.0.0 > > > Both last replies proved useful in me reviewing the PATHs. I had missed > a > crucial slash before the paths... so it was 'usr/local/lib64' instead > of > '/usr/local/lib64'. Thanks for having me retry this. > > Now stage runs fine, that is I see a map and a robot riding over it. > Player > gives me a new error: > $ player simple.cfg > Registering driver > Player v.3.0.2 > > * Part of the Player/Stage/Gazebo Project > [http://playerstage.sourceforge.net]. > * Copyright (C) 2000 - 2009 Brian Gerkey, Richard Vaughan, Andrew > Howard, > * Nate Koenig, and contributors. Released under the GNU General Public > License. > * Player comes with ABSOLUTELY NO WARRANTY. This is free software, and > you > * are welcome to redistribute it under certain conditions; see COPYING > * for details. > > error : Failed to load plugin stageplugin. > error : libtool reports error: file not found > error : plugin search path: > /usr/local/lib64:/home/raf/playerstage_download/Stage-4.0.0- > src/worlds:.:/usr/local/lib/ > error : failed to load plugin: stageplugin > error : failed to parse config file simple.cfg driver blocks > > I suspect that player and stage weren't linked correctly? So the > easiest fix > would be to reinstall again? > > Raf > > First, ensure that stageplugin.so actually exists. It should be in the same place as all of the rest of the shared libraries. If it does not exist, Stage couldn't find Player when it was built (probably due to a misconfigured PKG_CONFIG_PATH). Set the PKG_CONFIG_PATH to /usr/local/lib64/pkgconfig and re-run CMake for Stage. You should see messages indicating which version of Player was discovered. If you run make you should see mention of a "stageplugin" target in the output. If it does exist, you may be running into the symbol resolution I linked in a previous email. Since your LD_LIBRARY_PATH is set to the the stageplugin.so install directory, Player should have no problem finding stageplugin.so if it exists there. The previous email contained some debugging tips and a resolution. Rich |
From: Raf B. <raf...@gm...> - 2011-11-20 10:24:12
|
I made sure that stageplugin.so exists. I also ldd'd it, and it can find al its dependencies. My guess is that I run into a similar error as in that http://old.nabble.com/Player-Plugin-Driver%3A-libtool%3A-Undefined-Symbol-tt32478974.html previous mail you linked. Running: $ LD_PRELOAD=/usr/local/lib64/stageplugin.so player simple.cfg Returns: player: symbol lookup error: /usr/local/lib64/libstage.so.4.0.0: undefined symbol: _ZTI12Fl_Gl_Window This is a different undefined symbol, giving the same error. I'm a bit cautious with diving into the source code to resolve this error. Maybe someone can point me in the good direction? It would even seem to be an OpenGL problem (Gl_Window). Rich Mattes-2 wrote: > > First, ensure that stageplugin.so actually exists. It should be in the > same > place as all of the rest of the shared libraries. > > If it does not exist, Stage couldn't find Player when it was built > (probably > due to a misconfigured PKG_CONFIG_PATH). Set the PKG_CONFIG_PATH to > /usr/local/lib64/pkgconfig and re-run CMake for Stage. You should see > messages indicating which version of Player was discovered. If you run > make > you should see mention of a "stageplugin" target in the output. > > If it does exist, you may be running into the symbol resolution I linked > in > a previous email. Since your LD_LIBRARY_PATH is set to the the > stageplugin.so install directory, Player should have no problem finding > stageplugin.so if it exists there. The previous email contained some > debugging tips and a resolution. > > Rich > -- View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32869051.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: Weyn M. <maa...@ar...> - 2011-11-20 12:37:12
|
Zorg dat wouter asap 32bit versie installeerd zodat jullie al met player leren werken En je zo snel mogelijk een eenvoudige particle filter kan implementeren Maarten Weyn docent IW:elektronica-ICT industriële wetenschappen en technologie: elektronica-ict applied engineering: electronics-ict Artesis Hogeschool Antwerpen Artesis University College of Antwerp Paardenmarkt 92 B-2000 Antwerpen M +32 496 50 31 67 T +32 3 213 79 41 maa...@ar... http://www.artesis.be jij je passie, wij de opleiding On 20-nov.-2011, at 10:26, "Raf Berkvens" <raf...@gm...> wrote: > > I made sure that stageplugin.so exists. I also ldd'd it, and it can find al > its dependencies. My guess is that I run into a similar error as in that > http://old.nabble.com/Player-Plugin-Driver%3A-libtool%3A-Undefined-Symbol-tt32478974.html > previous mail you linked. > > Running: $ LD_PRELOAD=/usr/local/lib64/stageplugin.so player simple.cfg > Returns: player: symbol lookup error: /usr/local/lib64/libstage.so.4.0.0: > undefined symbol: _ZTI12Fl_Gl_Window > > This is a different undefined symbol, giving the same error. I'm a bit > cautious with diving into the source code to resolve this error. Maybe > someone can point me in the good direction? It would even seem to be an > OpenGL problem (Gl_Window). > > > Rich Mattes-2 wrote: >> >> First, ensure that stageplugin.so actually exists. It should be in the >> same >> place as all of the rest of the shared libraries. >> >> If it does not exist, Stage couldn't find Player when it was built >> (probably >> due to a misconfigured PKG_CONFIG_PATH). Set the PKG_CONFIG_PATH to >> /usr/local/lib64/pkgconfig and re-run CMake for Stage. You should see >> messages indicating which version of Player was discovered. If you run >> make >> you should see mention of a "stageplugin" target in the output. >> >> If it does exist, you may be running into the symbol resolution I linked >> in >> a previous email. Since your LD_LIBRARY_PATH is set to the the >> stageplugin.so install directory, Player should have no problem finding >> stageplugin.so if it exists there. The previous email contained some >> debugging tips and a resolution. >> >> Rich >> > > -- > View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32869051.html > Sent from the playerstage-users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Weyn M. <maa...@ar...> - 2011-11-20 12:42:07
|
Sorry guys, i repies to the mailinglist instead of to raf alone! Maarten Weyn docent IW:elektronica-ICT industriële wetenschappen en technologie: elektronica-ict applied engineering: electronics-ict Artesis Hogeschool Antwerpen Artesis University College of Antwerp Paardenmarkt 92 B-2000 Antwerpen M +32 496 50 31 67 T +32 3 213 79 41 maa...@ar... http://www.artesis.be jij je passie, wij de opleiding On 20-nov.-2011, at 12:39, "Weyn Maarten" <maa...@ar...> wrote: > Zorg dat wouter asap 32bit versie installeerd zodat jullie al met player leren werken > En je zo snel mogelijk een eenvoudige particle filter kan implementeren > > Maarten Weyn > docent IW:elektronica-ICT > > > industriële wetenschappen en technologie: elektronica-ict > applied engineering: electronics-ict > > Artesis Hogeschool Antwerpen > Artesis University College of Antwerp > Paardenmarkt 92 > B-2000 Antwerpen > > > M +32 496 50 31 67 > T +32 3 213 79 41 > maa...@ar... > http://www.artesis.be > > jij je passie, wij de opleiding > > On 20-nov.-2011, at 10:26, "Raf Berkvens" <raf...@gm...> wrote: > >> >> I made sure that stageplugin.so exists. I also ldd'd it, and it can find al >> its dependencies. My guess is that I run into a similar error as in that >> http://old.nabble.com/Player-Plugin-Driver%3A-libtool%3A-Undefined-Symbol-tt32478974.html >> previous mail you linked. >> >> Running: $ LD_PRELOAD=/usr/local/lib64/stageplugin.so player simple.cfg >> Returns: player: symbol lookup error: /usr/local/lib64/libstage.so.4.0.0: >> undefined symbol: _ZTI12Fl_Gl_Window >> >> This is a different undefined symbol, giving the same error. I'm a bit >> cautious with diving into the source code to resolve this error. Maybe >> someone can point me in the good direction? It would even seem to be an >> OpenGL problem (Gl_Window). >> >> >> Rich Mattes-2 wrote: >>> >>> First, ensure that stageplugin.so actually exists. It should be in the >>> same >>> place as all of the rest of the shared libraries. >>> >>> If it does not exist, Stage couldn't find Player when it was built >>> (probably >>> due to a misconfigured PKG_CONFIG_PATH). Set the PKG_CONFIG_PATH to >>> /usr/local/lib64/pkgconfig and re-run CMake for Stage. You should see >>> messages indicating which version of Player was discovered. If you run >>> make >>> you should see mention of a "stageplugin" target in the output. >>> >>> If it does exist, you may be running into the symbol resolution I linked >>> in >>> a previous email. Since your LD_LIBRARY_PATH is set to the the >>> stageplugin.so install directory, Player should have no problem finding >>> stageplugin.so if it exists there. The previous email contained some >>> debugging tips and a resolution. >>> >>> Rich >>> >> >> -- >> View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32869051.html >> Sent from the playerstage-users mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Playerstage-users mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-users > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Raf B. <raf...@gm...> - 2011-12-03 11:32:14
|
I've made a 32-bit virtual Ubuntu 11.10 machine and followed the same steps. I just ran into exactly the same error as I've mentioned here previously: Running: $ LD_PRELOAD=/usr/local/lib/stageplugin.so player simple.cfg Returns: player: symbol lookup error: /usr/local/lib/libstage.so.4.0.0: undefined symbol: _ZTI12Fl_Gl_Window I can't be the only having this issue, can I? Raf Berkvens wrote: > > I made sure that stageplugin.so exists. I also ldd'd it, and it can find > al its dependencies. My guess is that I run into a similar error as in > that > http://old.nabble.com/Player-Plugin-Driver%3A-libtool%3A-Undefined-Symbol-tt32478974.html > previous mail you linked. > > Running: $ LD_PRELOAD=/usr/local/lib64/stageplugin.so player simple.cfg > Returns: player: symbol lookup error: /usr/local/lib64/libstage.so.4.0.0: > undefined symbol: _ZTI12Fl_Gl_Window > > This is a different undefined symbol, giving the same error. I'm a bit > cautious with diving into the source code to resolve this error. Maybe > someone can point me in the good direction? It would even seem to be an > OpenGL problem (Gl_Window). > -- View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32907394.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: Rich M. <jp...@gm...> - 2011-12-04 03:01:39
|
On 12/03/2011 06:32 AM, Raf Berkvens wrote: > I've made a 32-bit virtual Ubuntu 11.10 machine and followed the same steps. > I just ran into exactly the same error as I've mentioned here previously: > > Running: $ LD_PRELOAD=/usr/local/lib/stageplugin.so player simple.cfg > Returns: player: symbol lookup error: /usr/local/lib/libstage.so.4.0.0: > undefined symbol: _ZTI12Fl_Gl_Window > > I can't be the only having this issue, can I? > Nope. The fix was identified the other day, more details at http://old.nabble.com/player-can%27t-find-stageplugin.so-td32902274.html Basically, you need to use target_link_libraries to link FLTK to stage; passing the LDFLAGS seems to not work on Ubuntu 11.10. Rich |
From: Raf B. <raf...@gm...> - 2011-12-04 12:07:42
|
Yes, indeed, this fixed it for 32-bit. So I can finally start using player and stage. I've immediately tried the same fix on 64-bit, without success. I've modified the libstage/CMakeLists.txt in the same way, added the cxx flags "-Wl,--no-as-needed" and tried make. I received following error, trimmed to the part where the error occurs: [ 72%] Building CXX object libstage/CMakeFiles/stage.dir/ancestor.o Linking CXX shared library libstage.so /usr/bin/ld: /usr/local/lib/libfltk.a(Fl.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libfltk.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [libstage/libstage.so.4.0.0] Error 1 make[1]: *** [libstage/CMakeFiles/stage.dir/all] Error 2 make: *** [all] Error 2 I've tried to put the -fPIC flag on some places, at CMAKE_CXX_FLAGS (unknown flag error here), at CMAKE_C_FLAGS and CMAKE_C_FLAGS_RELEASE, both giving no new error nor fixing the other error. Any way I can resolve this new error? Rich Mattes-2 wrote: > > Nope. The fix was identified the other day, more details at > http://old.nabble.com/player-can%27t-find-stageplugin.so-td32902274.html > Basically, > you need to use target_link_libraries to link FLTK to stage; passing the > LDFLAGS seems to not work on Ubuntu 11.10. > > Rich > -- View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32911770.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: Rich M. <jp...@gm...> - 2011-12-04 19:31:43
|
On 12/04/2011 07:07 AM, Raf Berkvens wrote: > Yes, indeed, this fixed it for 32-bit. So I can finally start using player > and stage. I've immediately tried the same fix on 64-bit, without success. > I've modified the libstage/CMakeLists.txt in the same way, added the cxx > flags "-Wl,--no-as-needed" and tried make. I received following error, > trimmed to the part where the error occurs: > > [ 72%] Building CXX object libstage/CMakeFiles/stage.dir/ancestor.o > Linking CXX shared library libstage.so > /usr/bin/ld: /usr/local/lib/libfltk.a(Fl.o): relocation R_X86_64_32 against > `.bss' can not be used when making a shared object; recompile with -fPIC > /usr/local/lib/libfltk.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > make[2]: *** [libstage/libstage.so.4.0.0] Error 1 > make[1]: *** [libstage/CMakeFiles/stage.dir/all] Error 2 > make: *** [all] Error 2 > > I've tried to put the -fPIC flag on some places, at CMAKE_CXX_FLAGS (unknown > flag error here), at CMAKE_C_FLAGS and CMAKE_C_FLAGS_RELEASE, both giving no > new error nor fixing the other error. Any way I can resolve this new error? > > Is there any reason you're using your own version of FLTK instead of the ones included with your distribution? Rich |
From: Raf B. <raf...@gm...> - 2011-12-04 19:49:21
|
For all I knew I wasn't. However, something tells me that I've been installing fltk sometime before installing player and stage, since it was written somewhere that it was a dependency. If I read you correctly, I've been overwriting previously installed libraries? I'm assuming there's no easy way to fix this, right? Rich Mattes-2 wrote: > > Is there any reason you're using your own version of FLTK instead of the > ones included with your distribution? > > Rich > -- View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32913678.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: Rich M. <jp...@gm...> - 2011-12-05 14:12:15
|
> -----Original Message----- > From: Raf Berkvens [mailto:raf...@gm...] > Sent: Sunday, December 04, 2011 2:49 PM > To: pla...@li... > Subject: Re: [Playerstage-users] stage: error while loading shared > libraries: libstage.so.4.0.0 > > > For all I knew I wasn't. However, something tells me that I've been > installing fltk sometime before installing player and stage, since it > was written somewhere that it was a dependency. If I read you > correctly, I've been overwriting previously installed libraries? I'm > assuming there's no easy way to fix this, right? > The presence of libfltk.a in /usr/local/lib tends to indicate that Stage is trying to link against a custom-built version of FLTK (since package managers never put their files in /usr/local.) I recommend you uninstall the custom FLTK version and install fltk1.1-dev from ubuntu. The distribution-provided package doesn't seem to break anything for anyone else using 64 bit ubuntu. Rich |
From: Raf B. <raf...@gm...> - 2011-12-05 16:24:54
|
Indeed, your suggestion made me solve it. I first removed every bit of libfltk I had with apt-get remove, since I had already deleted the manual install directories for a make uninstall. This was not enough, so I downloaded the latest stable version of libfltk (1.3), and installed manually again. Did didn't work either (you suggested that it wouldn't work), so I could now manually uninstall the latest libfltk. Then I got the libfltk1.1 from apt-get install, checked whether cmake found it and there I was, installing stage. Thanks for the help! Raf Rich Mattes-2 wrote: > > The presence of libfltk.a in /usr/local/lib tends to indicate that Stage > is > trying to link against a custom-built version of FLTK (since package > managers never put their files in /usr/local.) I recommend you uninstall > the custom FLTK version and install fltk1.1-dev from ubuntu. The > distribution-provided package doesn't seem to break anything for anyone > else > using 64 bit ubuntu. > > Rich > -- View this message in context: http://old.nabble.com/stage%3A-error-while-loading-shared-libraries%3A-libstage.so.4.0.0-tp32842463p32918428.html Sent from the playerstage-users mailing list archive at Nabble.com. |