2009/9/13 Ion Gaztaņaga <igaztanaga@gmail.com>
>From the gdb output you sent, I can't deduce why is falling in HPUX, because sem_open is failing but I can't see the errno value and that errno is not a value that can be translated to standardized interprocess values. Let's see if the value of errno after sem_open fails can give us any hint.
In that gdb output, you can see I've printed out the errno value: 22 (EINVAL) . As for the fact that gdb can't show stack variables, can you give me a hint for a possible cause? As I told you, now I'm using the latest available version of gdb for HPUX. The platform linker is being used (not gnu linker) and the only additional flags I've passed to bjam were: cxxflags=-mlp64 linkflags=-mlp64.
I don't know how much you're interested that boost.interprocess supports HPUX platforms, if at all. I you think it would be useful, I could provide you a VPN access to the HPUX host, so that you could check for your self what's happening.
Regarding the atomic library, it's beyond my skills to port it properly and requires a support that I can't provide. If you feel confident you can port it and fill the few functions needed in interprocess/detail/atomic.hpp to support aCC,
I'm afraid my experience doesn't allow me to accomplish such a task, I'm sorry. Maybe someone else in the mailing list could have the knowledge to do it.
supposing aCC is C++ standard compliant enough to compler the rest of interprocess and its dependencies.
I think it is. At least Boost.thread builds correctly with aCC.
Thank you very much for your help.