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.


2009/1/26 Paul Osmialowski <>
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

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?

urglaser and rs4leuze couldn't be linked. The error was:
Undefined                       first referenced
 symbol                             in file
 void urglaser_Register(DriverTable*) libplayerdrivers/
 void rs4leuze_Register(DriverTable*) libplayerdrivers/
 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)

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.

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.

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/ 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()
   (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/
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/ 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 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.


This email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
Playerstage-developers mailing list

This email is intended for the addressee only and may contain privileged and/or confidential information