On Tue, Jan 22, 2002 at 03:36:01PM -0800, Justin Erenkrantz wrote: > On Tue, Jan 22, 2002 at 11:02:39AM -0800, Aaron Bannert wrote: > > This patch is verified to work on AIX 4.2.1, but it was suggested > > to me by the reporter (Elrond <[EMAIL PROTECTED]>) that we do > > the same for other platforms for things like _REENTRANT and I > > agree. Does anyone see a reason not to do this? > > I think there are some platforms that will do bad things when > _REENTRANT is defined for some libraries and not for others. > I think it's best to always define that wherever possible. > (AIX brain damage excluded.)
That would be a valid concern, but I don't think we need to worry about system libraries (since they've already been compiled and _REENTRANT is a preprocessor directive). The worry is with _REENTRANT apps that link against a non-_REENTRANT APR and vice-versa. To be fair, this isn't a braindead AIX, this is simply an AIX that does not have thread support AFAIK. The main point here is that if APR is configured with --disable-threads, we shouldn't be enabling threaded or reentrant versions of libs unless we intend to use that feature of the library. APR is currently broken on that particular version of AIX. > > installations of APR in threaded and non-threaded modes. Will we > > eventually go to the libapr.so and libapr_r.so modes? > > I don't like this approach. The reason you would do it for libc > and libc_r is that the codebase is completely separate. Our code > is unified and we'd require a two-pass compilation system. I'm > not sure I'd like that. We'd need to think long and hard before > splitting it out like that. -- justin I wasn't proposing this as a solution, since I don't like it either, but for the moment I don't know where the group stands on this issue. We don't really have a reentrant and a non-reentrant version of APR, per the definition. What we have is a mismatch between APR-supported platforms that have threads and those that don't. -aaron
