I think that's the best solution for now. APR doesn't actually needOn Tue, Oct 18, 2011 at 9:26 AM, Oscar Pernas <firstname.lastname@example.org> wrote:
> Hi all,
> I'm using apr in a process that uses CORBA TAO, for communications. My
> problem is that TAO and APR has the same redefinition of a variable.
> In apr.h i can see:
> typedef int uid_t ;
> typedef int pid_t;
> typedef int gid_t;
> However in TAO I could see:
> typedef long uid_t
> typedef long pid_t
> Im in Win32 and Win64 platform. I've commented it in apr source and library
> compiles well, Could I have any problem? What would be the best solution?
to define uid_t for its own purposes.
That general issue -- defining Unix types -- should be be fixed in the
next major (i.e., not binary compatible) release. In cases other than
uid_t there may be other fallout to handle. For example, apr_proc_t
uses (requires) pid_t.
According to our API compatibility rules, something equivalent to
typedef whatever uid_t
could be provided with apr 1.5.x. That would be worthwhile if the fix
could be near-complete. (I dunno the complete fallout.)