From: Jorge S. S. <jsa...@gm...> - 2010-02-11 16:30:59
|
Hello, After (futile) struggling to compile player on windows, now I'll try to use the new player binaries, but I'm quite confused about what can and cannot do with this release: Can I port a plugin driver wrote on Linux to use it on Windows (with visual studio 2008)? Has anyone tried this? It will be complicated? (I know almost nothing about CMake). Thank you very much |
From: Geoff <gb...@ki...> - 2010-02-11 16:38:00
|
You could try the example plugin driver. I vaguely recall testing compiling it in Windows. What problems did you have compiling Player on Windows? If we don't know, we can't fix them. Geoff ----- Original message ----- From: "Jorge Santos Simón" <jsa...@gm...> To: pla...@li... Date: Thu, 11 Feb 2010 17:30:28 +0100 Subject: [Playerstage-users] About Player-3.01.exe windows installer Hello, After (futile) struggling to compile player on windows, now I'll try to use the new player binaries, but I'm quite confused about what can and cannot do with this release: Can I port a plugin driver wrote on Linux to use it on Windows (with visual studio 2008)? Has anyone tried this? It will be complicated? (I know almost nothing about CMake). Thank you very much |
From: Geoff <gb...@ki...> - 2010-02-12 08:04:26
|
Do you have any form of pkg-config installed? If the cmake modules find a pkg-config program, they will use that to try and find the Player libraries, which is what it looks like is happening (except that pkg-config is failing to find them). I'm not sure what's happening with the SVN version. Can you set your locale to English and post the error again? If you are compiling Player on Windows, you do not need a UNIX environment emulator, and having one is likely to cause problems because CMake will try to use the files from it rather than the Windows replacements included with Player. Make sure you follow the instructions on the Player wiki for Windows: http://playerstage.sourceforge.net/wiki/Windows http://playerstage.sourceforge.net/wiki/Compiling_Player_3_clients_and_plugins Geoff On Fri, 12 Feb 2010 01:22 +0100, "Jorge Santos Simón" <jsa...@gm...> wrote: > Making some progress, but... > > No luck with the CMake path; I gest I must include a CMAKE_MODULE_PATH > entry pointing to Player\share\cmake\Modules in CMake, but this > doesn't work. Anyway, I manage to contour this problem by just copying > the player .cmake files in the CMake 2.6\share\cmake-2.6\Modules > directory (for sure, not a so elegant solution). When doing that, the > error changes to: > > checking for module 'playerc' > package 'playerc' not found > CMake Error at C:/Program Files/CMake > 2.6/share/cmake-2.6/Modules/FindPkgConfig.cmake:270 (message): > A required package was not found > Call Stack (most recent call first): > C:/Program Files/CMake > 2.6/share/cmake-2.6/Modules/FindPkgConfig.cmake:322 > (_pkg_check_modules_internal) > C:/Program Files/CMake > 2.6/share/cmake-2.6/Modules/UsePlayerPlugin.cmake:24 > (pkg_check_modules) > CMakeLists.txt:6 (INCLUDE) > ... > > > > 2nd approach: compiling the SVN exampledriver. Windows finds the .dll > (if not, the error is different), so something deeper is happening. > > > And finally, the hole player compilation. After avoiding all warnings, > the errors look more tractable. Most of them come from expected > sources: unistd.h, sys/_types.h... > Question for people compiling with Visual .net: What UNIX environment > are you using? cygwin or mingw? |
From: gte199t <gt...@pr...> - 2010-02-14 03:59:21
|
Hello world, out of curiousity I downloaded player for windows... I'm a linux player user and I was curious about progress on "that" front. Ofcourse I didn't have visual studio installed so I decided to see how far I could get with cygwin. I tested with Windows 7 professional, Cygwin 1.7.1, Player v.3.0.1 (precompiled and source tarball). First, it seems that the precompiled player binary does have some drivers included since I was able to "use" the passthrough driver and not the roomba driver. I wasn't able to see a list of the included drivers, although player tells me that there are 58 before it hangs. Correction, using the command prompt it hangs and windows tries to find a solution (which I don't let it). Using the cygwin bash shell, it doens't hang. C:\Program Files\Player\share\player\config>player passthrough.cfg Registering driver Player v.3.0.1 * 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. Warning: failed to setlocale(); config file may not be parse correctly listening on 6665 Listening on ports: 6665 $ player roomba.cfg Registering driver Player v.3.0.1 * 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. Warning: failed to setlocale(); config file may not be parse correctly error : Couldn't find driver "roomba" error : failed to parse config file roomba.cfg driver blocks $ player Registering driver Player v.3.0.1 USAGE: player [options] [<configfile>] Where [options] can be: -h : print this message. -d <level> : debug message level (0 = none, 1 = default, 9 = all). -p <port> : port where Player will listen. Default: 6665 -q : quiet mode: minimizes the console output on startup. -l <logfile> : log player output to the specified file <configfile> : load the the indicated config file The following 58 drivers were compiled into Player: Since the VS users are told to go grab source (even though sourceforge's download section says as a windows user I don't need to grab a tarball since it's for the "others"), I tested the waters of cmake and player on cygwin. I was able to get much of the ususal suspects using setup.exe but there were a couple of thingss on the player side which were not quite ready for cygwin. Had to tweak findos.cmake so that it would behave "nicely" # Windows is easy (for once)... sorry scratch that... IF (WIN32) # Check is it's CYGWIN or "real" windoze IF (NOT UNIX) SET (PLAYER_OS_WIN TRUE BOOL INTERNAL) ELSE (NOT UNIX) UNSET (WIN32) ENDIF (NOT UNIX) ENDIF (WIN32) Voila! cmake worked, but make didn't. The first try had some integer definition problems which I "dealt" with (please help me... this might have been a bad hack) Com@Com-PC /cygdrive/c/source/player-3.0.1/build $ make [ 0%] Built target playercommon [ 0%] Generating functiontable_gen.h [ 0%] Built target functiontable_gen [ 0%] Generating interface_table.h [ 1%] Built target interface_table [ 1%] Generating player_interfaces.h [ 1%] Built target player_interfaces [ 1%] Building C object replace/CMakeFiles/playerreplace.dir/xdr.c.o In file included from /cygdrive/c/source/player-3.0.1/replace/xdr.c:50: /cygdrive/c/source/player-3.0.1/replace/rpc/types.h:91: error: conflicting types for 'int64_t' /usr/include/stdint.h:21: error: previous declaration of 'int64_t' was here /cygdrive/c/source/player-3.0.1/replace/rpc/types.h:92: error: conflicting types for 'uint64_t' /usr/include/stdint.h:30: error: previous declaration of 'uint64_t' was here /cygdrive/c/source/player-3.0.1/replace/xdr.c: In function `xdr_hyper': /cygdrive/c/source/player-3.0.1/replace/xdr.c:215: warning: right shift count >= width of type /cygdrive/c/source/player-3.0.1/replace/xdr.c:224: warning: left shift count >= width of type /cygdrive/c/source/player-3.0.1/replace/xdr.c: In function `xdr_u_hyper': /cygdrive/c/source/player-3.0.1/replace/xdr.c:246: warning: right shift count >= width of type /cygdrive/c/source/player-3.0.1/replace/xdr.c:255: warning: left shift count >= width of type make[2]: *** [replace/CMakeFiles/playerreplace.dir/xdr.c.o] Error 1 make[1]: *** [replace/CMakeFiles/playerreplace.dir/all] Error 2 make: *** [all] Error 2 I "fixed" this in types.h by adding the ifndefs thus keeping the existing definitions #ifndef __int8_t_defined typedef signed long int int64_t; typedef unsigned long int uint64_t; #endif I've also had to disable mricp, readlog, playerjoy and a couple of other utils for now... I really wanted to test all the drivers I could... Readlog failed (I think) because the "-lz" was at the beginning of the compile line and not to the end. I've seen some buzz about this when compiling object files. I couldn't figure out the proper place to fix this so I punked out. [ 80%] Building CXX object server/libplayerdrivers/CMakeFiles/playerdrivers.dir/ __/drivers/base/imagebase.cc.o Linking CXX shared library cygplayerdrivers-3.0.1.dll CMakeFiles/playerdrivers.dir/__/drivers/shell/readlog.cc.o:readlog.cc:(.text+0xe78): undefined reference to `_gzopen' CMakeFiles/playerdrivers.dir/__/drivers/shell/readlog.cc.o:readlog.cc:(.text+0xfaa): undefined reference to `_gzclose' CMakeFiles/playerdrivers.dir/__/drivers/shell/readlog.cc.o:readlog.cc:(.text+0x10b1): undefined reference to `_gzseek' CMakeFiles/playerdrivers.dir/__/drivers/shell/readlog.cc.o:readlog.cc:(.text+0x11c4): undefined reference to `_gzgets' Creating library file: libplayerdrivers.dll.a collect2: ld returned 1 exit status make[2]: *** [server/libplayerdrivers/cygplayerdrivers-3.0.1.dll] Error 1 make[1]: *** [server/libplayerdrivers/CMakeFiles/playerdrivers.dir/all] Error 2 make: *** [all] Error 2 Is there any reason why make would forget where boost is located? I've gotten as far as 93% of the build once and it complained about that of all things. Running make again doens't always even get back to the place where things crapped out. Deleting the build and rerunning cmake tends to cure this, but that is a painfully solution because it just adds more build time. [ 92%] Built target playercam Scanning dependencies of target playernav [ 92%] Building C object utils/playernav/CMakeFiles/playernav.dir/playernav.c.o [ 93%] Building C object utils/playernav/CMakeFiles/playernav.dir/gui.c.o [ 93%] Building C object utils/playernav/CMakeFiles/playernav.dir/player.c.o [ 93%] Building C object utils/playernav/CMakeFiles/playernav.dir/parse.c.o Linking C executable playernav.exe [ 93%] Built target playernav Scanning dependencies of target playerprint [ 93%] Building CXX object utils/playerprint/CMakeFiles/playerprint.dir/playerprint.cc.o In file included from /cygdrive/c/source/player-3.0.1/client_libs/libplayerc++/playerc++.h:61, from /cygdrive/c/source/player-3.0.1/utils/playerprint/playerprint.cc:105: /cygdrive/c/source/player-3.0.1/client_libs/libplayerc++/playerclient.h:66:30: boost/signal.hpp: No such file or directory /cygdrive/c/source/player-3.0.1/client_libs/libplayerc++/playerclient.h:70:36: boost/thread/mutex.hpp: No such file or directory /cygdrive/c/source/player-3.0.1/client_libs/libplayerc++/playerclient.h:71:37: boost/thread/thread.hpp: No such file or directory /cygdrive/c/source/player-3.0.1/client_libs/libplayerc++/playerclient.h:72:36: boost/thread/xtime.hpp: No such file or directory /cygdrive/c/source/player-3.0.1/client_libs/libplayerc++/playerclient.h:73:28: boost/bind.hpp: No such file or directory Surely this isn't the first time boost is used.... so how should I trouble shoot? For now I'm going to just remove it from cmake and do it all over again.. sigh.. Com@Com-PC /cygdrive/c/source/player-3.0.1/build2 $ cmake -D ENABLE_DRIVER_READLOG:BOOL=OFF -D ENABLE_DRIVER_MRICP:BOOL=OFF -D BUILD_UTILS_PLAYERJOY:BOOL=OFF -D BUILD_UTILS_PLAYERPRINT:BOOL=OFF -D BUILD_UTILS_PLAYERPOP:BOOL=OFF -D BUILD_UTILS_PLAYERVCR:BOOL=OFF -D BUILD_UTILS_PLAYERWRITEMAP:BOOL=OFF -D BUILD_UTILS_PMAP:BOOL=OFF -D BUILD_UTILS_XMMS:BOOL=OFF .. But finally... after a short walk to inspect the snow.. [100%] Building C object utils/playerv/CMakeFiles/playerv.dir/pv_dev_vectormap.c.o Linking C executable playerv.exe [100%] Built target playerv make install'ed and then added /usr/local/lib/ (c:\cygwin\usr\local\lib) to the path environment variable since there's no ldconfig on cygwin $ player Registering driver Player v.3.0.1 USAGE: player [options] [<configfile>] Where [options] can be: -h : print this message. -d <level> : debug message level (0 = none, 1 = default, 9 = all). -p <port> : port where Player will listen. Default: 6665 -q : quiet mode: minimizes the console output on startup. -l <logfile> : log player output to the specified file <configfile> : load the the indicated config file The following 98 drivers were compiled into Player: AioToSonar accel_calib acts amcl amtecpowercube aodv bitlogic blobtodio blobtracker bumper2laser bumper_safe bumpertodio cameracompress camerauncompress camfilter canonvcc4 clodbuster cmdsplitter cmucam2 cmvision create deadstop diocmd diodelay diolatch dummy epuck erratic fakelocalize festival flockofbirds garminnmea globalize goto gridmap gripcmd inhibitor insideM300 iwspy kartowriter khepera laserbar laserbarcode lasercspace lasercutter laserposeinterpolator laserptzcloud laserrescan lasersafe lasertoranger localbb mapcspace mapfile mapscale mbicp mica2 microstrain3dmg motionmind nd nomad_driver obot p2os passthrough pbs03jn ptu46 rangerposeinterpolator rangertodio rangertolaser relay rflex roboteq robotracker roomba rs4leuze rt3xxx segwayrmp400 serialstream serio sickLDMRS sicklms200 sicklms400 sicknav200 sickpls sickrfi341 sicks3000 skyetekM1 snd sonartoranger sonyevid30 stalltodio suppressor tcpstream vec2map velcmd vfh vmapfile wavefront writelog I may actually try to use it sometime soon.. but I have to get back to what I was supposed to have been doing for the past 5 hours Anyone want to figure out how to get artoolkit into cygwin? Also, I haven't seen /dev/video0 nor /dev/input/js0 but I'm guessing that a plugin driver can be written for cameras... (very useful but may also need ffmpeg for max flexibility). nAnd for that matter the joystick could also warrant a plugin... (maybe plib based? Hmmmm... deeper question there) Fortunately other devices are more civilized... :) /dev/dsp Default sound device of the system. /dev/ttyS0 Serial communication devices. ttyS0 == Win32 COM1, /dev/ttyS1 ttyS1 == COM2, etc. ... Hope this helps someone. -- View this message in context: http://old.nabble.com/About-Player-3.01.exe-windows-installer-tp27550170p27580741.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: Paul O. <new...@ki...> - 2010-02-14 09:28:28
|
On Sat, 13 Feb 2010, gte199t wrote: > > I "fixed" this in types.h by adding the ifndefs thus keeping the existing > definitions > > #ifndef __int8_t_defined > typedef signed long int int64_t; > typedef unsigned long int uint64_t; > #endif > I guess it would be better if cmake was able to detect if int64_t/uint64_t are defined and set HAVE_INT64_T and HAVE_UINT64_T preprocessor variables that could be used here. > > I've also had to disable mricp, readlog, playerjoy and a couple of other > utils for now... I really wanted to test all the drivers I could... > > Readlog failed (I think) because the "-lz" was at the beginning of the > compile line and not to the end. > I've seen some buzz about this when compiling object files. > I couldn't figure out the proper place to fix this so I punked out. > Old problem that I met using gcc on foreign (not-Linux and not-*BSD) platforms. I don't know cmake that much to help you, and there's no guarantee that it would actually help. > Also, I haven't seen /dev/video0 nor /dev/input/js0 but I'm guessing that a > plugin driver can be written for cameras... (very useful but may also need > ffmpeg for max flexibility). nAnd for that matter the joystick could also > warrant a plugin... (maybe plib based? Hmmmm... deeper question there) There's one camera driver written with Windows in mind already: cvcam. As I can see in your post, you didn't install OpenCV for Cygwin as all drivers depending on it are missing (there are couple of guides on how to compile OpenCV from sources on Cygwin; many years passed since I last used Cygwin, check twice, mabye OpenCV is now part of its distribution disabled by default, which wasn't the case at the time I was using it). Whole idea of writting cvcam driver started with that simple program: http://vlab.pjwstk.edu.pl/~vlabdemo/io/cam/cvgrab.c and Makefile for it: http://vlab.pjwstk.edu.pl/~vlabdemo/io/cam/Makefile it builds fine on all Unixes on which cross-platform OpenCV library can be installed and also on Windows with MinGW and OpenCV (in such a case OpenCV is installed using regular binary installer; well, it is easy to integrate it with MinGW, however it doesn't really mean that it can be integrated with Cygwin that easy, so if OpenCV is not provided by Cygwin itself it may be necessery to build it from sources using hints fron google and hoping that camera grabbing stuff will also build nicely). OpenCV provides camera grabbing functions capable to work with Video4Linux/Video4Linux2, video1394 and Windows WDM cameras (PCI framegrabbers, USB webcams and so on). Having cvgrab compiled on Linux and Windows, I've wrapped its code with Player driver infrastructure and here we are: cvcam driver that is now a part of official Player tree. > Fortunately other devices are more civilized... :) > > /dev/dsp Default sound device of the system. So what? Player does not use OSS (to which /dev/dsp is attached), it uses ALSA. I guess now ALSA is also available on Cygwin. At some time I proposed to write audio and joystick plugins that would use popular SDL cross-platform library (I guess Cygwin has it by default) so we could have both features on every system (I also proposed to use SDL threads instead of pthreads to help portability - at that time I didn't realise pthreads is so cross-platform library), however depending on one more huge library wasn't welcome then so I dropped the idea. It didn't happend to cvcam as number of Player drivers was already depending on OpenCV. I stopped to figth with Cygwin after I realised there's no way to compile Stage on it. I wonder what changed in that matter during last few years. Paul |