qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: qpid (cpp) on solaris + Sun Studio 12
Date Mon, 26 May 2008 12:59:11 GMT
Manuel Teira wrote:
> Hello again. First of all, thanks for all your kind responses and 
> suggestions in my "Greetings and questions" post. I could have answered 
> to that post, but I thought that opening a more explicit thread would be 
> helpful for people searching for information about this topic.
> 
> About the lacking of epoll interface in Solaris, I'm planning an 
> implementation of qpid::sys::Poller based on the Solaris 10 Event 
> Completion Framework 
> (http://developers.sun.com/solaris/articles/event_completion.html).
> 
Cool, will be nice to see it. The intended model is to implement your stuff in a 
src/qpid/sys/solaris directory and add the #ifdefs to select it appropriately.

> Other than that issue, I've found the following  startup ones. I've 
> applied some dirty hacks for some of the problems, and would like to 
> hear about suggestions for a better way to fix them, in a way that could 
> be helpful for everybody:
> 
> 1.-Incompatibility with autoconf 2.62. I will have to check again what 
> the error was. I solved it just downgrading autoconf version to 2.60. 
> Unfortunately, I didn't register the exact error, but if you're 
> interested, I can install again the 2.62 version to reproduce it.

I *hate* autoconf. Hate, hate, hate it. Causes us more grief than everything 
else put together. Sigh.

If you figure out the solution I'd love a patch. Otherwise please pass on the 
info, but if you have a workaround for now then it may not be top priority to fix.

> 2.-Uuid.h problems caused by what I think is a buggy solaris uuid.h 
> header. Problems are caused by these interface functions, declared as:
> 
> extern void uuid_copy(uuid_t, uuid_t);
> extern int uuid_is_null(uuid_t);
> 
> in solaris bundled /usr/include/uuid/uuid.h
> 
> The second argument in uuid_copy and the only one in uuid_is_null are 
> const in the linux implementation (and that's the right way to do it, I 
> think). As a fast hack, I've const casted the arguments for the 
> offending calls in cpp/src/qpid/framing/Uuid.h, as noted in the 
> following diff:
> 
> -bash-3.00$ svn diff qpid/framing/Uuid.h
> Index: qpid/framing/Uuid.h
> ===================================================================
> --- qpid/framing/Uuid.h (revision 659071)
> +++ qpid/framing/Uuid.h (working copy)
> @@ -45,7 +45,7 @@
>     Uuid(const uint8_t* data) { assign(data); }
> 
>     /** Copy from 16 bytes of data. */
> -    void assign(const uint8_t* data) { uuid_copy(c_array(), data); }
> +    void assign(const uint8_t* data) { uuid_copy(c_array(), 
> const_cast<uint8_t*>(data)); }
>        /** Set to a new unique identifier. */
>     void generate() { uuid_generate(c_array()); }
> @@ -54,7 +54,7 @@
>     void clear() { uuid_clear(c_array()); }
>        /** Test for null (all zeros). */
> -    bool isNull() const { return uuid_is_null(data()); }
> +    bool isNull() const { return 
> uuid_is_null(const_cast<uint8_t*>(data())); }
> 
>     // Default op= and copy ctor are fine.
>     // boost::array gives us ==, < etc.
> 
> Of course, this is just a nasty hack. What is the recommended way to 
> deal with this kind of API annoyances?

The fixes above are not so bad as they don't change the API for anyone else.

In general all the big platform differences should be gathered together in 
src/qpid/sys/solaris header files that can be #ifdef included. That way we keep 
the platform specifics together in one recognizable place.

> 3.- It seems to me that this statement in qpid/framing/Blob.h is no 
> longer true:
> 
> 
> /** 0-arg in_place<T>() function, missing from boost. */
> template<class T>
> typed_in_place_factory0<T> in_place() { return 
> typed_in_place_factory0<T>(); }
> 
> 
> As I'm getting a lot of overloading ambiguities while compiling 
> gen/qpid/framing/BodyHolder_gen.cpp:
[snip]
> Same error repeated for all the in_place calls. This is happening using 
> boost 1.35.0
> 
> I'm just guessing that the in_place<T>() is no longer missing from 
> boost, because the header is a macro-hell, and my brain coredumped after 
> a fast review.

Boost trips us up almost as often as autoconf (but I don't hate boost :)
Try putting this around my 0-arg hack:
#if (BOOST_VERSION < 103500)

> Is there any way to force regeneration of the ruby generated sources? 

rm src/rubygen.mk

> I've deleted BodyHolder_gen.cpp to make some tests, and running make 
> again doesn't seem to regenerate the missing sources, neither a 'make 
> clean' at the cpp directory does.
> 
That's broken, deleting a generated source should most definitely cause rubygen 
to re-run. I'm seeing the same thing so I'll sort it out ASAP.

Cheers,
Alan.

Mime
View raw message