You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Manuel Teira <mt...@tid.es> on 2008/07/18 13:07:32 UTC
Solaris port state
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:
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?
That's all, I think. Comments about the issues and the way the've been
fixed are welcomed.
Proudly attaching a console output of the 'make check' command:
bash-3.00$ uname -a
SunOS ps4000 5.10 Generic sun4u sparc SUNW,Sun-Fire-V210
bash-3.00$ make check
make libshlibtest.la libdlclose_noop.la unit_test perftest txtest
latencytest client_test topic_listener topic_publisher publish consume
`libshlibtest.la' is up to date.
`libdlclose_noop.la' is up to date.
`unit_test' is up to date.
`perftest' is up to date.
`txtest' is up to date.
`latencytest' is up to date.
`client_test' is up to date.
`topic_listener' is up to date.
`topic_publisher' is up to date.
`publish' is up to date.
`consume' is up to date.
make check-TESTS
Running 155 test cases...
2008-jul-18 12:02:48 error Exception in client dispatch thread:
Connection closed by broker
*** No errors detected
PASS: unit_test
PASS: start_broker
PASS: client_test
1779.01 1230.98 2658.65 2.59634
PASS: quick_perftest
PASS: quick_topictest
sh: objdump: not found
test_example (tests_0-10.example.ExampleTest) ... ok
test_auto_rollback (tests_0-10.tx.TxTests) ... ok
test_commit (tests_0-10.tx.TxTests) ... ok
test_rollback (tests_0-10.tx.TxTests) ... ok
test_broker_connectivity (tests_0-10.management.ManagementTest) ... ok
test_self_session_id (tests_0-10.management.ManagementTest) ... ok
test_standard_exchanges (tests_0-10.management.ManagementTest) ... ok
test_system_object (tests_0-10.management.ManagementTest) ... ok
test_bad_resume (tests_0-10.dtx.DtxTests) ... ok
test_commit_unknown (tests_0-10.dtx.DtxTests) ... ok
test_end (tests_0-10.dtx.DtxTests) ... ok
test_end_suspend_and_fail (tests_0-10.dtx.DtxTests) ... ok
test_end_unknown_xid (tests_0-10.dtx.DtxTests) ... ok
test_forget_xid_on_completion (tests_0-10.dtx.DtxTests) ... ok
test_get_timeout (tests_0-10.dtx.DtxTests) ... ok
test_get_timeout_unknown (tests_0-10.dtx.DtxTests) ... ok
test_implicit_end (tests_0-10.dtx.DtxTests) ... ok
test_invalid_commit_not_ended (tests_0-10.dtx.DtxTests) ... ok
test_invalid_commit_one_phase_false (tests_0-10.dtx.DtxTests) ... ok
test_invalid_commit_one_phase_true (tests_0-10.dtx.DtxTests) ... ok
test_invalid_prepare_not_ended (tests_0-10.dtx.DtxTests) ... ok
test_invalid_rollback_not_ended (tests_0-10.dtx.DtxTests) ... ok
test_prepare_unknown (tests_0-10.dtx.DtxTests) ... ok
test_recover (tests_0-10.dtx.DtxTests) ... ok
test_rollback_unknown (tests_0-10.dtx.DtxTests) ... ok
test_select_required (tests_0-10.dtx.DtxTests) ... ok
test_set_timeout (tests_0-10.dtx.DtxTests) ... ok
test_simple_commit (tests_0-10.dtx.DtxTests) ... ok
test_simple_prepare_commit (tests_0-10.dtx.DtxTests) ... ok
test_simple_prepare_rollback (tests_0-10.dtx.DtxTests) ... ok
test_simple_rollback (tests_0-10.dtx.DtxTests) ... ok
test_start_already_known (tests_0-10.dtx.DtxTests) ... ok
test_start_join (tests_0-10.dtx.DtxTests) ... ok
test_start_join_and_resume (tests_0-10.dtx.DtxTests) ... ok
test_suspend_resume (tests_0-10.dtx.DtxTests) ... ok
test_suspend_start_end_resume (tests_0-10.dtx.DtxTests) ... ok
test_delete_while_used_by_exchange
(tests_0-10.alternate_exchange.AlternateExchangeTests) ... ok
test_delete_while_used_by_queue
(tests_0-10.alternate_exchange.AlternateExchangeTests) ... ok
test_queue_delete (tests_0-10.alternate_exchange.AlternateExchangeTests)
... ok
test_unroutable (tests_0-10.alternate_exchange.AlternateExchangeTests)
... ok
test (tests_0-10.exchange.DeclareMethodPassiveFieldNotFoundRuleTests) ... ok
testDefaultExchange (tests_0-10.exchange.DefaultExchangeRuleTests) ... ok
testHeadersBindNoMatchArg (tests_0-10.exchange.ExchangeTests) ... ok
testMatchAll (tests_0-10.exchange.HeadersExchangeTests) ... ok
testMatchAny (tests_0-10.exchange.HeadersExchangeTests) ... ok
testDifferentDeclaredType (tests_0-10.exchange.MiscellaneousErrorsTests)
... ok
testTypeNotKnown (tests_0-10.exchange.MiscellaneousErrorsTests) ... ok
testDirect (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
testFanout (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
testHeaders (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
testTopic (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
testAmqDirect (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
testAmqFanOut (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
testAmqMatch (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
testAmqTopic (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
test_ack_and_no_ack (tests_0-10.broker.BrokerTests) ... ok
test_simple_delivery_immediate (tests_0-10.broker.BrokerTests) ... ok
test_simple_delivery_queued (tests_0-10.broker.BrokerTests) ... ok
test_ack (tests_0-10.message.MessageTests) ... ok
test_acquire (tests_0-10.message.MessageTests) ... ok
test_acquire_with_no_accept_and_credit_flow
(tests_0-10.message.MessageTests) ... ok
test_cancel (tests_0-10.message.MessageTests) ... ok
test_consume_exclusive (tests_0-10.message.MessageTests) ... ok
test_consume_exclusive2 (tests_0-10.message.MessageTests) ... ok
test_consume_queue_not_found (tests_0-10.message.MessageTests) ... ok
test_consume_queue_not_specified (tests_0-10.message.MessageTests) ... ok
test_consume_unique_consumers (tests_0-10.message.MessageTests) ... ok
test_credit_flow_bytes (tests_0-10.message.MessageTests) ... ok
test_credit_flow_messages (tests_0-10.message.MessageTests) ... ok
test_empty_body (tests_0-10.message.MessageTests) ... ok
test_incoming_start (tests_0-10.message.MessageTests) ... ok
test_no_local (tests_0-10.message.MessageTests) ... ok
test_no_local_awkward (tests_0-10.message.MessageTests) ... ok
test_no_local_exclusive_subscribe (tests_0-10.message.MessageTests) ... ok
test_ranged_ack (tests_0-10.message.MessageTests) ... ok
test_reject (tests_0-10.message.MessageTests) ... ok
test_release (tests_0-10.message.MessageTests) ... ok
test_release_ordering (tests_0-10.message.MessageTests) ... ok
test_release_unacquired (tests_0-10.message.MessageTests) ... ok
test_subscribe_not_acquired (tests_0-10.message.MessageTests) ... ok
test_subscribe_not_acquired_2 (tests_0-10.message.MessageTests) ... ok
test_subscribe_not_acquired_3 (tests_0-10.message.MessageTests) ... ok
test_window_flow_bytes (tests_0-10.message.MessageTests) ... ok
test_window_flow_messages (tests_0-10.message.MessageTests) ... ok
test_ack_message_from_deleted_queue
(tests_0-10.persistence.PersistenceTests) ... ok
test_delete_queue_after_publish
(tests_0-10.persistence.PersistenceTests) ... ok
test_queue_deletion (tests_0-10.persistence.PersistenceTests) ... ok
test_autodelete_shared (tests_0-10.queue.QueueTests) ... ok
test_bind (tests_0-10.queue.QueueTests) ... ok
test_bind_queue_existence (tests_0-10.queue.QueueTests) ... ok
test_declare_exclusive (tests_0-10.queue.QueueTests) ... ok
test_declare_passive (tests_0-10.queue.QueueTests) ... ok
test_delete_ifempty (tests_0-10.queue.QueueTests) ... ok
test_delete_ifunused (tests_0-10.queue.QueueTests) ... ok
test_delete_queue_exists (tests_0-10.queue.QueueTests) ... ok
test_delete_simple (tests_0-10.queue.QueueTests) ... ok
test_purge (tests_0-10.queue.QueueTests) ... ok
test_purge_empty_name (tests_0-10.queue.QueueTests) ... ok
test_purge_queue_exists (tests_0-10.queue.QueueTests) ... ok
test_unbind_direct (tests_0-10.queue.QueueTests) ... ok
test_unbind_fanout (tests_0-10.queue.QueueTests) ... ok
test_unbind_headers (tests_0-10.queue.QueueTests) ... ok
test_unbind_topic (tests_0-10.queue.QueueTests) ... ok
test_exchange_bound_direct (tests_0-10.query.QueryTests) ... ok
test_exchange_bound_fanout (tests_0-10.query.QueryTests) ... ok
test_exchange_bound_header (tests_0-10.query.QueryTests) ... ok
test_exchange_bound_topic (tests_0-10.query.QueryTests) ... ok
test_exchange_query (tests_0-10.query.QueryTests) ... ok
test_queue_query (tests_0-10.query.QueryTests) ... ok
test_queue_query_unknown (tests_0-10.query.QueryTests) ... ok
----------------------------------------------------------------------
Ran 110 tests in 86.495s
OK
PASS: python_tests
PASS: stop_broker
Running federation tests using brokers on ports 46788 46789
sh: objdump: not found
test_bridge_create_and_close (federation.FederationTests) ... ok
test_pull_from_exchange (federation.FederationTests) ... ok
test_pull_from_queue (federation.FederationTests) ... ok
test_tracing (federation.FederationTests) ... ok
----------------------------------------------------------------------
Ran 4 tests in 46.718s
OK
PASS: run_federation_tests
==================
All 8 tests passed
==================
Re: Solaris port state
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2008-07-18 at 17:51 +0100, Gordon Sim wrote:
> Andrew Stitcher wrote:
> >> On Fri, 2008-07-18 at 13:07 +0200, Manuel Teira wrote:
> >>> 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.
>
> Personally I think the change itself is fine in any case. I think all
> the examples and the bulk of the tests use the arg:: qualifier anyway.
>
+1. It's good practice to always use the arg:: qualifier since there are
so many argument keywords (queue, destination, exchange etc.) that could
potentially clash with names from unrelated headers (or even from our
own - queue used to cause a self-clash at one point though not anymore)
Re: Solaris port state
Posted by Gordon Sim <gs...@redhat.com>.
Andrew Stitcher wrote:
>> On Fri, 2008-07-18 at 13:07 +0200, Manuel Teira wrote:
>>> 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.
Personally I think the change itself is fine in any case. I think all
the examples and the bulk of the tests use the arg:: qualifier anyway.
Re: Solaris port state
Posted by Andrew Stitcher <as...@redhat.com>.
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
Re: Solaris port state
Posted by Andrew Stitcher <as...@redhat.com>.
I will take a look at this next week with a minimum aim of merging the
"obviously" correct changes (like the u_intX -> uintX changes).
Some of the #ifdef change might be better solved by creating new files
in a new qpid/sys/solaris directory (or whatever you called the new
directory for the ECF Poller code), I'll take a proper look and have a
think, but as I said earlier (I think) I dislike #ifdef a lot as it soon
leads to unreadable code once people think it's okay to use.
Very well done for getting this far, we really appreciate having the
code ported to more OSes and compilers, it enormously improves the code
quality.
Andrew
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:
>
>
> 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?
>
>
> That's all, I think. Comments about the issues and the way the've been
> fixed are welcomed.
>
>
> Proudly attaching a console output of the 'make check' command:
>
> bash-3.00$ uname -a
> SunOS ps4000 5.10 Generic sun4u sparc SUNW,Sun-Fire-V210
> bash-3.00$ make check
> make libshlibtest.la libdlclose_noop.la unit_test perftest txtest
> latencytest client_test topic_listener topic_publisher publish consume
> `libshlibtest.la' is up to date.
> `libdlclose_noop.la' is up to date.
> `unit_test' is up to date.
> `perftest' is up to date.
> `txtest' is up to date.
> `latencytest' is up to date.
> `client_test' is up to date.
> `topic_listener' is up to date.
> `topic_publisher' is up to date.
> `publish' is up to date.
> `consume' is up to date.
> make check-TESTS
> Running 155 test cases...
> 2008-jul-18 12:02:48 error Exception in client dispatch thread:
> Connection closed by broker
>
> *** No errors detected
> PASS: unit_test
> PASS: start_broker
> PASS: client_test
> 1779.01 1230.98 2658.65 2.59634
> PASS: quick_perftest
> PASS: quick_topictest
> sh: objdump: not found
> test_example (tests_0-10.example.ExampleTest) ... ok
> test_auto_rollback (tests_0-10.tx.TxTests) ... ok
> test_commit (tests_0-10.tx.TxTests) ... ok
> test_rollback (tests_0-10.tx.TxTests) ... ok
> test_broker_connectivity (tests_0-10.management.ManagementTest) ... ok
> test_self_session_id (tests_0-10.management.ManagementTest) ... ok
> test_standard_exchanges (tests_0-10.management.ManagementTest) ... ok
> test_system_object (tests_0-10.management.ManagementTest) ... ok
> test_bad_resume (tests_0-10.dtx.DtxTests) ... ok
> test_commit_unknown (tests_0-10.dtx.DtxTests) ... ok
> test_end (tests_0-10.dtx.DtxTests) ... ok
> test_end_suspend_and_fail (tests_0-10.dtx.DtxTests) ... ok
> test_end_unknown_xid (tests_0-10.dtx.DtxTests) ... ok
> test_forget_xid_on_completion (tests_0-10.dtx.DtxTests) ... ok
> test_get_timeout (tests_0-10.dtx.DtxTests) ... ok
> test_get_timeout_unknown (tests_0-10.dtx.DtxTests) ... ok
> test_implicit_end (tests_0-10.dtx.DtxTests) ... ok
> test_invalid_commit_not_ended (tests_0-10.dtx.DtxTests) ... ok
> test_invalid_commit_one_phase_false (tests_0-10.dtx.DtxTests) ... ok
> test_invalid_commit_one_phase_true (tests_0-10.dtx.DtxTests) ... ok
> test_invalid_prepare_not_ended (tests_0-10.dtx.DtxTests) ... ok
> test_invalid_rollback_not_ended (tests_0-10.dtx.DtxTests) ... ok
> test_prepare_unknown (tests_0-10.dtx.DtxTests) ... ok
> test_recover (tests_0-10.dtx.DtxTests) ... ok
> test_rollback_unknown (tests_0-10.dtx.DtxTests) ... ok
> test_select_required (tests_0-10.dtx.DtxTests) ... ok
> test_set_timeout (tests_0-10.dtx.DtxTests) ... ok
> test_simple_commit (tests_0-10.dtx.DtxTests) ... ok
> test_simple_prepare_commit (tests_0-10.dtx.DtxTests) ... ok
> test_simple_prepare_rollback (tests_0-10.dtx.DtxTests) ... ok
> test_simple_rollback (tests_0-10.dtx.DtxTests) ... ok
> test_start_already_known (tests_0-10.dtx.DtxTests) ... ok
> test_start_join (tests_0-10.dtx.DtxTests) ... ok
> test_start_join_and_resume (tests_0-10.dtx.DtxTests) ... ok
> test_suspend_resume (tests_0-10.dtx.DtxTests) ... ok
> test_suspend_start_end_resume (tests_0-10.dtx.DtxTests) ... ok
> test_delete_while_used_by_exchange
> (tests_0-10.alternate_exchange.AlternateExchangeTests) ... ok
> test_delete_while_used_by_queue
> (tests_0-10.alternate_exchange.AlternateExchangeTests) ... ok
> test_queue_delete (tests_0-10.alternate_exchange.AlternateExchangeTests)
> ... ok
> test_unroutable (tests_0-10.alternate_exchange.AlternateExchangeTests)
> ... ok
> test (tests_0-10.exchange.DeclareMethodPassiveFieldNotFoundRuleTests) ... ok
> testDefaultExchange (tests_0-10.exchange.DefaultExchangeRuleTests) ... ok
> testHeadersBindNoMatchArg (tests_0-10.exchange.ExchangeTests) ... ok
> testMatchAll (tests_0-10.exchange.HeadersExchangeTests) ... ok
> testMatchAny (tests_0-10.exchange.HeadersExchangeTests) ... ok
> testDifferentDeclaredType (tests_0-10.exchange.MiscellaneousErrorsTests)
> ... ok
> testTypeNotKnown (tests_0-10.exchange.MiscellaneousErrorsTests) ... ok
> testDirect (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
> testFanout (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
> testHeaders (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
> testTopic (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
> testAmqDirect (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
> testAmqFanOut (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
> testAmqMatch (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
> testAmqTopic (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
> test_ack_and_no_ack (tests_0-10.broker.BrokerTests) ... ok
> test_simple_delivery_immediate (tests_0-10.broker.BrokerTests) ... ok
> test_simple_delivery_queued (tests_0-10.broker.BrokerTests) ... ok
> test_ack (tests_0-10.message.MessageTests) ... ok
> test_acquire (tests_0-10.message.MessageTests) ... ok
> test_acquire_with_no_accept_and_credit_flow
> (tests_0-10.message.MessageTests) ... ok
> test_cancel (tests_0-10.message.MessageTests) ... ok
> test_consume_exclusive (tests_0-10.message.MessageTests) ... ok
> test_consume_exclusive2 (tests_0-10.message.MessageTests) ... ok
> test_consume_queue_not_found (tests_0-10.message.MessageTests) ... ok
> test_consume_queue_not_specified (tests_0-10.message.MessageTests) ... ok
> test_consume_unique_consumers (tests_0-10.message.MessageTests) ... ok
> test_credit_flow_bytes (tests_0-10.message.MessageTests) ... ok
> test_credit_flow_messages (tests_0-10.message.MessageTests) ... ok
> test_empty_body (tests_0-10.message.MessageTests) ... ok
> test_incoming_start (tests_0-10.message.MessageTests) ... ok
> test_no_local (tests_0-10.message.MessageTests) ... ok
> test_no_local_awkward (tests_0-10.message.MessageTests) ... ok
> test_no_local_exclusive_subscribe (tests_0-10.message.MessageTests) ... ok
> test_ranged_ack (tests_0-10.message.MessageTests) ... ok
> test_reject (tests_0-10.message.MessageTests) ... ok
> test_release (tests_0-10.message.MessageTests) ... ok
> test_release_ordering (tests_0-10.message.MessageTests) ... ok
> test_release_unacquired (tests_0-10.message.MessageTests) ... ok
> test_subscribe_not_acquired (tests_0-10.message.MessageTests) ... ok
> test_subscribe_not_acquired_2 (tests_0-10.message.MessageTests) ... ok
> test_subscribe_not_acquired_3 (tests_0-10.message.MessageTests) ... ok
> test_window_flow_bytes (tests_0-10.message.MessageTests) ... ok
> test_window_flow_messages (tests_0-10.message.MessageTests) ... ok
> test_ack_message_from_deleted_queue
> (tests_0-10.persistence.PersistenceTests) ... ok
> test_delete_queue_after_publish
> (tests_0-10.persistence.PersistenceTests) ... ok
> test_queue_deletion (tests_0-10.persistence.PersistenceTests) ... ok
> test_autodelete_shared (tests_0-10.queue.QueueTests) ... ok
> test_bind (tests_0-10.queue.QueueTests) ... ok
> test_bind_queue_existence (tests_0-10.queue.QueueTests) ... ok
> test_declare_exclusive (tests_0-10.queue.QueueTests) ... ok
> test_declare_passive (tests_0-10.queue.QueueTests) ... ok
> test_delete_ifempty (tests_0-10.queue.QueueTests) ... ok
> test_delete_ifunused (tests_0-10.queue.QueueTests) ... ok
> test_delete_queue_exists (tests_0-10.queue.QueueTests) ... ok
> test_delete_simple (tests_0-10.queue.QueueTests) ... ok
> test_purge (tests_0-10.queue.QueueTests) ... ok
> test_purge_empty_name (tests_0-10.queue.QueueTests) ... ok
> test_purge_queue_exists (tests_0-10.queue.QueueTests) ... ok
> test_unbind_direct (tests_0-10.queue.QueueTests) ... ok
> test_unbind_fanout (tests_0-10.queue.QueueTests) ... ok
> test_unbind_headers (tests_0-10.queue.QueueTests) ... ok
> test_unbind_topic (tests_0-10.queue.QueueTests) ... ok
> test_exchange_bound_direct (tests_0-10.query.QueryTests) ... ok
> test_exchange_bound_fanout (tests_0-10.query.QueryTests) ... ok
> test_exchange_bound_header (tests_0-10.query.QueryTests) ... ok
> test_exchange_bound_topic (tests_0-10.query.QueryTests) ... ok
> test_exchange_query (tests_0-10.query.QueryTests) ... ok
> test_queue_query (tests_0-10.query.QueryTests) ... ok
> test_queue_query_unknown (tests_0-10.query.QueryTests) ... ok
>
> ----------------------------------------------------------------------
> Ran 110 tests in 86.495s
>
> OK
> PASS: python_tests
> PASS: stop_broker
> Running federation tests using brokers on ports 46788 46789
> sh: objdump: not found
> test_bridge_create_and_close (federation.FederationTests) ... ok
> test_pull_from_exchange (federation.FederationTests) ... ok
> test_pull_from_queue (federation.FederationTests) ... ok
> test_tracing (federation.FederationTests) ... ok
>
> ----------------------------------------------------------------------
> Ran 4 tests in 46.718s
>
> OK
> PASS: run_federation_tests
> ==================
> All 8 tests passed
> ==================
>
>
>
Re: Solaris port state
Posted by Manuel Teira <mt...@tid.es>.
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.
>
> 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.
>
> 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.
>
> Andrew
Commited to JIRA as QPID-1198.
Changes are in its original state, so, feel free to adapt it to the
changes you planned to do (Thread yield issue, or uuid constness).
Best regards.
--
Manuel.
Re: Solaris port state
Posted by Manuel Teira <mt...@tid.es>.
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?
>>
>>
>>
>
Re: Solaris port state
Posted by Andrew Stitcher <as...@redhat.com>.
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.
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.
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.
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?
>
>
> That's all, I think. Comments about the issues and the way the've been
> fixed are welcomed.
>
>
> Proudly attaching a console output of the 'make check' command:
>
> bash-3.00$ uname -a
> SunOS ps4000 5.10 Generic sun4u sparc SUNW,Sun-Fire-V210
> bash-3.00$ make check
> make libshlibtest.la libdlclose_noop.la unit_test perftest txtest
> latencytest client_test topic_listener topic_publisher publish consume
> `libshlibtest.la' is up to date.
> `libdlclose_noop.la' is up to date.
> `unit_test' is up to date.
> `perftest' is up to date.
> `txtest' is up to date.
> `latencytest' is up to date.
> `client_test' is up to date.
> `topic_listener' is up to date.
> `topic_publisher' is up to date.
> `publish' is up to date.
> `consume' is up to date.
> make check-TESTS
> Running 155 test cases...
> 2008-jul-18 12:02:48 error Exception in client dispatch thread:
> Connection closed by broker
>
> *** No errors detected
> PASS: unit_test
> PASS: start_broker
> PASS: client_test
> 1779.01 1230.98 2658.65 2.59634
> PASS: quick_perftest
> PASS: quick_topictest
> sh: objdump: not found
> test_example (tests_0-10.example.ExampleTest) ... ok
> test_auto_rollback (tests_0-10.tx.TxTests) ... ok
> test_commit (tests_0-10.tx.TxTests) ... ok
> test_rollback (tests_0-10.tx.TxTests) ... ok
> test_broker_connectivity (tests_0-10.management.ManagementTest) ... ok
> test_self_session_id (tests_0-10.management.ManagementTest) ... ok
> test_standard_exchanges (tests_0-10.management.ManagementTest) ... ok
> test_system_object (tests_0-10.management.ManagementTest) ... ok
> test_bad_resume (tests_0-10.dtx.DtxTests) ... ok
> test_commit_unknown (tests_0-10.dtx.DtxTests) ... ok
> test_end (tests_0-10.dtx.DtxTests) ... ok
> test_end_suspend_and_fail (tests_0-10.dtx.DtxTests) ... ok
> test_end_unknown_xid (tests_0-10.dtx.DtxTests) ... ok
> test_forget_xid_on_completion (tests_0-10.dtx.DtxTests) ... ok
> test_get_timeout (tests_0-10.dtx.DtxTests) ... ok
> test_get_timeout_unknown (tests_0-10.dtx.DtxTests) ... ok
> test_implicit_end (tests_0-10.dtx.DtxTests) ... ok
> test_invalid_commit_not_ended (tests_0-10.dtx.DtxTests) ... ok
> test_invalid_commit_one_phase_false (tests_0-10.dtx.DtxTests) ... ok
> test_invalid_commit_one_phase_true (tests_0-10.dtx.DtxTests) ... ok
> test_invalid_prepare_not_ended (tests_0-10.dtx.DtxTests) ... ok
> test_invalid_rollback_not_ended (tests_0-10.dtx.DtxTests) ... ok
> test_prepare_unknown (tests_0-10.dtx.DtxTests) ... ok
> test_recover (tests_0-10.dtx.DtxTests) ... ok
> test_rollback_unknown (tests_0-10.dtx.DtxTests) ... ok
> test_select_required (tests_0-10.dtx.DtxTests) ... ok
> test_set_timeout (tests_0-10.dtx.DtxTests) ... ok
> test_simple_commit (tests_0-10.dtx.DtxTests) ... ok
> test_simple_prepare_commit (tests_0-10.dtx.DtxTests) ... ok
> test_simple_prepare_rollback (tests_0-10.dtx.DtxTests) ... ok
> test_simple_rollback (tests_0-10.dtx.DtxTests) ... ok
> test_start_already_known (tests_0-10.dtx.DtxTests) ... ok
> test_start_join (tests_0-10.dtx.DtxTests) ... ok
> test_start_join_and_resume (tests_0-10.dtx.DtxTests) ... ok
> test_suspend_resume (tests_0-10.dtx.DtxTests) ... ok
> test_suspend_start_end_resume (tests_0-10.dtx.DtxTests) ... ok
> test_delete_while_used_by_exchange
> (tests_0-10.alternate_exchange.AlternateExchangeTests) ... ok
> test_delete_while_used_by_queue
> (tests_0-10.alternate_exchange.AlternateExchangeTests) ... ok
> test_queue_delete (tests_0-10.alternate_exchange.AlternateExchangeTests)
> ... ok
> test_unroutable (tests_0-10.alternate_exchange.AlternateExchangeTests)
> ... ok
> test (tests_0-10.exchange.DeclareMethodPassiveFieldNotFoundRuleTests) ... ok
> testDefaultExchange (tests_0-10.exchange.DefaultExchangeRuleTests) ... ok
> testHeadersBindNoMatchArg (tests_0-10.exchange.ExchangeTests) ... ok
> testMatchAll (tests_0-10.exchange.HeadersExchangeTests) ... ok
> testMatchAny (tests_0-10.exchange.HeadersExchangeTests) ... ok
> testDifferentDeclaredType (tests_0-10.exchange.MiscellaneousErrorsTests)
> ... ok
> testTypeNotKnown (tests_0-10.exchange.MiscellaneousErrorsTests) ... ok
> testDirect (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
> testFanout (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
> testHeaders (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
> testTopic (tests_0-10.exchange.RecommendedTypesRuleTests) ... ok
> testAmqDirect (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
> testAmqFanOut (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
> testAmqMatch (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
> testAmqTopic (tests_0-10.exchange.RequiredInstancesRuleTests) ... ok
> test_ack_and_no_ack (tests_0-10.broker.BrokerTests) ... ok
> test_simple_delivery_immediate (tests_0-10.broker.BrokerTests) ... ok
> test_simple_delivery_queued (tests_0-10.broker.BrokerTests) ... ok
> test_ack (tests_0-10.message.MessageTests) ... ok
> test_acquire (tests_0-10.message.MessageTests) ... ok
> test_acquire_with_no_accept_and_credit_flow
> (tests_0-10.message.MessageTests) ... ok
> test_cancel (tests_0-10.message.MessageTests) ... ok
> test_consume_exclusive (tests_0-10.message.MessageTests) ... ok
> test_consume_exclusive2 (tests_0-10.message.MessageTests) ... ok
> test_consume_queue_not_found (tests_0-10.message.MessageTests) ... ok
> test_consume_queue_not_specified (tests_0-10.message.MessageTests) ... ok
> test_consume_unique_consumers (tests_0-10.message.MessageTests) ... ok
> test_credit_flow_bytes (tests_0-10.message.MessageTests) ... ok
> test_credit_flow_messages (tests_0-10.message.MessageTests) ... ok
> test_empty_body (tests_0-10.message.MessageTests) ... ok
> test_incoming_start (tests_0-10.message.MessageTests) ... ok
> test_no_local (tests_0-10.message.MessageTests) ... ok
> test_no_local_awkward (tests_0-10.message.MessageTests) ... ok
> test_no_local_exclusive_subscribe (tests_0-10.message.MessageTests) ... ok
> test_ranged_ack (tests_0-10.message.MessageTests) ... ok
> test_reject (tests_0-10.message.MessageTests) ... ok
> test_release (tests_0-10.message.MessageTests) ... ok
> test_release_ordering (tests_0-10.message.MessageTests) ... ok
> test_release_unacquired (tests_0-10.message.MessageTests) ... ok
> test_subscribe_not_acquired (tests_0-10.message.MessageTests) ... ok
> test_subscribe_not_acquired_2 (tests_0-10.message.MessageTests) ... ok
> test_subscribe_not_acquired_3 (tests_0-10.message.MessageTests) ... ok
> test_window_flow_bytes (tests_0-10.message.MessageTests) ... ok
> test_window_flow_messages (tests_0-10.message.MessageTests) ... ok
> test_ack_message_from_deleted_queue
> (tests_0-10.persistence.PersistenceTests) ... ok
> test_delete_queue_after_publish
> (tests_0-10.persistence.PersistenceTests) ... ok
> test_queue_deletion (tests_0-10.persistence.PersistenceTests) ... ok
> test_autodelete_shared (tests_0-10.queue.QueueTests) ... ok
> test_bind (tests_0-10.queue.QueueTests) ... ok
> test_bind_queue_existence (tests_0-10.queue.QueueTests) ... ok
> test_declare_exclusive (tests_0-10.queue.QueueTests) ... ok
> test_declare_passive (tests_0-10.queue.QueueTests) ... ok
> test_delete_ifempty (tests_0-10.queue.QueueTests) ... ok
> test_delete_ifunused (tests_0-10.queue.QueueTests) ... ok
> test_delete_queue_exists (tests_0-10.queue.QueueTests) ... ok
> test_delete_simple (tests_0-10.queue.QueueTests) ... ok
> test_purge (tests_0-10.queue.QueueTests) ... ok
> test_purge_empty_name (tests_0-10.queue.QueueTests) ... ok
> test_purge_queue_exists (tests_0-10.queue.QueueTests) ... ok
> test_unbind_direct (tests_0-10.queue.QueueTests) ... ok
> test_unbind_fanout (tests_0-10.queue.QueueTests) ... ok
> test_unbind_headers (tests_0-10.queue.QueueTests) ... ok
> test_unbind_topic (tests_0-10.queue.QueueTests) ... ok
> test_exchange_bound_direct (tests_0-10.query.QueryTests) ... ok
> test_exchange_bound_fanout (tests_0-10.query.QueryTests) ... ok
> test_exchange_bound_header (tests_0-10.query.QueryTests) ... ok
> test_exchange_bound_topic (tests_0-10.query.QueryTests) ... ok
> test_exchange_query (tests_0-10.query.QueryTests) ... ok
> test_queue_query (tests_0-10.query.QueryTests) ... ok
> test_queue_query_unknown (tests_0-10.query.QueryTests) ... ok
>
> ----------------------------------------------------------------------
> Ran 110 tests in 86.495s
>
> OK
> PASS: python_tests
> PASS: stop_broker
> Running federation tests using brokers on ports 46788 46789
> sh: objdump: not found
> test_bridge_create_and_close (federation.FederationTests) ... ok
> test_pull_from_exchange (federation.FederationTests) ... ok
> test_pull_from_queue (federation.FederationTests) ... ok
> test_tracing (federation.FederationTests) ... ok
>
> ----------------------------------------------------------------------
> Ran 4 tests in 46.718s
>
> OK
> PASS: run_federation_tests
> ==================
> All 8 tests passed
> ==================
>
>
>
Re: Solaris port state
Posted by Manuel Teira <mt...@tid.es>.
Robert Greig escribió:
> 2008/8/20 Manuel Teira <mt...@tid.es>:
>
>
>> I don't know if these implicit dependencies should be tracked automatically
>> by the compiler (it seems to know where the dependency is located, but
>> refuses to link it). I think that adding boost_system to the libraries
>> needed by qpidd, regardless the compiler won't hurt. What do you think?
>>
>
> Just a guess but I presume the platform difference is due to
> differences in the output file format - i.e. only explicit
> dependencies are recorded on solaris?
>
After googling a bit, I didn't found any positive reason to explain it
(but it's a very usual error linking ported code in Solaris)
Nevertheless, in my opinion, the fact is that we are referencing
directly to a symbol existing in a A library, being aware that the
already linked B library will link A. The only confusing thing here is
that the symbol get referenced through the inclusion of the B header. I
guess that the gnu linker tries to resolve all the linked libraries,
whereas the solaris one is only collecting symbols from the explicitly
linked libraries to resolve those undefined in the object files.
Regards.
Manuel.
> RG
>
>
Re: Solaris port state
Posted by Robert Greig <ro...@gmail.com>.
2008/8/20 Manuel Teira <mt...@tid.es>:
> I don't know if these implicit dependencies should be tracked automatically
> by the compiler (it seems to know where the dependency is located, but
> refuses to link it). I think that adding boost_system to the libraries
> needed by qpidd, regardless the compiler won't hurt. What do you think?
Just a guess but I presume the platform difference is due to
differences in the output file format - i.e. only explicit
dependencies are recorded on solaris?
RG
Re: Solaris port state
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2008-08-20 at 14:10 +0200, Manuel Teira wrote:
> Manuel Teira escribió:
> > After this, and a pair of minor changes I've sent to Andrew, regarding
> > previously committed changes, there's only one little glitch avoiding a
> > clean solaris build. I'm asking for your advise with this issue:
> >
> > I need to explicitly provide a -lboost_system to link qpidd. I don't
> > know if it's related with some solaris linker bug or feature, but even
> > when I provide a LD_LIBRARY_PATH with the boost libraries location, it
> > seems unable to find it. This is what the linker dumps out when no
> > -lboost_system is provided:
> >
> > CC -g -m64 -I/opt/dslap/contrib/include -mt -mt -o .libs/qpidd qpidd.o
> > -L/opt/dslap/contrib/lib -L/usr/lib/openais -L/usr/lib64/openais
> > ./.libs/libqpidbroker.so
> > /export/home/devel/ws/DSLAP/qpid/trunk/qpid/cpp/src/.libs/libqpidcommon.so
> > ./.libs/libqpidcommon.so -lboost_program_options -lboost_filesystem
> > -luuid -library=stlport4 -R/opt/dslap/contrib/lib
> > ld: warning: file ./.libs/libqpidcommon.so: linked to
> > /export/home/devel/ws/DSLAP/qpid/trunk/qpid/cpp/src/.libs/libqpidcommon.so:
> > attempted multiple inclusion of file
> > Undefined first referenced
> > symbol in file
> > const boost::system::error_category&boost::system::get_posix_category()
> > qpidd.o (symbol belongs to implicit dependency
> > /opt/dslap/contrib/lib/libboost_system.so)
> > const boost::system::error_category&boost::system::get_system_category()
> > qpidd.o (symbol belongs to implicit dependency
> > /opt/dslap/contrib/lib/libboost_system.so)
> > ld: fatal: Symbol referencing errors. No output written to .libs/qpidd
> >
> >
>
> More info on this issue. It seems that the actual problem is that SunCC
> tools refuse to resolve this kind of implicit dependencies. I've
> isolated a little example, sure it can be minimized, as always:
>
> $ cat A.h
> #ifndef A_H
> #define A_H
> int A();
> #endif
>
> $cat A.cc
> #include "A.h"
>
> int A() {
> return 10;
> }
>
> $cat B.h
> #ifndef B_H
> #define B_H
> #include "A.h"
> int B() { return A(); };
> int C();
> #endif
>
> $cat B.cc
> #include "B.h"
> int C() { return 0; }
>
> $ cat main.cc
> #include "B.h"
> int main(int argc, char **argv) {
> B();
> }
>
> $cat Makefile
> CXX = CC
> LD = $(CXX) -G
>
> %.o : %.cc
> $(CXX) -c $<
>
> test : libA.so libB.so main.o
> $(CXX) -o test main.o -L. -lB
>
> libA.so : A.o
> $(LD) -o libA.so A.o
>
> libB.so : B.o
> $(LD) -o libB.so B.o -L. -lA
>
> clean:
> rm -rf *.so *.o test
>
> This is more or less the same case than in the libboost_filesystem and
> libboost_system issue. Some symbols defined in libboost_system.so have
> inlined usage in the libboost_filesystem header, thus injecting
> unresolved symbols of libboost_system in source code including headers
> from libboost_system. To be more precise, this behaviour is seen in:
> qpidd.cpp including boost/filesystem/path.hpp
> boost/filesystem/path.hpp including boost/system/system_error.hpp
> boost/system/system_error.hpp including boost/system/error_code.hpp
> boost/system/error_code.hpp defining
> BOOST_SYSTEM_DECL const error_category & get_system_category();
>
> Compiling the previous example, using Sun CC:
>
> $ make
> CC -c A.cc
> CC -G -o libA.so A.o
> CC -c B.cc
> CC -G -o libB.so B.o -L. -lA
> CC -c main.cc
> CC -o test main.o -L. -lB
> Undefined first referenced
> symbol in file
> int A() main.o (symbol belongs to implicit
> dependency ./libA.so)
> ld: fatal: Symbol referencing errors. No output written to test
> *** Error code 1
> make: Fatal error: Command failed for target `test'
>
> Whereas doing the same with GNU g++ on a Linux machine:
> $ make CXX=g++ LD="g++ -shared"
> g++ -c A.cc
> g++ -shared -o libA.so A.o
> g++ -c B.cc
> g++ -shared -o libB.so B.o -L. -lA
> g++ -c main.cc
> g++ -o test main.o -L. -lB
>
> Works fine, being the test executable dinamically linked against the two
> libraries.
>
> I don't know if these implicit dependencies should be tracked
> automatically by the compiler (it seems to know where the dependency is
> located, but refuses to link it). I think that adding boost_system to
> the libraries needed by qpidd, regardless the compiler won't hurt. What
> do you think?
>
> Regards.
>
I don't see a problem with this, but we should make it clear that it's
required by Solaris - at least in a comment if not in a makefile
conditional - otherwise some day someone using linux will say "hey
that's not required, it's linked implicitly" and take it out again.
Cheers,
Alan.
Re: Solaris port state
Posted by Manuel Teira <mt...@tid.es>.
Manuel Teira escribió:
> After this, and a pair of minor changes I've sent to Andrew, regarding
> previously committed changes, there's only one little glitch avoiding a
> clean solaris build. I'm asking for your advise with this issue:
>
> I need to explicitly provide a -lboost_system to link qpidd. I don't
> know if it's related with some solaris linker bug or feature, but even
> when I provide a LD_LIBRARY_PATH with the boost libraries location, it
> seems unable to find it. This is what the linker dumps out when no
> -lboost_system is provided:
>
> CC -g -m64 -I/opt/dslap/contrib/include -mt -mt -o .libs/qpidd qpidd.o
> -L/opt/dslap/contrib/lib -L/usr/lib/openais -L/usr/lib64/openais
> ./.libs/libqpidbroker.so
> /export/home/devel/ws/DSLAP/qpid/trunk/qpid/cpp/src/.libs/libqpidcommon.so
> ./.libs/libqpidcommon.so -lboost_program_options -lboost_filesystem
> -luuid -library=stlport4 -R/opt/dslap/contrib/lib
> ld: warning: file ./.libs/libqpidcommon.so: linked to
> /export/home/devel/ws/DSLAP/qpid/trunk/qpid/cpp/src/.libs/libqpidcommon.so:
> attempted multiple inclusion of file
> Undefined first referenced
> symbol in file
> const boost::system::error_category&boost::system::get_posix_category()
> qpidd.o (symbol belongs to implicit dependency
> /opt/dslap/contrib/lib/libboost_system.so)
> const boost::system::error_category&boost::system::get_system_category()
> qpidd.o (symbol belongs to implicit dependency
> /opt/dslap/contrib/lib/libboost_system.so)
> ld: fatal: Symbol referencing errors. No output written to .libs/qpidd
>
>
More info on this issue. It seems that the actual problem is that SunCC
tools refuse to resolve this kind of implicit dependencies. I've
isolated a little example, sure it can be minimized, as always:
$ cat A.h
#ifndef A_H
#define A_H
int A();
#endif
$cat A.cc
#include "A.h"
int A() {
return 10;
}
$cat B.h
#ifndef B_H
#define B_H
#include "A.h"
int B() { return A(); };
int C();
#endif
$cat B.cc
#include "B.h"
int C() { return 0; }
$ cat main.cc
#include "B.h"
int main(int argc, char **argv) {
B();
}
$cat Makefile
CXX = CC
LD = $(CXX) -G
%.o : %.cc
$(CXX) -c $<
test : libA.so libB.so main.o
$(CXX) -o test main.o -L. -lB
libA.so : A.o
$(LD) -o libA.so A.o
libB.so : B.o
$(LD) -o libB.so B.o -L. -lA
clean:
rm -rf *.so *.o test
This is more or less the same case than in the libboost_filesystem and
libboost_system issue. Some symbols defined in libboost_system.so have
inlined usage in the libboost_filesystem header, thus injecting
unresolved symbols of libboost_system in source code including headers
from libboost_system. To be more precise, this behaviour is seen in:
qpidd.cpp including boost/filesystem/path.hpp
boost/filesystem/path.hpp including boost/system/system_error.hpp
boost/system/system_error.hpp including boost/system/error_code.hpp
boost/system/error_code.hpp defining
BOOST_SYSTEM_DECL const error_category & get_system_category();
Compiling the previous example, using Sun CC:
$ make
CC -c A.cc
CC -G -o libA.so A.o
CC -c B.cc
CC -G -o libB.so B.o -L. -lA
CC -c main.cc
CC -o test main.o -L. -lB
Undefined first referenced
symbol in file
int A() main.o (symbol belongs to implicit
dependency ./libA.so)
ld: fatal: Symbol referencing errors. No output written to test
*** Error code 1
make: Fatal error: Command failed for target `test'
Whereas doing the same with GNU g++ on a Linux machine:
$ make CXX=g++ LD="g++ -shared"
g++ -c A.cc
g++ -shared -o libA.so A.o
g++ -c B.cc
g++ -shared -o libB.so B.o -L. -lA
g++ -c main.cc
g++ -o test main.o -L. -lB
Works fine, being the test executable dinamically linked against the two
libraries.
I don't know if these implicit dependencies should be tracked
automatically by the compiler (it seems to know where the dependency is
located, but refuses to link it). I think that adding boost_system to
the libraries needed by qpidd, regardless the compiler won't hurt. What
do you think?
Regards.
Re: Solaris port state
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2008-08-19 at 14:15 +0200, Manuel Teira wrote:
> I forgot to comment another weird issue I suffered:
>
> The first version of the solaris qpid::sys::SystemInfo::concurrency was
> just returning -1, as I was not sure about how to implement it for
> solaris, and the code in the common version was:
>
> long SystemInfo::concurrency() {
> #ifdef _SC_NPROCESSORS_ONLN // Linux specific.
> return sysconf(_SC_NPROCESSORS_ONLN);
> #else
> return -1;
> #endif
> }
>
> So, as it was marked as Linux specific, my first version was:
>
> long SystemInfo::concurrency() {
> return -1;
> }
>
> What I got using this version was a funny "Out of memory" error. The
> problem was actually in qpid::broker::Broker, that is using the
> concurrency() value to calculate the number of working threads, as:
>
> int c = sys::SystemInfo::concurrency();
> workerThreads=c+1;
>
> So, with concurrency returning -1, workerThreads equals 0, and later, in
> Broker::run()
>
>
> int numIOThreads = config.workerThreads;
> std::vector<Thread> t(numIOThreads-1);
>
> Leading to an attempt to create a vector of 0xffffffffffffffff entries
> in my 64 bits sparc executable.
>
> Later, I discovered that _SC_NPROCESSORS_ONLN also exists on Solaris (it
> seems it's actually posix compliant) and changed the solaris
> implementation, as part of the localaddrs patch. However, I think that
> perhaps the value of SystemInfo::concurrency() should be used more
> prudently or perhaps the value to return when an architecture has no way
> to provide the number of processors should be 1, as a safe value.
Yes, this is my stupid bug - I'd go with returning 1 if no better
estimate is available. Note this means on multi-cpu solaris boxes it
will be important to set --worker-threads manually to something
approximating the number of available cores to get good performance.
Sorry about that!
Re: Solaris port state
Posted by Manuel Teira <mt...@tid.es>.
I forgot to comment another weird issue I suffered:
The first version of the solaris qpid::sys::SystemInfo::concurrency was
just returning -1, as I was not sure about how to implement it for
solaris, and the code in the common version was:
long SystemInfo::concurrency() {
#ifdef _SC_NPROCESSORS_ONLN // Linux specific.
return sysconf(_SC_NPROCESSORS_ONLN);
#else
return -1;
#endif
}
So, as it was marked as Linux specific, my first version was:
long SystemInfo::concurrency() {
return -1;
}
What I got using this version was a funny "Out of memory" error. The
problem was actually in qpid::broker::Broker, that is using the
concurrency() value to calculate the number of working threads, as:
int c = sys::SystemInfo::concurrency();
workerThreads=c+1;
So, with concurrency returning -1, workerThreads equals 0, and later, in
Broker::run()
int numIOThreads = config.workerThreads;
std::vector<Thread> t(numIOThreads-1);
Leading to an attempt to create a vector of 0xffffffffffffffff entries
in my 64 bits sparc executable.
Later, I discovered that _SC_NPROCESSORS_ONLN also exists on Solaris (it
seems it's actually posix compliant) and changed the solaris
implementation, as part of the localaddrs patch. However, I think that
perhaps the value of SystemInfo::concurrency() should be used more
prudently or perhaps the value to return when an architecture has no way
to provide the number of processors should be 1, as a safe value.
Regards.
Re: Solaris port state
Posted by Manuel Teira <mt...@tid.es>.
Hello again. Just reusing this thread to update the status of the
solaris port:
I've committed a set of patches attached to the JIRA QPID-1198:
1.- syslog-feature-test.patch. Provide a feature-wise detection of
problematic syslog categories in qpid::log::Options. The checked
categories are LOG_AUTHPRIV and LOG_FTP, unexisting in Solaris.
2.- acl.patch. To take into account that the ACL API is included as
part of libc in Solaris, and provided as libacl in Linux.
3.- ecfpoller-refactoring.patch. Refactoring to honour the refactoring
Andrew made in rev 680395. The ugly Sun CC private inheritance
workaround is no longer needed!
4.- localaddrs.patch. Changes as suggested by Steve (many thanks!) to
provide system dependent local address calculations.
After this, and a pair of minor changes I've sent to Andrew, regarding
previously committed changes, there's only one little glitch avoiding a
clean solaris build. I'm asking for your advise with this issue:
I need to explicitly provide a -lboost_system to link qpidd. I don't
know if it's related with some solaris linker bug or feature, but even
when I provide a LD_LIBRARY_PATH with the boost libraries location, it
seems unable to find it. This is what the linker dumps out when no
-lboost_system is provided:
CC -g -m64 -I/opt/dslap/contrib/include -mt -mt -o .libs/qpidd qpidd.o
-L/opt/dslap/contrib/lib -L/usr/lib/openais -L/usr/lib64/openais
./.libs/libqpidbroker.so
/export/home/devel/ws/DSLAP/qpid/trunk/qpid/cpp/src/.libs/libqpidcommon.so
./.libs/libqpidcommon.so -lboost_program_options -lboost_filesystem
-luuid -library=stlport4 -R/opt/dslap/contrib/lib
ld: warning: file ./.libs/libqpidcommon.so: linked to
/export/home/devel/ws/DSLAP/qpid/trunk/qpid/cpp/src/.libs/libqpidcommon.so:
attempted multiple inclusion of file
Undefined first referenced
symbol in file
const boost::system::error_category&boost::system::get_posix_category()
qpidd.o (symbol belongs to implicit dependency
/opt/dslap/contrib/lib/libboost_system.so)
const boost::system::error_category&boost::system::get_system_category()
qpidd.o (symbol belongs to implicit dependency
/opt/dslap/contrib/lib/libboost_system.so)
ld: fatal: Symbol referencing errors. No output written to .libs/qpidd
Annoying, because it knows where the library is! The only woraround I
found was to explicitly provide it as a linker argument, with
-lboost_system. Perhaps the problem could be that the library is used
directly from qpidd.cpp source code, and not indirectly through
libboost_filesystem?
Any idea?
Regards.
Manuel.
RE: Solaris port state
Posted by Alan Conway <ac...@redhat.com>.
On Fri, 2008-07-18 at 15:37 -0400, Andrew Stitcher wrote:
> On Fri, 2008-07-18 at 13:55 -0400, Steve Huston wrote:
> > Hi folks,
> >
> > Some ideas related to logging - I'd like some direction/feedback...
[snip]
> As above I don't think documentation difficulty should stop us from
> taking advantage of the native platform features at this level. If it
> turns out to be very confusing to users we'll have to investigate ways
> to make common use cases the default or use similar options on each
> platform which abstract away the platform differences in some way.
>
> >
> > Ideas? I can begin working this out this afternoon if I get some
> > feedback...
>
>
> Give it a go!
+1. We generate the --help message at run time so it's always correct
for the platform. We generate the man page from qpidd --help so it's
fine too. Might want to generalize the generation mechanism (which is
currently specific to man pages) for other forms of doc, e.g. qpid
--help to XML, XML to whatever you like.
RE: Solaris port state
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2008-07-18 at 13:55 -0400, Steve Huston wrote:
> Hi folks,
>
> Some ideas related to logging - I'd like some direction/feedback...
>
> > > 3.- Solaris doesn't define the FTP and LOG_FTP syslog
> > > categories. Fixed with a #ifdef/#ifndef clause.
> >
> > Right... I am looking at this area today wrt Windows since Windows
> has
> > none of this stuff and I fear it's creeped too far into
> > platform-agnostic code. I'll send another email on this later.
>
> It seems that the portability problems in the logging area are
> primarily related to syslog, particularly in:
>
> - Specifying options to configure logging
> - Logging sink to syslog
>
> I think I can see a way to remedy both, and I'm hoping for some input.
>
> Options... If I read the code correctly, qpid::log::Options inherits
> from qpid::Options. Qpid::log::Options adds a bunch of available
> options, most of which are portable and the syslog-related ones, which
> are not. Might it be possible to add another layer, such as
> qpid::log::posix::Options, qpid::log::windows::Options, etc. that
> inherit from qpid::log::Options? Then move the syslog options setup to
> the posix::Options, and add Windows ones to that area.
>
> Logging... The SyslogOutput struct could be moved to a posix-specific
> area, maybe qpid/log/posix?
I think the approach you've outlined here is about the correct platform
specific/platform independent split for logging.
Given that the Windows/Unix system logging components are so different I
don't think you could sensibly try to make them look similar.
>
> This presents a bit of a challenge to documentation since there would
> then be some options that only work for Linux/Solaris/etc. and some
> that only work for Windows. But that's unavoidable if the full range
> of options remains available, and I think it's a good idea for them to
> remain.
As above I don't think documentation difficulty should stop us from
taking advantage of the native platform features at this level. If it
turns out to be very confusing to users we'll have to investigate ways
to make common use cases the default or use similar options on each
platform which abstract away the platform differences in some way.
>
> Ideas? I can begin working this out this afternoon if I get some
> feedback...
Give it a go!
Andrew
RE: Solaris port state
Posted by Steve Huston <sh...@riverace.com>.
Hi folks,
Some ideas related to logging - I'd like some direction/feedback...
> > 3.- Solaris doesn't define the FTP and LOG_FTP syslog
> > categories. Fixed with a #ifdef/#ifndef clause.
>
> Right... I am looking at this area today wrt Windows since Windows
has
> none of this stuff and I fear it's creeped too far into
> platform-agnostic code. I'll send another email on this later.
It seems that the portability problems in the logging area are
primarily related to syslog, particularly in:
- Specifying options to configure logging
- Logging sink to syslog
I think I can see a way to remedy both, and I'm hoping for some input.
Options... If I read the code correctly, qpid::log::Options inherits
from qpid::Options. Qpid::log::Options adds a bunch of available
options, most of which are portable and the syslog-related ones, which
are not. Might it be possible to add another layer, such as
qpid::log::posix::Options, qpid::log::windows::Options, etc. that
inherit from qpid::log::Options? Then move the syslog options setup to
the posix::Options, and add Windows ones to that area.
Logging... The SyslogOutput struct could be moved to a posix-specific
area, maybe qpid/log/posix?
This presents a bit of a challenge to documentation since there would
then be some options that only work for Linux/Solaris/etc. and some
that only work for Windows. But that's unavoidable if the full range
of options remains available, and I think it's a good idea for them to
remain.
Ideas? I can begin working this out this afternoon if I get some
feedback...
Thanks,
-Steve
RE: Solaris port state
Posted by Steve Huston <sh...@riverace.com>.
Hi Manuel,
> 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.
Congratulations! You win the first completed port prize :-)
I have no authority to say how to do the rest of the integration, but
I have some comments based on the ongoing Windows work and past
experience with porting a codebase to many platforms.
> 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.
Probably you're right.
> 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);
In the Windows port, this function ends up in its own file
qpid/sys/posix/StrError.cpp (because Windows requires a different
implementation all together). You could put yours in
qpid/sys/solaris/StrError.cpp after the Windows patches with the
split, or do the split now in your workspace.
> 2.2. - pthread_yield is not POSIX compliant. Using sched_yield
for
> the Solaris version, with a #ifdef/#ifndef clause.
Right... You could copy the Thread implementation to solaris and
reimplement with a different yield... This is the sort of approach
Andrew urged me to follow with Windows - copy and change/reimplement
rather than add ifdefs.
> 3.- Solaris doesn't define the FTP and LOG_FTP syslog
> categories. Fixed with a #ifdef/#ifndef clause.
Right... I am looking at this area today wrt Windows since Windows has
none of this stuff and I fear it's creeped too far into
platform-agnostic code. I'll send another email on this later.
> 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).
But that's probably the best you can do to work around a compiler
issue.
> 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
Right - this is another one that's copied and reimplemented for
Windows, so if you need to copy and reimplement for solaris, it's not
without precedent.
This is a situation, though, where some autoconf feature tests can
detect which is needed and set the config appropriately. Then you'd
ifdef based oin the feature test rather than a platform/compiler
feature.
> 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.
Ok.
> 7.- Replace all the u_intN_t typenames with uintN_t typenames. The
> former ones are not available on solaris.
Right - this is being done in the Windows port as well.
> 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?
The only alternative here is to change the name to something other
than queue... This problem will come back in other ports.
> That's all, I think. Comments about the issues and the way
> the've been fixed are welcomed.
Very nice.
One issue that will keep coming up as more ports are worked on is
issues similar to sched_yield and uuid above... Very minor differences
in platforms or arguments or standards implementations that really
don't warrant reimplementing code. I'd urge some more usage of
autoconf feature tests to work these out at build time. I definitely
hear Andrew's sentiment that once ifdefs are "ok" they spread like
wildfire. The danger in copy/reimplement, however, is also real - the
more copies of code there are, the easier it is for them to get out of
sync - maintenance becomes harder and harder. There should be a
balance between these approaches. Fortunately, the qpid dev team is
alert, attentive, and able to review changes that come in so they can
watch for excesses in either direction.
> Proudly attaching a console output of the 'make check' command:
Wonderful - congratulations!
-Steve