What I describe as "minor" fixes are adding imports or tweaking #ifdefs so that the posix branch is taken (defined __sun instead of __unix__). There are no changes related to locking or threads, the pthreads API is used for this in the same way as on linux. From what I can see in the documentation, there are no differences in the API for the calls which are made on both systems. In particular, the mutex should be recursive in the same way as on linux.
I also created a dummy implementation of SystemInfo::getInterfaceAddresses and SystemInfo::getInterfaceNames based on the posix implementation (<ifaddrs.h> is not available on my platform). Do you think this could be related to the issue? My analysis did not show any calls to this code in the failing test test. For reference, the platform I am testing on is SunStudio 12.4 on Solaris 10u10. I am also using stlport4. Thanks for your help On Fri, Apr 8, 2016 at 4:49 PM, Andrew Stitcher <[email protected]> wrote: > On Fri, 2016-04-08 at 11:58 +0200, Alexandre Trufanow wrote: > > Hi, > > > > I am trying to run QPID on solaris using sun studio and have managed > > to get > > the broker to compile with a few minor fixes. Unfortunately many unit > > tests > > are blocking. > > Could you tell us what the "minor fixes" are? I suspect they may be > relevant to the issue. > > Also it may be relevant to give a few more details about your > environment: Which Solaris version on what architecture? With exactly > which version of the compiler? In this case I doubt that will give a > whole lot more info, but in general it helps. > > One potential problem that comes to mind that could cause this sort of > issue: Did you implement Mutex yourself? For some irritating reasons, > Mutex must be a recursive mutex not a regular mutex, and making it a > regular mutex will cause some parts of the code base to deadlock. > > It has been a long time since I tried to compile qpid on Solaris so > that's about the limit of my memory. > > Solaris is a very lightly test platform unfortunately so you may be > largely on your own. > > Good luck, > > Andrew > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
