From: Paul O. <new...@ki...> - 2009-01-25 19:34:36
|
Hello Devels, As I announced in some post earlier, I'm opening new thread about my struggles to compile Player 2.2 (SVN) on Solaris 10 using Sun compiler from SunStudio 12 instead of gcc from csw development environment. So far csw (which offer gcc 2.95.3) was proven to be suitable to compile Player. Unfortunately, offered version of gcc is far too old so it is not possible to compile easily anything more than Player + utils (most noticable is Stage which needs huge amount of changes for succcesfull build). First step after installation of SunStudio 12 (both user and system wide installations are suitable) is to install cmake 2.6.x (I used cmake 2.6.2). It builds fine with suncc (csw itself offered cmake 2.4.8 which was also suitable for Player). Next, libtool must be isntalled as I didn't find any libltdl other than provided by csw (I used libtool 2.2). Other critical libraries (glib2, gtk2, gnomecanvas) are provided by Solaris 10 (Sun provides its own distribution of GNOME with all required libraries, so there is a choice for the user between using GNOME and good old CDE - ancient KDE; also csw offered its own GNOME distribution with libraries, I was using it while compiling Player with csw; nevertheless, I sticked with good old CDE). So far I didn't touch C++ client-side library, so I don't even know if it causes boost-related problems. *LINKING* The biggest problem I had was caused by linking issues that came from inline functions. Do we really need them? For the purpose of my attempts, I've removed all 'inline' directives, but someone more responsible for Player will have to make a statement if inlines should be changed to regular global functions. *LINKING* urglaser and rs4leuze couldn't be linked. The error was: Undefined first referenced symbol in file void urglaser_Register(DriverTable*) libplayerdrivers/libplayerdrivers.so.2.2.0 void rs4leuze_Register(DriverTable*) libplayerdrivers/libplayerdrivers.so.2.2.0 ld: fatal: Symbol referencing errors. No output written to player I don't know what happens, I've turned off both using ccmake. *CMAKE* One problem is caused by cmake which does not know that if function from math.h is used, -lm linker flag must be added: affected place is logsplitter utility which uses fabs() function. *CMAKE* Other problem with dependencies that I guess cmake should solve is that some functions from math library offered by Sun compiler aren't defined in <math.h>, there is one more header file called <ieeefp.h> which should be included if any of those functions must be used. Namely, it is finite() function, (typically defined in math.h, but not in Sun's compiler), it is used in server/drivers/localization/amcl/pf/pf_vector.c file. Other mathematical functions used in this file are available in regular <math.h> that it properly includes. I guess, cmake should check if ieeefp.h is available and if so, HAVE_IEEEFP (or something like that) should be defined, so pf_vector.c could use this in #ifdefs to include one more required header. *COMPATIBILITY* In many places __packed__ attribute is used. What for? It causes such a warning: 'attribute packed is unsupported and will be skipped..' Here are some easy to fix issues, for other bigger and more serious errors I'll soon release a serie of patches. All problems were caused by permissive nature of gcc compiler. 1. Missing headers: 1.1. client_libs/libplayerc/dev_ranger.c: stddef.h, stdlib.h 1.2. server/drivers/mixed/nomad/Nclient.c: string.h (see section 4 below for more problems with this file) 2. Unexpected comas: 2.1. server/drivers/mixed/erratic/erratic.h about line 96, last line of the typedef enum command 2.2. server/drivers/map/mapcspace.cc about line 100, last line of robot_shape_t enum 3. Unexpected semicolons: 3.1. client_libs/libplayerc/dev_speech_recognition line 73 (after playerc_speech_recognition_putmsg() function) 3.2. client_libs/libplayerc/dev_vectormap about line 71 (after geosprint() function) (one more thing: this geosprint() function is declared inline, later the pointer to this inline is taken, what ta hell?!) (I'm sure there was more places with unexpected semicolons, I can't find it in my notes... or maybe it is my impression; fortunately, I'm doing fresh build from time to time and bugs are shwoing their faces then) 4. Missing 'unsigned': 4.1. utils/playerv/playerv.h about line 659: 'char *img_buffer;' should be 'unsigned char *img_buffer;' 4.2. rtk2/rtk_canvas.c about line 674, 'char * pixel;' should be 'unsigned char * pixel;' 4.3. server/drivers/mixed/nomad/Nclient.c: 'short' should be changed to 'unsinged short' in variables definitions about lines: 3613, 3630, 3668 5. Missing 'const': 5.1. server/drivers/position/ascension/flockofbirds.cc: 5.1.1. about line 98: constructor parameter 'char * port = FOB_DEFAULT_PORT' should be 'const char * port = FOB_DEFAULT_PORT'; 5.1.2. the same in line 135 where constructor body is implemented: 'char * port' should bd 'const char * port' 5.2. server/drivers/mixed/p2os/robot_params.h: all 'char *' in RobotParams_t shoult be 'const char *', strangely, erratic driver also have such a file and I see it has those pointers properly defined as const. I don't remember I'd ever changed this file, someone must had done the same previously, but why only to erratic files, leaving p2os buggy?! 6. Missing 'return': 6.1. server/drivers/planner/wavefront about line 524 should be 'return 0;' - the end of MainSetup() method (I guess Toby has fixed that already) 6.2. server/drivers/sonar/aitosonar.cc about line 283 should be 'return 0;' - the end of MainSetup() method 6.3. rtk2/rtk_menu.c about line 171 should be 'return 0;' - the end of rtk_menuitem_enable() function erratic.cc creates additional threads, is it safe? Cheers, Paul |
From: Toby C. <tco...@pl...> - 2009-01-25 22:09:41
|
always interesting trying to compile with a new compiler, hopefully we can get all this fixed in trunk over time, some comments below. Probably best for you to submit a patch rather than anyone else trying to reimplement the fixes. If there are any fixes that you are not as sure about try stick them in a second patch so we can apply the basic fixes quickly. Toby 2009/1/26 Paul Osmialowski <new...@ki...> > Hello Devels, > > As I announced in some post earlier, I'm opening new thread about my > struggles to compile Player 2.2 (SVN) on Solaris 10 using Sun compiler > from SunStudio 12 instead of gcc from csw development environment. So far > csw (which offer gcc 2.95.3) was proven to be suitable to compile Player. > Unfortunately, offered version of gcc is far too old so it is not possible > to compile easily anything more than Player + utils (most noticable is > Stage which needs huge amount of changes for succcesfull build). > > First step after installation of SunStudio 12 (both user and system wide > installations are suitable) is to install cmake 2.6.x (I used cmake > 2.6.2). It builds fine with suncc (csw itself offered cmake 2.4.8 which > was also suitable for Player). Next, libtool must be isntalled as I didn't > find any libltdl other than provided by csw (I used libtool 2.2). Other > critical libraries (glib2, gtk2, gnomecanvas) are provided by Solaris 10 > (Sun provides its own distribution of GNOME with all required libraries, > so there is a choice for the user between using GNOME and good old CDE - > ancient KDE; also csw offered its own GNOME distribution with libraries, I > was using it while compiling Player with csw; nevertheless, I sticked > with good old CDE). > > So far I didn't touch C++ client-side library, so I don't even know if it > causes boost-related problems. > They should compile fine without boost, not sure what you will need to do to get them to work with boost > > *LINKING* > The biggest problem I had was caused by linking issues that came from > inline functions. Do we really need them? For the purpose of my attempts, > I've removed all 'inline' directives, but someone more responsible for > Player will have to make a statement if inlines should be changed to > regular global functions. > inline is seldom needed these days as the compiler is smart enough to work it out itself in the optmisation stages. I am surprised that suncc doesnt like inlines, its a pretty standard attribute in my experience. What errors do you actually get here? > > *LINKING* > urglaser and rs4leuze couldn't be linked. The error was: > Undefined first referenced > symbol in file > void urglaser_Register(DriverTable*) > libplayerdrivers/libplayerdrivers.so.2.2.0 > void rs4leuze_Register(DriverTable*) > libplayerdrivers/libplayerdrivers.so.2.2.0 > ld: fatal: Symbol referencing errors. No output written to player > I don't know what happens, I've turned off both using ccmake. > I guess the register methods for these two drivers are written wrong, possibly they have the wrong case in the source file (this was changed with the autobuilt driver registry that geoff added with the cmake build system) > > *CMAKE* > One problem is caused by cmake which does not know that if function from > math.h is used, -lm linker flag must be added: affected place is > logsplitter utility which uses fabs() function. > > *CMAKE* > Other problem with dependencies that I guess cmake should solve is that > some functions from math library offered by Sun compiler aren't defined in > <math.h>, there is one more header file called <ieeefp.h> which should be > included if any of those functions must be used. Namely, it is finite() > function, (typically defined in math.h, but not in Sun's compiler), it is > used in server/drivers/localization/amcl/pf/pf_vector.c file. Other > mathematical functions used in this file are available in regular <math.h> > that it properly includes. > I guess, cmake should check if ieeefp.h is available and if so, > HAVE_IEEEFP (or something like that) should be defined, so pf_vector.c > could use this in #ifdefs to include one more required header. > > *COMPATIBILITY* > In many places __packed__ attribute is used. What for? It causes such a > warning: 'attribute packed is unsupported and will be skipped..' > This tells the compiler to pack a structure as much as possible (i.e. 4 chars into an int, instead of the default behaviour of word aligning them. This probably isnt actually needed since we moved to the XDR packing libraries, and may actually slow some systems down a little. Should do no harm to just #define packed to an empty string, or remove them > > Here are some easy to fix issues, for other bigger and more serious errors > I'll soon release a serie of patches. All problems were caused by > permissive nature of gcc compiler. gcc 4.3 has already picked up a lot of issues along these lines, always good to fix up these little quirks/bugs. > > > 1. Missing headers: > 1.1. client_libs/libplayerc/dev_ranger.c: stddef.h, stdlib.h > 1.2. server/drivers/mixed/nomad/Nclient.c: string.h (see section 4 below > for more problems with this file) > > 2. Unexpected comas: > 2.1. server/drivers/mixed/erratic/erratic.h about line 96, last line of > the typedef enum command > 2.2. server/drivers/map/mapcspace.cc about line 100, last line of > robot_shape_t enum > > 3. Unexpected semicolons: > 3.1. client_libs/libplayerc/dev_speech_recognition line 73 (after > playerc_speech_recognition_putmsg() function) > 3.2. client_libs/libplayerc/dev_vectormap about line 71 (after geosprint() > function) > (one more thing: this geosprint() function is declared inline, later > the pointer to this inline is taken, what ta hell?!) > > (I'm sure there was more places with unexpected semicolons, I can't find > it in my notes... or maybe it is my impression; fortunately, I'm doing > fresh build from time to time and bugs are shwoing their faces then) > > 4. Missing 'unsigned': > 4.1. utils/playerv/playerv.h about line 659: 'char *img_buffer;' should be > 'unsigned char *img_buffer;' > 4.2. rtk2/rtk_canvas.c about line 674, 'char * pixel;' should be 'unsigned > char * pixel;' > 4.3. server/drivers/mixed/nomad/Nclient.c: 'short' should be changed to > 'unsinged short' in variables definitions about lines: 3613, 3630, 3668 > > 5. Missing 'const': The const char* also gets picked up by 4.3 as a warning, so what you are seeing are the last few of many many const char * errors that were missed first few iterations. > > 5.1. server/drivers/position/ascension/flockofbirds.cc: > 5.1.1. about line 98: constructor parameter 'char * port = > FOB_DEFAULT_PORT' should be 'const char * port = FOB_DEFAULT_PORT'; > 5.1.2. the same in line 135 where constructor body is implemented: 'char * > port' should bd 'const char * port' > 5.2. server/drivers/mixed/p2os/robot_params.h: all 'char *' in > RobotParams_t shoult be 'const char *', strangely, erratic driver also > have such a file and I see it has those pointers properly defined as > const. I don't remember I'd ever changed this file, someone must had done > the same previously, but why only to erratic files, leaving p2os buggy?! > > 6. Missing 'return': > 6.1. server/drivers/planner/wavefront about line 524 should be 'return 0;' > - the end of MainSetup() method (I guess Toby has fixed that already) yip > > 6.2. server/drivers/sonar/aitosonar.cc about line 283 should be 'return > 0;' - the end of MainSetup() method > 6.3. rtk2/rtk_menu.c about line 171 should be 'return 0;' - the end of > rtk_menuitem_enable() function > > erratic.cc creates additional threads, is it safe? I think so, it uses the non threaded driver class as its base as it manages its own threads (at least that was how I read it last I looked). So worst case it is as safe as it was when it was first written. > > > Cheers, > Paul > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Paul O. <new...@ki...> - 2009-01-25 22:43:15
|
On Mon, 26 Jan 2009, Toby Collett wrote: > inline is seldom needed these days as the compiler is smart enough to work > it out itself in the optmisation stages. I am surprised that suncc doesnt > like inlines, its a pretty standard attribute in my experience. What errors > do you actually get here? > This is not compiler error, rather linker error like this: Undefined first referenced symbol in file sonar_sensor_prob libplayerdrivers/libplayerdrivers.so.2.2.0 laser_sensor_prob libplayerdrivers/libplayerdrivers.so.2.2.0 Looks like if some function is declared inline in one object file, it cannot be resolved in other object files that might use it. Definitly, inlines must go away. >> In many places __packed__ attribute is used. What for? It causes such a >> warning: 'attribute packed is unsupported and will be skipped..' >> > This tells the compiler to pack a structure as much as possible (i.e. 4 > chars into an int, instead of the default behaviour of word aligning them. > This probably isnt actually needed since we moved to the XDR packing > libraries, and may actually slow some systems down a little. Should do no > harm to just #define packed to an empty string, or remove them > I guess, thanks to XDR I can just ignore this warning, XDR serialization makes sure all data are transfered properly to/from remote system whatever it is on the other side of the wire. I'll back to the topic when I have some spare time again. Paul |
From: gbiggs <gb...@ki...> - 2009-01-25 23:39:59
|
Probably the Sun linker is not making inline functions available as symbols for other objects to link to. This doesn't mean all inlines must go away, just those that other files try to use. Geoff Paul Osmialowski wrote: > > On Mon, 26 Jan 2009, Toby Collett wrote: > >> inline is seldom needed these days as the compiler is smart enough to work >> it out itself in the optmisation stages. I am surprised that suncc doesnt >> like inlines, its a pretty standard attribute in my experience. What errors >> do you actually get here? >> > This is not compiler error, rather linker error like this: > Undefined first referenced > symbol in file > sonar_sensor_prob libplayerdrivers/libplayerdrivers.so.2.2.0 > laser_sensor_prob libplayerdrivers/libplayerdrivers.so.2.2.0 > > Looks like if some function is declared inline in one object file, it > cannot be resolved in other object files that might use it. Definitly, > inlines must go away. |
From: gbiggs <gb...@ki...> - 2009-01-27 01:12:25
|
Scattered entries for this path recently appeared in a few of the CMakeLists.txt files. I gather it's for OSX, but what specifically? If it's not vital for OSX (e.g. it's for a library installed from source rather than the usual method) it should be set in the PLAYER_EXTRA_INCLUDE_DIRS and PLAYER_EXTRA_LIB_DIRS advanced options. If it's vital for OSX (or other platforms), there are more portable ways to set it that I can add, if someone lets me know where it's necessary. Geoff |
From: Brian G. <br...@ge...> - 2009-01-27 01:16:29
|
On Jan 26, 2009, at 5:12 PM, gbiggs wrote: > Scattered entries for this path recently appeared in a few of the > CMakeLists.txt files. I gather it's for OSX, but what specifically? If > it's not vital for OSX (e.g. it's for a library installed from source > rather than the usual method) it should be set in the > PLAYER_EXTRA_INCLUDE_DIRS and PLAYER_EXTRA_LIB_DIRS advanced > options. If > it's vital for OSX (or other platforms), there are more portable > ways to > set it that I can add, if someone lets me know where it's necessary. On OS X, MacPorts installs things into /opt/local. But I would argue that a proper MacPorts installation has CPATH, LIBRARY_PATH, DYLD_LIBRARY_PATH, PKG_CONFIG_PATH, and friends modified to point into /opt/local, so that nobody need ever refer to it directly. brian. |
From: gbiggs <gb...@ki...> - 2009-01-27 03:10:04
|
If everyone on OS X will have to set it, then it's vital (at least until MacPorts and/or CMake sort themselves out). I'll add it to the scripts as a default path under OS X today. I don't have an OS X computer so I can't test it myself, though. Geoff Brian Gerkey wrote: > On Jan 26, 2009, at 5:12 PM, gbiggs wrote: > >> Scattered entries for this path recently appeared in a few of the >> CMakeLists.txt files. I gather it's for OSX, but what specifically? If >> it's not vital for OSX (e.g. it's for a library installed from source >> rather than the usual method) it should be set in the >> PLAYER_EXTRA_INCLUDE_DIRS and PLAYER_EXTRA_LIB_DIRS advanced >> options. If >> it's vital for OSX (or other platforms), there are more portable >> ways to >> set it that I can add, if someone lets me know where it's necessary. > > On OS X, MacPorts installs things into /opt/local. But I would argue > that a proper MacPorts installation has CPATH, LIBRARY_PATH, > DYLD_LIBRARY_PATH, PKG_CONFIG_PATH, and friends modified to point > into /opt/local, so that nobody need ever refer to it directly. > > brian. |
From: Brian G. <br...@ge...> - 2009-01-27 03:11:50
|
On Jan 26, 2009, at 5:32 PM, gbiggs wrote: > If everyone on OS X will have to set it, then it's vital (at least > until > MacPorts and/or CMake sort themselves out). I'll add it to the scripts > as a default path under OS X today. I don't have an OS X computer so I > can't test it myself, though. Oh, I was suggesting that it's out of scope for our build system, and rather that we should be assuming that the user has already set those variables accordingly. brian. > Brian Gerkey wrote: >> On Jan 26, 2009, at 5:12 PM, gbiggs wrote: >> >>> Scattered entries for this path recently appeared in a few of the >>> CMakeLists.txt files. I gather it's for OSX, but what >>> specifically? If >>> it's not vital for OSX (e.g. it's for a library installed from >>> source >>> rather than the usual method) it should be set in the >>> PLAYER_EXTRA_INCLUDE_DIRS and PLAYER_EXTRA_LIB_DIRS advanced >>> options. If >>> it's vital for OSX (or other platforms), there are more portable >>> ways to >>> set it that I can add, if someone lets me know where it's necessary. >> >> On OS X, MacPorts installs things into /opt/local. But I would argue >> that a proper MacPorts installation has CPATH, LIBRARY_PATH, >> DYLD_LIBRARY_PATH, PKG_CONFIG_PATH, and friends modified to point >> into /opt/local, so that nobody need ever refer to it directly. >> >> brian. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: gbiggs <gb...@ki...> - 2009-01-27 03:45:43
|
OK then. Saves me some work. :) The user can either set them system-wide, or they can use the PLAYER_EXTRA_* variables to specify them. Geoff Brian Gerkey wrote: > On Jan 26, 2009, at 5:32 PM, gbiggs wrote: > >> If everyone on OS X will have to set it, then it's vital (at least >> until >> MacPorts and/or CMake sort themselves out). I'll add it to the scripts >> as a default path under OS X today. I don't have an OS X computer so I >> can't test it myself, though. > > Oh, I was suggesting that it's out of scope for our build system, and > rather that we should be assuming that the user has already set those > variables accordingly. > > brian. > >> Brian Gerkey wrote: >>> On Jan 26, 2009, at 5:12 PM, gbiggs wrote: >>> >>>> Scattered entries for this path recently appeared in a few of the >>>> CMakeLists.txt files. I gather it's for OSX, but what >>>> specifically? If >>>> it's not vital for OSX (e.g. it's for a library installed from >>>> source >>>> rather than the usual method) it should be set in the >>>> PLAYER_EXTRA_INCLUDE_DIRS and PLAYER_EXTRA_LIB_DIRS advanced >>>> options. If >>>> it's vital for OSX (or other platforms), there are more portable >>>> ways to >>>> set it that I can add, if someone lets me know where it's necessary. >>> On OS X, MacPorts installs things into /opt/local. But I would argue >>> that a proper MacPorts installation has CPATH, LIBRARY_PATH, >>> DYLD_LIBRARY_PATH, PKG_CONFIG_PATH, and friends modified to point >>> into /opt/local, so that nobody need ever refer to it directly. |
From: gbiggs <gb...@ki...> - 2009-01-27 03:11:07
|
By now, most of us probably don't have to think about the answer when someone asks if Player will work on Windows. Unfortunately, we're all going to have to do some retraining. I've just checked in a large change set that adds native Windows support to Player: http://killbots.net/images/player_win32.jpg This work is not yet complete, but it has a functional server and the C client libraries. A large number of drivers also compile, although I haven't tested them. See below for the complete list. There is a todo list in the root source directory, which should give an idea of what works and what doesn't outside of the drivers. So far I have tested this using Visual Studio 2005 under Windows Vista x64 and Visual Studio 2008 under Windows XP x64. There are copious warnings thanks to MS's desire to deprecate standard library functions in favour of their own more secure versions, but they can be ignored. Some of the changes made may have a flow-on effect causing issues on other platforms. I don't expect there will be many, but just in case, keep an eye out and let me know if any problems crop up. I was going to write a wiki page detailing how to build and use Player under Windows, but the wiki is currently broken. So I'll write it in an email to this list soon and put it in the wiki later. Geoff This is the list of drivers that do and don't build. Those drivers that look for stuff using pkg-config may well build (I know of a couple that definitely will) once pkg-config and the necessary packages are installed. -- ===== Drivers ===== -- The following drivers will be built: -- localbb -- cmvision -- laserbar -- laserbarcode -- XSensMT -- bumper2laser -- sicks3000 -- laserposeinterpolator -- lasercspace -- laserrescan -- lasercutter -- sickLDMRS -- amcl -- fakelocalize -- mapcspace -- vmapfile -- laserptzcloud -- bumpersafe -- lasersafe -- mbicp -- motionmind -- sicknav200 -- nd -- vfh -- lasertoranger -- sonartoranger -- rangertolaser -- dummy -- kartowriter -- writelog -- readlog -- passthrough -- relay -- AioToSonar -- accel_calib -- -- The following drivers will not be built: -- amtecm5 - Cannot build on this operating system. -- alsa - Cannot build on this operating system. -- acts - Cannot build on this operating system. -- artoolkitplus - Could not find pkg-config -- shapetracker - Could not find pkg-config -- simpleshape - Could not find pkg-config -- upcbarcode - Could not find pkg-config -- camerav4l - Cannot build on this operating system. -- camera1394 - Cannot build on this operating system. -- cameracompress - playerjpeg is not available. -- camerauncompress - playerjpeg is not available. -- cvcam - Could not find pkg-config -- imageseq - Could not find pkg-config -- sphere - Cannot build on this operating system. -- camerauvc - Cannot build on this operating system. -- yarpimage - Could not find header yarp/os/all.h -- unicapimage - Could not find header unicap.h -- laservisualbarcode - Has not been updated to use dynamic message structures -- laservisualbw - Has not been updated to use dynamic message structures -- garminnmea - Cannot build on this operating system. -- statgrab - Could not find pkg-config -- nimu - Could not find header usb.h -- linuxjoystick - Cannot build on this operating system. -- pbslaser - Cannot build on this operating system. -- sicklms400 - Cannot build on this operating system. -- urglaser - Cannot build on this operating system. -- rs4leuze - Cannot build on this operating system. -- eedhcontroller - Disabled - probably doesn't build -- mapfile - Could not find pkg-config -- mapscale - Could not find pkg-config -- lifomcom - Disabled by default -- obot - Cannot build on this operating system. -- chatterbox - Experimental -- clodbuster - Cannot build on this operating system. -- cmucam2 - Cannot build on this operating system. -- erratic - Cannot build on this operating system. -- er1 - Cannot build on this operating system. -- garcia - Could not find pkg-config -- create - Cannot build on this operating system. -- roomba - Cannot build on this operating system. -- khepera - Cannot build on this operating system. -- mricp - Could not find pkg-config -- nomad - Cannot build on this operating system. -- p2os - Cannot build on this operating system. -- phidgetifk - Could not find header phidget21.h -- reb - Disabled by default -- segwayrmp - Disabled by default -- rflex - Cannot build on this operating system. -- robotino - Could not find header robotinocom.h -- sr3000 - Could not find header libusbSR.h -- wbr914 - Cannot build on this operating system. -- flexiport - Could not find pkg-config -- serialstream - Cannot build on this operating system. -- tcpstream - Cannot build on this operating system. -- wavefront - Could not find pkg-config -- flockofbirds - Cannot build on this operating system. -- isense - Could not find header isense/isense.h -- microstrain - Cannot build on this operating system. -- roboteq - Cannot build on this operating system. -- amtecpowercube - Cannot build on this operating system. -- canonvcc4 - Cannot build on this operating system. -- ptu46 - Cannot build on this operating system. -- sonyevid30 - Cannot build on this operating system. -- gbxsickacfr - Could not find pkg-config -- hokuyo_aist - Could not find pkg-config -- insideM300 - Cannot build on this operating system. -- sickRFI341 - Cannot build on this operating system. -- skyetekM1 - Cannot build on this operating system. -- phidgetRFID - Could not find header phidget21.h -- acr120u - Could not find header usb.h -- service_adv_mdns - Disabled by default -- sphinx2 - Disabled by default -- festival - Cannot build on this operating system. -- stoc - Could not find header SVS/svsclass.h -- postgis - Could not find header geos_c.h -- vec2map - Could not find header geos_c.h -- aodv - Cannot build on this operating system. -- iwspy - Cannot build on this operating system. -- linuxwifi - Cannot build on this operating system. -- mica2 - Cannot build on this operating system. -- rcore_xbridge - Could not find header libparticle.h -- phidgetAcc - Could not find header phidget21.h -- =================== |
From: gbiggs <gb...@ki...> - 2009-01-27 03:49:06
|
How to compile and use Player on Windows ======================================== Compiling Player for Windows has been tested with the following compilers and operating systems: - Visual Studio 2005, Windows Vista x64 - Visual Studio 2008, Windows XP x64 Since I've only used Visual Studio, that's what these instructions will focus on. Things you will need: - CMake (http://cmake.org/). Download the latest Win32 installer and run it. - pthreads for Win32 (http://sourceware.org/pthreads-win32/index.html). Download the latest version of the DLLs, lib files and include files (ftp://sourceware.org/pub/pthreads-win32/dll-latest/). Place these somewhere handy (e.g. c:\pthreads\lib and c:\pthreads\include). Add the lib directory to your system's PATH environment variable. You can do this through the System Properties control panel, Advanced tab, "Environment variables..." button. Separate multiple paths with a semi-colon. Things you may want: - pkg-config (not vital, but needed for many drivers). Compiling and Installing Player ------------------------------- Summary of steps to compile and install Player 1. Download the source. 2. Configure Player using CMake. 3. Poke it until it finds pthreads. 4. Compile Player using your compiler. 5. Install Player. 6. Set up environment variables. 1. Check out the source from the subversion repository. Tortoise SVN (http://tortoisesvn.net/) is probably the best subversion client available for Windows. See the Player Project wiki for details on how to get the latest source code. Where you put the source doesn't matter much. Create a subdirectory of the root source directory called "build". 2. Run the CMake graphical configuration tool (it should be in the Start Menu). Point it at the source directory for the source code, and the build/ subdirectory for the binaries. Click "Configure". 3. On the first run, CMake will probably be unable to locate the file "pthread.h". On Windows, the path to the pthreads include files and libraries currently needs to be set manually. Switch CMake to advanced mode and set the values of PTHREAD_INCLUDE_DIR and PTHREAD_LIB_DIR accordingly. You will also need to choose a version of the pthreads library to use. pthreads for Win32 includes several versions compiled using different compilers and different options (the FAQ on the website gives details). Enter the name of your chosen version in the value of PTHREAD_LIB (the default value is the recommended option for Visual Studio users). Unfortunately, CMake will not perform the test for the header again (I'm not completely sure why, it looks like it's a bug in the module that does the search). You will need to open the file build/CMakeCache.txt and delete two lines. They will look something like this: //Have include HAVE_PTHREAD_H HAVE_PTHREAD_H:INTERNAL= After saving that file, click "Configure" again and CMake should complete successfully this time. Click "OK" to generate the project/make files for your chosen compiler. 4. In the build/ directory will be a file called "Player.sln". This is the solution file for Player. Open it using Visual C++. To compile, all you have to do is build the "ALL_BUILD" project. Don't just tell Visual C++ to build the startup project, as CMake seems to assign this randomly and you may end up running the uninstall script or something equally annoying. If the build scripts have changed, building any project in Visual C++ will automatically re-run CMake. 5. To install Player using Visual Studio, build the "INSTALL" project. This will recompile anything that is out of date (including re-running CMake if the build scripts have changed). Player will be installed in the directory specified in the CMAKE_INSTALL_PREFIX variable during configuration. The layout under this directory will be similar to that seen on a Unix-like system. 6. Before you can execute Player, you must set up your environment variables correctly. Open the control panel and go to the system settings, or alternatively, right click on "My Computer" and select "Properties" (on Vista, you will need to click "Advanced System Settings" on the left after this). Switch to the "Advanced" tab and click "Environment Variables...". Edit the PATH variable and append to it the Player binary and library directories. Separate multiple paths with a semi-colon. For example, using the default install path, you would append this: C:\Program Files (x86)\Player\bin;C:\Program Files (x86)\Player\lib Any open command prompts will need to be re-opened to get the updated value. You will need to log out of Windows and log back in to update it everywhere else. If this process has been successful, you should be able to open a command prompt (Start Menu->Run...->cmd) and type "player" to start the server. Obviously, to do anything useful you should provide a configuration file as a command line option. Any other command line options are not currently supported. Debugging the server and clients -------------------------------- The Player server can be debugged using Visual Studio's debugger and the CMake-generated solution. First, you need to set some paths in Visual Studio so it can find the various DLL files to launch the server. For Visual Studio 2005 and 2008, you need to open the Options panel from the Tools menu. Open the "Projects and Solutions" branch, and choose "VC++ Directories". You need to add the DLL locations under both "Binary files" and "Library files". To avoid needing to run the INSTALL step every time you change something while debugging, add the DLL locations in the build/ directory. There are four necessary locations: build/libplayercore/debug, build/libplayertcp/debug, build/libplayerxdr/debug and build/server/libplayerdrivers/debug. Add all four to both "Binary files" and "Library files". Debugging will then function as normal in Visual Studio. For debugging clients, you only need to add the location of the installed libraries (for example, C:\Program Files (x86)\Player\lib). If you have set the directories for debugging the server, this is not necessary, but you will need to add the directory "build/client_libs/libplayerc/debug". Building clients ---------------- The CMake modules for configuring clients are, at this time, somewhat not working on Windows. Instead, here's a handy CMakeLists.txt that will work with the default install location: CMAKE_MINIMUM_REQUIRED (VERSION 2.4.7 FATAL_ERROR) INCLUDE_DIRECTORIES ("C:/Program Files (x86)/Player/include/player-2.2") LINK_DIRECTORIES ("C:/Program Files (x86)/Player/lib") ADD_EXECUTABLE (test test.c) TARGET_LINK_LIBRARIES (test playerc) Alternatively, use the build system of your choice, or just create a project manually in Visual Studio and add the include directory as appropriate. |
From: Radu B. R. <ru...@cs...> - 2009-01-27 04:23:38
|
Geoff, even though I might not use it at all (then again, who knows? :) ), a big THANKS for the amazing work you've put into this. Great stuff! Cheers, Radu. gbiggs wrote: > How to compile and use Player on Windows > ======================================== > > Compiling Player for Windows has been tested with the following > compilers and operating systems: > - Visual Studio 2005, Windows Vista x64 > - Visual Studio 2008, Windows XP x64 > > Since I've only used Visual Studio, that's what these instructions will > focus on. > > Things you will need: > - CMake (http://cmake.org/). Download the latest Win32 installer and run it. > - pthreads for Win32 (http://sourceware.org/pthreads-win32/index.html). > Download the latest version of the DLLs, lib files and include files > (ftp://sourceware.org/pub/pthreads-win32/dll-latest/). Place these > somewhere handy (e.g. c:\pthreads\lib and c:\pthreads\include). Add the > lib directory to your system's PATH environment variable. You can do > this through the System Properties control panel, Advanced tab, > "Environment variables..." button. Separate multiple paths with a > semi-colon. > > Things you may want: > - pkg-config (not vital, but needed for many drivers). > > Compiling and Installing Player > ------------------------------- > > Summary of steps to compile and install Player > 1. Download the source. > 2. Configure Player using CMake. > 3. Poke it until it finds pthreads. > 4. Compile Player using your compiler. > 5. Install Player. > 6. Set up environment variables. > > 1. Check out the source from the subversion repository. Tortoise SVN > (http://tortoisesvn.net/) is probably the best subversion client > available for Windows. See the Player Project wiki for details on how to > get the latest source code. Where you put the source doesn't matter > much. Create a subdirectory of the root source directory called "build". > > 2. Run the CMake graphical configuration tool (it should be in the Start > Menu). Point it at the source directory for the source code, and the > build/ subdirectory for the binaries. Click "Configure". > > 3. On the first run, CMake will probably be unable to locate the file > "pthread.h". On Windows, the path to the pthreads include files and > libraries currently needs to be set manually. Switch CMake to advanced > mode and set the values of PTHREAD_INCLUDE_DIR and PTHREAD_LIB_DIR > accordingly. You will also need to choose a version of the pthreads > library to use. pthreads for Win32 includes several versions compiled > using different compilers and different options (the FAQ on the website > gives details). Enter the name of your chosen version in the value of > PTHREAD_LIB (the default value is the recommended option for Visual > Studio users). Unfortunately, CMake will not perform the test for the > header again (I'm not completely sure why, it looks like it's a bug in > the module that does the search). You will need to open the file > build/CMakeCache.txt and delete two lines. They will look something like > this: > > //Have include HAVE_PTHREAD_H > HAVE_PTHREAD_H:INTERNAL= > > After saving that file, click "Configure" again and CMake should > complete successfully this time. Click "OK" to generate the project/make > files for your chosen compiler. > > 4. In the build/ directory will be a file called "Player.sln". This is > the solution file for Player. Open it using Visual C++. To compile, all > you have to do is build the "ALL_BUILD" project. Don't just tell Visual > C++ to build the startup project, as CMake seems to assign this randomly > and you may end up running the uninstall script or something equally > annoying. If the build scripts have changed, building any project in > Visual C++ will automatically re-run CMake. > > 5. To install Player using Visual Studio, build the "INSTALL" project. > This will recompile anything that is out of date (including re-running > CMake if the build scripts have changed). Player will be installed in > the directory specified in the CMAKE_INSTALL_PREFIX variable during > configuration. The layout under this directory will be similar to that > seen on a Unix-like system. > > 6. Before you can execute Player, you must set up your environment > variables correctly. Open the control panel and go to the system > settings, or alternatively, right click on "My Computer" and select > "Properties" (on Vista, you will need to click "Advanced System > Settings" on the left after this). Switch to the "Advanced" tab and > click "Environment Variables...". Edit the PATH variable and append to > it the Player binary and library directories. Separate multiple paths > with a semi-colon. For example, using the default install path, you > would append this: > > C:\Program Files (x86)\Player\bin;C:\Program Files (x86)\Player\lib > > Any open command prompts will need to be re-opened to get the updated > value. You will need to log out of Windows and log back in to update it > everywhere else. > > > If this process has been successful, you should be able to open a > command prompt (Start Menu->Run...->cmd) and type "player" to start the > server. Obviously, to do anything useful you should provide a > configuration file as a command line option. Any other command line > options are not currently supported. > > > Debugging the server and clients > -------------------------------- > > The Player server can be debugged using Visual Studio's debugger and the > CMake-generated solution. First, you need to set some paths in Visual > Studio so it can find the various DLL files to launch the server. For > Visual Studio 2005 and 2008, you need to open the Options panel from the > Tools menu. Open the "Projects and Solutions" branch, and choose "VC++ > Directories". You need to add the DLL locations under both "Binary > files" and "Library files". To avoid needing to run the INSTALL step > every time you change something while debugging, add the DLL locations > in the build/ directory. There are four necessary locations: > build/libplayercore/debug, build/libplayertcp/debug, > build/libplayerxdr/debug and build/server/libplayerdrivers/debug. Add > all four to both "Binary files" and "Library files". Debugging will then > function as normal in Visual Studio. > > For debugging clients, you only need to add the location of the > installed libraries (for example, C:\Program Files (x86)\Player\lib). If > you have set the directories for debugging the server, this is not > necessary, but you will need to add the directory > "build/client_libs/libplayerc/debug". > > > Building clients > ---------------- > > The CMake modules for configuring clients are, at this time, somewhat > not working on Windows. Instead, here's a handy CMakeLists.txt that will > work with the default install location: > > CMAKE_MINIMUM_REQUIRED (VERSION 2.4.7 FATAL_ERROR) > > INCLUDE_DIRECTORIES ("C:/Program Files (x86)/Player/include/player-2.2") > LINK_DIRECTORIES ("C:/Program Files (x86)/Player/lib") > ADD_EXECUTABLE (test test.c) > TARGET_LINK_LIBRARIES (test playerc) > > Alternatively, use the build system of your choice, or just create a > project manually in Visual Studio and add the include directory as > appropriate. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers -- | Radu Bogdan Rusu | http://rbrusu.com/ |
From: gbiggs <gb...@ki...> - 2009-02-10 00:49:48
|
This information is now available in the wiki: http://playerstage.sourceforge.net/wiki/index.php/Windows Geoff gbiggs wrote: > How to compile and use Player on Windows > ======================================== > > Compiling Player for Windows has been tested with the following > compilers and operating systems: > - Visual Studio 2005, Windows Vista x64 > - Visual Studio 2008, Windows XP x64 > > Since I've only used Visual Studio, that's what these instructions will > focus on. > > Things you will need: > - CMake (http://cmake.org/). Download the latest Win32 installer and run it. > - pthreads for Win32 (http://sourceware.org/pthreads-win32/index.html). > Download the latest version of the DLLs, lib files and include files > (ftp://sourceware.org/pub/pthreads-win32/dll-latest/). Place these > somewhere handy (e.g. c:\pthreads\lib and c:\pthreads\include). Add the > lib directory to your system's PATH environment variable. You can do > this through the System Properties control panel, Advanced tab, > "Environment variables..." button. Separate multiple paths with a > semi-colon. > > Things you may want: > - pkg-config (not vital, but needed for many drivers). > > Compiling and Installing Player > ------------------------------- > > Summary of steps to compile and install Player > 1. Download the source. > 2. Configure Player using CMake. > 3. Poke it until it finds pthreads. > 4. Compile Player using your compiler. > 5. Install Player. > 6. Set up environment variables. > > 1. Check out the source from the subversion repository. Tortoise SVN > (http://tortoisesvn.net/) is probably the best subversion client > available for Windows. See the Player Project wiki for details on how to > get the latest source code. Where you put the source doesn't matter > much. Create a subdirectory of the root source directory called "build". > > 2. Run the CMake graphical configuration tool (it should be in the Start > Menu). Point it at the source directory for the source code, and the > build/ subdirectory for the binaries. Click "Configure". > > 3. On the first run, CMake will probably be unable to locate the file > "pthread.h". On Windows, the path to the pthreads include files and > libraries currently needs to be set manually. Switch CMake to advanced > mode and set the values of PTHREAD_INCLUDE_DIR and PTHREAD_LIB_DIR > accordingly. You will also need to choose a version of the pthreads > library to use. pthreads for Win32 includes several versions compiled > using different compilers and different options (the FAQ on the website > gives details). Enter the name of your chosen version in the value of > PTHREAD_LIB (the default value is the recommended option for Visual > Studio users). Unfortunately, CMake will not perform the test for the > header again (I'm not completely sure why, it looks like it's a bug in > the module that does the search). You will need to open the file > build/CMakeCache.txt and delete two lines. They will look something like > this: > > //Have include HAVE_PTHREAD_H > HAVE_PTHREAD_H:INTERNAL= > > After saving that file, click "Configure" again and CMake should > complete successfully this time. Click "OK" to generate the project/make > files for your chosen compiler. > > 4. In the build/ directory will be a file called "Player.sln". This is > the solution file for Player. Open it using Visual C++. To compile, all > you have to do is build the "ALL_BUILD" project. Don't just tell Visual > C++ to build the startup project, as CMake seems to assign this randomly > and you may end up running the uninstall script or something equally > annoying. If the build scripts have changed, building any project in > Visual C++ will automatically re-run CMake. > > 5. To install Player using Visual Studio, build the "INSTALL" project. > This will recompile anything that is out of date (including re-running > CMake if the build scripts have changed). Player will be installed in > the directory specified in the CMAKE_INSTALL_PREFIX variable during > configuration. The layout under this directory will be similar to that > seen on a Unix-like system. > > 6. Before you can execute Player, you must set up your environment > variables correctly. Open the control panel and go to the system > settings, or alternatively, right click on "My Computer" and select > "Properties" (on Vista, you will need to click "Advanced System > Settings" on the left after this). Switch to the "Advanced" tab and > click "Environment Variables...". Edit the PATH variable and append to > it the Player binary and library directories. Separate multiple paths > with a semi-colon. For example, using the default install path, you > would append this: > > C:\Program Files (x86)\Player\bin;C:\Program Files (x86)\Player\lib > > Any open command prompts will need to be re-opened to get the updated > value. You will need to log out of Windows and log back in to update it > everywhere else. > > > If this process has been successful, you should be able to open a > command prompt (Start Menu->Run...->cmd) and type "player" to start the > server. Obviously, to do anything useful you should provide a > configuration file as a command line option. Any other command line > options are not currently supported. > > > Debugging the server and clients > -------------------------------- > > The Player server can be debugged using Visual Studio's debugger and the > CMake-generated solution. First, you need to set some paths in Visual > Studio so it can find the various DLL files to launch the server. For > Visual Studio 2005 and 2008, you need to open the Options panel from the > Tools menu. Open the "Projects and Solutions" branch, and choose "VC++ > Directories". You need to add the DLL locations under both "Binary > files" and "Library files". To avoid needing to run the INSTALL step > every time you change something while debugging, add the DLL locations > in the build/ directory. There are four necessary locations: > build/libplayercore/debug, build/libplayertcp/debug, > build/libplayerxdr/debug and build/server/libplayerdrivers/debug. Add > all four to both "Binary files" and "Library files". Debugging will then > function as normal in Visual Studio. > > For debugging clients, you only need to add the location of the > installed libraries (for example, C:\Program Files (x86)\Player\lib). If > you have set the directories for debugging the server, this is not > necessary, but you will need to add the directory > "build/client_libs/libplayerc/debug". > > > Building clients > ---------------- > > The CMake modules for configuring clients are, at this time, somewhat > not working on Windows. Instead, here's a handy CMakeLists.txt that will > work with the default install location: > > CMAKE_MINIMUM_REQUIRED (VERSION 2.4.7 FATAL_ERROR) > > INCLUDE_DIRECTORIES ("C:/Program Files (x86)/Player/include/player-2.2") > LINK_DIRECTORIES ("C:/Program Files (x86)/Player/lib") > ADD_EXECUTABLE (test test.c) > TARGET_LINK_LIBRARIES (test playerc) > > Alternatively, use the build system of your choice, or just create a > project manually in Visual Studio and add the include directory as > appropriate. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: gbiggs <gb...@ki...> - 2009-02-18 03:56:38
|
A quick update on progress with the Win32 build: The C++ client library now compiles. I haven't tested it, and there's a potential issue with DLL linking corrupting some data (at least with VC++ 2005) that I haven't investigated yet, but it will probably work. Some utilities compile. Mainly the simple ones like playerprint and playerprop. Command line argument passing works now. Geoff gbiggs wrote: > By now, most of us probably don't have to think about the answer when > someone asks if Player will work on Windows. Unfortunately, we're all > going to have to do some retraining. I've just checked in a large change > set that adds native Windows support to Player: > > http://killbots.net/images/player_win32.jpg > > This work is not yet complete, but it has a functional server and the C > client libraries. A large number of drivers also compile, although I > haven't tested them. See below for the complete list. There is a todo > list in the root source directory, which should give an idea of what > works and what doesn't outside of the drivers. > > So far I have tested this using Visual Studio 2005 under Windows Vista > x64 and Visual Studio 2008 under Windows XP x64. There are copious > warnings thanks to MS's desire to deprecate standard library functions > in favour of their own more secure versions, but they can be ignored. > > Some of the changes made may have a flow-on effect causing issues on > other platforms. I don't expect there will be many, but just in case, > keep an eye out and let me know if any problems crop up. > > I was going to write a wiki page detailing how to build and use Player > under Windows, but the wiki is currently broken. So I'll write it in an > email to this list soon and put it in the wiki later. > > Geoff |
From: Paul O. <new...@ki...> - 2009-01-28 15:51:47
|
On Mon, 26 Jan 2009, Toby Collett wrote: >> >> So far I didn't touch C++ client-side library, so I don't even know if it >> causes boost-related problems. >> > They should compile fine without boost, not sure what you will need to do to > get them to work with boost > I've tried to compile c++ client-side library, unfortunately compilation ends with an error: player-20090128/client_libs/libplayerc++/playerc++.h", line 1841: Error: Unexpected type name "player_pose2d_t" encountered. player-20090128/client_libs/libplayerc++/playerc++.h", line 2009: Error: Unexpected type name "player_pose3d_t" encountered. Also I had to change SearchForStuff.cmake file a bit, as nanosleep() presence was discovered in wrong place so it couln't be found. Patch will be released soon (on a tracker). Paul |
From: Paul O. <new...@ki...> - 2009-02-11 19:55:04
|
Hello Geoff, I've found 5 minutes to see how todays player snapshot behaves on Solaris 10 compiled using suncc from SunStudio12. It is much better, however, not everything is working as it should: 1. cmake/internal/SearchForStuff.cmake - solution for nanosleep issue seem to be OK, except that it should be PLAYER_OS_SOLARIS (as everywhere else in this file) not PLAYER_OS_SUN; after this change nanosleep() is found on both csw and SunStudio. 2. server/drivers/mixed/p2os/robot_params.h, this structure has char * fields initialised with troublemaking string literals, so the pointer type should be const char *. Previously the same issue was corrected by someone else in erratics robot_params.h, so why can't it be done the same with p2os? 3. server/drivers/mixed/rflex/rflex.cc the joy_control static property of RFLEX class cannot be declared extern. I guess only SunCC complains about it, so cmake should disable this driver if detected compiler is SunCC. To be honest, I can't find where this variable is instanced if it is extern here! or.... let's do it like that: #ifdef __SUNPRO_CC int RFLEX::joy_control; #else extern int RFLEX::joy_control; #endif 4. skyetekM1.cc still complains about tid[LEN], also still this code is unsafe in case len is less than or equal 0. 5. separate camerav4l and upcbarcode patches aren't applied so still they can't be built Cheers, Paul On Wed, 28 Jan 2009, Paul Osmialowski wrote: > > > On Mon, 26 Jan 2009, Toby Collett wrote: > >>> >>> So far I didn't touch C++ client-side library, so I don't even know if it >>> causes boost-related problems. >>> >> They should compile fine without boost, not sure what you will need to do to >> get them to work with boost >> > I've tried to compile c++ client-side library, unfortunately compilation > ends with an error: > player-20090128/client_libs/libplayerc++/playerc++.h", line 1841: Error: > Unexpected type name "player_pose2d_t" encountered. > player-20090128/client_libs/libplayerc++/playerc++.h", line 2009: Error: > Unexpected type name "player_pose3d_t" encountered. > > Also I had to change SearchForStuff.cmake file a bit, as nanosleep() > presence was discovered in wrong place so it couln't be found. Patch will > be released soon (on a tracker). > > Paul > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: gbiggs <gb...@ki...> - 2009-02-17 01:00:18
|
Paul Osmialowski wrote: > 2. server/drivers/mixed/p2os/robot_params.h, this structure has char * > fields initialised with troublemaking string literals, so the pointer type > should be const char *. Previously the same issue was corrected by someone > else in erratics robot_params.h, so why can't it be done the same with > p2os? This file is generated. The files that actually need to be fixed are the tcl files in server/codetools/saphconv/. > 3. server/drivers/mixed/rflex/rflex.cc the joy_control static > property of RFLEX class cannot be declared extern. I guess only SunCC > complains about it, so cmake should disable this driver if detected > compiler is SunCC. To be honest, I can't find where this variable is > instanced if it is extern here! > or.... let's do it like that: > > #ifdef __SUNPRO_CC > int RFLEX::joy_control; > #else > extern int RFLEX::joy_control; > #endif Looking at what the code does with this variable, I don't think taking away the extern will leave the driver in a fully-functional state. I've disabled it for solaris instead. Geoff |
From: Paul O. <new...@ki...> - 2009-02-17 17:58:05
|
Hi Geoff, I've obtained todays trunk snapshot to see how things work with sunCC. It is much better now, however, there are four things to consider: 1. This has nothing in common with Solaris nor SunCC, but today looking at playerconfig.h I noticed that all things that are defined looks like: #define HAVE_FOO 1 except one: HAVE_XDR, which looks: #define HAVE_XDR (no '1' at the end) why this one should differ? 2. recently applied upcbarcode fix causes new error: [ 34%] Building CXX object server/libplayerdrivers/CMakeFiles/playerdrivers.dir/__/drivers/blobfinder/upcbarcode/upcbarcode.o "/home/guest/psg22/src/player-20090217/server/drivers/blobfinder/upcbarcode/upcbarcode.cc", line 255: Error: In this declaration "symbols" is of an incomplete type "int[][2]". "/home/guest/psg22/src/player-20090217/server/drivers/blobfinder/upcbarcode/upcbarcode.cc", line 257: Error: The operand "*symbols" cannot be assigned to. 2 Error(s) detected. *** Error code 2 My proposal was and still is to fix it like this: --- upcbarcode.cc.old Tu feb 17 12:37:15 2009 +++ upcbarcode.cc Tu feb 17 13:29:04 2009 @@ -252,7 +252,7 @@ width = this->stored_data.width; height = this->stored_data.height; - int symbols[][2]; + int (* symbols)[2]; if ((symbols = new int[height][2]) == NULL) { The "int (* symbols)[2];" declaration was taken from some old C++ book and seem to be still valid. 3. HAVE_IEEEFP_H definition is set properly (at least on Solaris with SunStudio), however the way it is used in server/drivers/localization/amcl/pf/pf_vector.c looks strange for me: #elif defined (sun) && defined (HAVE_IEEEFP_H) #include <ieeefp.h> #endif Are you sure that this header comes with Solaris only? I don't know every OS in the world, but first answer from google says it is present at least in Symbian: http://www.symbian.com/developer/techlib/v70sdocs/doc%5Fsource/reference/cpp/libc/ieeefp%5Fh (and the finite() function used in pf_vector.c is defined there). I guess, "#if defined (HAVE_IEEEFP_H)" would be enough, since whenever the <ieeefp.h> is present, it should be included here. (I'm curious, why are we using "#if defined (HAVE_FOO)"? Is good old "#ifdef" not enough?). 4. Still C++ client library cannot be compiled due to an error (however, currently I'm not making any kind of use of it, so I can live without it): Scanning dependencies of target playerc++ [ 18%] Building CXX object client_libs/libplayerc++/CMakeFiles/playerc++.dir/playerc++.o "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1841: Error: Unexpected type name "player_pose2d_t" encountered. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1841: Error: ")" expected instead of "{". "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1841: Error: Use ";" to terminate statements. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1841: Error: Use ";" to terminate statements. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1841: Error: Unexpected ")" -- Check for matching parenthesis. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1841: Error: Operand expected instead of ";". "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1846: Error: Unexpected type name "player_pose2d_t" encountered. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1846: Error: ")" expected instead of "{". "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1846: Error: Use ";" to terminate statements. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1846: Error: Use ";" to terminate statements. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1846: Error: "}" expected instead of ",". "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1846: Error: Use ";" to terminate statements. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1846: Error: Unexpected ")" -- Check for matching parenthesis. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 1846: Error: Operand expected instead of ";". "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2009: Error: Unexpected type name "player_pose3d_t" encountered. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2009: Error: ")" expected instead of "{". "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2009: Error: Use ";" to terminate statements. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2009: Error: Use ";" to terminate statements. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2009: Error: Unexpected ")" -- Check for matching parenthesis. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2009: Error: Operand expected instead of ";". "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2016: Error: Unexpected type name "player_pose3d_t" encountered. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2016: Error: ")" expected instead of "{". "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2016: Error: Use ";" to terminate statements. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2016: Error: Use ";" to terminate statements. "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/playerc++.h", line 2016: Error: "}" expected instead of ",". Compilation aborted, too many Error messages. *** Error code 1 Paul On Tue, 17 Feb 2009, gbiggs wrote: > Paul Osmialowski wrote: >> 2. server/drivers/mixed/p2os/robot_params.h, this structure has char * >> fields initialised with troublemaking string literals, so the pointer type >> should be const char *. Previously the same issue was corrected by someone >> else in erratics robot_params.h, so why can't it be done the same with >> p2os? > > This file is generated. The files that actually need to be fixed are the > tcl files in server/codetools/saphconv/. > >> 3. server/drivers/mixed/rflex/rflex.cc the joy_control static >> property of RFLEX class cannot be declared extern. I guess only SunCC >> complains about it, so cmake should disable this driver if detected >> compiler is SunCC. To be honest, I can't find where this variable is >> instanced if it is extern here! >> or.... let's do it like that: >> >> #ifdef __SUNPRO_CC >> int RFLEX::joy_control; >> #else >> extern int RFLEX::joy_control; >> #endif > > Looking at what the code does with this variable, I don't think taking > away the extern will leave the driver in a fully-functional state. I've > disabled it for solaris instead. > > > Geoff > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: gbiggs <gb...@ki...> - 2009-02-18 00:09:58
|
Paul Osmialowski wrote: > Hi Geoff, > > I've obtained todays trunk snapshot to see how things work with sunCC. It > is much better now, however, there are four things to consider: > > 1. This has nothing in common with Solaris nor SunCC, but today looking at > playerconfig.h I noticed that all things that are defined looks like: > #define HAVE_FOO 1 > except one: HAVE_XDR, which looks: > #define HAVE_XDR > (no '1' at the end) why this one should differ? Just a typo. It's fixed now. > 2. recently applied upcbarcode fix causes new error: Odd, that compiled fine under my GCC. > 3. HAVE_IEEEFP_H definition is set properly (at least on Solaris with > SunStudio), however the way it is used in > server/drivers/localization/amcl/pf/pf_vector.c looks strange for me: > > #elif defined (sun) && defined (HAVE_IEEEFP_H) > #include <ieeefp.h> > #endif > > Are you sure that this header comes with Solaris only? I don't know every > OS in the world, but first answer from google says it is present at least > in Symbian: While I'm not sure symbian is one of our target operating systems, I guess it doesn't hurt to include the header if it's there. > (I'm curious, why are we using "#if defined (HAVE_FOO)"? Is good old > "#ifdef" not enough?). The first way looks prettier, and Player must be the prettiest girl at the ball. > 4. Still C++ client library cannot be compiled due to an error (however, > currently I'm not making any kind of use of it, so I can live without it): That's nothing, you should see what it does on Windows. Unfortunately, I have no idea what's causing those errors other than probably something just before the first one. Without a solaris environment here, there's not much I can do to investigate. Geoff |
From: Brian G. <br...@ge...> - 2009-02-19 16:44:21
|
On Feb 17, 2009, at 9:57 AM, Paul Osmialowski wrote: > 4. Still C++ client library cannot be compiled due to an error > (however, > currently I'm not making any kind of use of it, so I can live > without it): > > Scanning dependencies of target playerc++ > [ 18%] Building CXX object > client_libs/libplayerc++/CMakeFiles/playerc++.dir/playerc++.o > "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/ > playerc++.h", > line 1841: Error: Unexpected type name "player_pose2d_t" encountered. Here's the code the compiler is complaining about: void GoTo(player_pose2d_t pos) {GoTo(pos,(player_pose2d_t) {0,0,0}); } Perhaps your compiler doesn't like the compact struct initialization and cast inside the method call. I was about to suggest expanding that call to declare and then refer to an instance of the struct. Then I updated and noticed that Geoff already did that, presumably as part of getting the MS compiler to accept it. So you might update and try it again on Solaris. brian. |
From: gbiggs <gb...@ki...> - 2009-02-19 23:43:38
|
Well that was easier than I expected. :) Yeah, I changed that the other day when VC++ was throwing a fit about it. It was one of those "a single error leading to a thousand more" situations... It seems that the cl compiler's tokeniser got completely lost after that line, but kept trying anyway. Geoff Brian Gerkey wrote: > Here's the code the compiler is complaining about: > > void GoTo(player_pose2d_t pos) > {GoTo(pos,(player_pose2d_t) {0,0,0}); } > > Perhaps your compiler doesn't like the compact struct initialization > and cast inside the method call. > > I was about to suggest expanding that call to declare and then refer > to an instance of the struct. Then I updated and noticed that Geoff > already did that, presumably as part of getting the MS compiler to > accept it. So you might update and try it again on Solaris. |
From: Paul O. <new...@ki...> - 2009-02-19 20:17:47
|
hi Brian, That solved the problem. libplayerc++ finally compiled fine with no other errors using SunCC, also libplayerc++ examples all compiled fine. Soon I'm going to compile boost and I'll see how boost support for libplayerc++ compiles using SunCC. Paul On Thu, 19 Feb 2009, Brian Gerkey wrote: > > On Feb 17, 2009, at 9:57 AM, Paul Osmialowski wrote: > >> 4. Still C++ client library cannot be compiled due to an error >> (however, >> currently I'm not making any kind of use of it, so I can live >> without it): >> >> Scanning dependencies of target playerc++ >> [ 18%] Building CXX object >> client_libs/libplayerc++/CMakeFiles/playerc++.dir/playerc++.o >> "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/ >> playerc++.h", >> line 1841: Error: Unexpected type name "player_pose2d_t" encountered. > > Here's the code the compiler is complaining about: > > void GoTo(player_pose2d_t pos) > {GoTo(pos,(player_pose2d_t) {0,0,0}); } > > Perhaps your compiler doesn't like the compact struct initialization > and cast inside the method call. > > I was about to suggest expanding that call to declare and then refer > to an instance of the struct. Then I updated and noticed that Geoff > already did that, presumably as part of getting the MS compiler to > accept it. So you might update and try it again on Solaris. > > brian. > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Paul O. <new...@ki...> - 2009-02-22 16:02:11
|
Hello Devels, Installation of bjam and boost on Solaris uncovered only one additional error in libplayerc++ examples: Scanning dependencies of target example3 [ 88%] Building CXX object examples/libplayerc++/CMakeFiles/example3.dir/example3.o "/home/guest/psg22/src/player-20090219/examples/libplayerc++/example3.cc", line 31: Error: mem_fun is not a member of std. 1 Error(s) detected. *** Error code 1 According to C++ reference, mem_fun() is defined in <functional>, therefore this issue can be easily fixed by adding: #include <functional> into the examples/libplayerc++/example3.cc file. This solved the problem. Other things compiled fine. Paul On Thu, 19 Feb 2009, Paul Osmialowski wrote: > hi Brian, > > That solved the problem. libplayerc++ finally compiled fine with no other > errors using SunCC, also libplayerc++ examples all compiled fine. Soon I'm > going to compile boost and I'll see how boost support for libplayerc++ > compiles using SunCC. > > Paul > > On Thu, 19 Feb 2009, Brian Gerkey wrote: > >> >> On Feb 17, 2009, at 9:57 AM, Paul Osmialowski wrote: >> >>> 4. Still C++ client library cannot be compiled due to an error >>> (however, >>> currently I'm not making any kind of use of it, so I can live >>> without it): >>> >>> Scanning dependencies of target playerc++ >>> [ 18%] Building CXX object >>> client_libs/libplayerc++/CMakeFiles/playerc++.dir/playerc++.o >>> "/home/guest/psg22/src/player-20090217/client_libs/libplayerc++/ >>> playerc++.h", >>> line 1841: Error: Unexpected type name "player_pose2d_t" encountered. >> >> Here's the code the compiler is complaining about: >> >> void GoTo(player_pose2d_t pos) >> {GoTo(pos,(player_pose2d_t) {0,0,0}); } >> >> Perhaps your compiler doesn't like the compact struct initialization >> and cast inside the method call. >> >> I was about to suggest expanding that call to declare and then refer >> to an instance of the struct. Then I updated and noticed that Geoff >> already did that, presumably as part of getting the MS compiler to >> accept it. So you might update and try it again on Solaris. >> >> brian. >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |