I have a quick look at the Solaris - Linux API differences... And with reference to Steve's comments as well:
> On Fri, 2008-07-18 at 13:07 +0200, Manuel Teira wrote: > ... > > 2.- Some GNUishms in system calls. I think there're two cases for this: > > 2.1.- POSIX strerror_r doesn't return the buffer. Temporarily, I've > > used a #ifndef clause, but I think that using the POSIX way everywhere > > should be better: > > > > #ifndef SUNOS > > return std::string(strerror_r(err, buf, sizeof(buf))); > > #else > > //POSIX strerror_r doesn't return the buffer > > strerror_r(err, buf, sizeof(buf)); > > return std::string(buf); I'll change the code to use the XPG6 version of strerror_r not the Gnu version as both work on Linux. > > > > 2.2. - pthread_yield is not POSIX compliant. Using sched_yield for > > the Solaris version, with a #ifdef/#ifndef clause. Again I'll change the code to use the portable form (although equally I might remove Thread::yield() completely as it's not used anywhere and I don't like the whole idea of yield outside of realtime threads) > > > > 3.- Solaris doesn't define the FTP and LOG_FTP syslog categories. Fixed > > with a #ifdef/#ifndef clause. Re Steve's comment about syslog having crept into the command line options too deeply - I agree, this does look a bit Posix syslog specific. Equally I think the #ifdef needs to be feature based here and set by configure rather than #ifdef SOLARIS. Actually I think that nearly all #ifdefs that we eventually accept will be feature tests not platform tests. > > > > 4.- The private inheritance bug in the solaris compiler > > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6710638). Fixed with > > a #ifdef/#ifndef to choose public inheritance when using the Sun > > compiler as a workaround (I know, it stinks). This is one place where the #ifdef actually should be something other than a feature test - as the problem here is *compiler* specific the test needs to be a compiler test. > > > > 5.- The Uuid.h solaris non-const members. I don't know why Solaris > > doesn't define some arguments to these functions as constant, but they > > produce compiler errors. The way I've fixed it was to use the dreaded > > #ifndef constructions: > > > > #ifdef SUNOS > > uuid_unparse(const_cast<uint8_t*>(uuid.data()), unparsed); > > #else > > uuid_unparse(uuid.data(), unparsed); > > #endif > > This is nasty, but I note the the Linux include files actually disagree with the man page, so I think the non const version is actually correct (even though it'd be better if it was const). So again I think that the code should just be modified to the solaris version (or something in that direction). > > > > 6.- Some explicit namespacing. In some parts of the code, I needed to > > specify the complete namespace for some calls. I don't know how it works > > on linux, because in most cases, no 'using' clause should guarantee the > > resolution of the namespace. It happened with some algorithms like > > for_each or some boost functions. I just added the namespace when the > > compiler complained. Adding the explicit namespace is fine. My only comment here is that it owuld be better if we could figure out the issue here so that when we add new code we don't keep on breaking the Solaris build. > > > > 7.- Replace all the u_intN_t typenames with uintN_t typenames. The > > former ones are not available on solaris. This is a tidy up that we've needed to do for ages. > > > > 8.- The queue issue. Some solaris header defines a struct name as > > 'queue'. Usage of that name in constructions like: > > > > session.queueDeclare(queue=q); > > session.messageSubscribe(queue=q, destination=dest, acquireMode=1); > > > > fires a compiler error, presumably because queue is a struct name. To > > avoid that, I decided to change that usage to: > > > > session.queueDeclare(arg::queue=q); > > session.messageSubscribe(arg::queue=q, arg::destination=dest, > > arg::acquireMode=1); > > > > Not the cleanest one, I know. Any idea to improve it? There's probably no good fix for this - ISTR that queue is defined somewhere in the Solaris streams headers and is virtually impossible to avoid in any code that includes much in usr/include/sys. Having said that it might just be possible by very careful including, but I don't hold out much hope. One really hacky/horrible (but possible solution) is to use #define queue xx_queue before the #include that gives you the struct and then #undef queue afterwards - this would make the defined struct have a different name by the time you get to our code. But if anyone else is also redefining queue with a macro things will get incomprehensible and buggy very quickly. Again, well done Andrew
