Andrew Stitcher escribió:
On Fri, 2008-07-18 at 13:07 +0200, Manuel Teira wrote:
Hello all.
Unfortunately, I didn't have too much time to devote to this activity
later. Nevertheless, I was able to fix the last bug preventing the tests
to pass completely on my solaris build. The remaining problem was
submitted as QPID-1183.
So, I have a local copy with a set of uncommited changes, and I'm not
sure of the best way to proceed. Perhaps a categorization of the changes
should be a good beginning? So, I tell you what kind of changes are
needed (other than those already commited, or pending as JIRA patches),
and you could ask me to do it in a given way. As far as I remember now,
most changes can be categorized in this way:
I started looking for your changes today and realised that you haven't
submitted an actual patch.
Yes, I thought that it would be better to talk about the best way to
manage these changes, so, thanks for all your comments.
I think what I'd like you to do is to submit a patch for these changes
as they are (to save you much more work) and I'll look at the patch,
change it where I think necessary and hopefully commit the port.
That's nice. I'm going to do so in a while.
If you can be bothered to split the individual items below into
different jiras/patches that would help to keep each change in it's own
changeset, but if its too much work don't worry too much.
Well, if you can live with the one-file-patch mode, I prefer it. It's
always a little annoying to split the patch when the same file is
involved in several modifications belonging to different change.
Best regards.
--
Manuel.
Andrew
1.- Missing include files. I think this shouldn't hurt the linux build,
and I think that these changes could be commited in a single patch.
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);
2.2. - pthread_yield is not POSIX compliant. Using sched_yield for
the Solaris version, with a #ifdef/#ifndef clause.
3.- Solaris doesn't define the FTP and LOG_FTP syslog categories. Fixed
with a #ifdef/#ifndef clause.
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).
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
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.
7.- Replace all the u_intN_t typenames with uintN_t typenames. The
former ones are not available on solaris.
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?
