bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compile failure


From: Alain Magloire
Subject: Re: Compile failure
Date: Wed, 13 Dec 2000 13:44:15 -0500 (EST)

> 
> On Wed, Dec 13, 2000 at 12:32:58PM -0500, Alain Magloire wrote:
> 
> > You are right, it will clash everywhere I do a
> > #ifdef HAVE_PTHREAD_H
> > #  define __USE_UNIX98
> > #  include <pthread.h>
> > #endif
> 
> Should the configure test to see is __USE_UNIX98 is ok?

__USE_UNIX98 is GNU Lib C thing, so indeed I should not use it.
The good way to do it is probably to a configure check
AC_CHECK_FUNC (pthread_rwlock_init()) or something close
with more intelligence.

> > > I added a flag to configure to handle this.  It seems to send some other 
> > > things funny though, so I'll look at that later.  (./configure 
> > > --disable-pthread)
> > 
> > Ok, I see what you're doing.  Actually the default should rather
> > be to not compile with Threading support but to allow it when passing
> > --with-pthread.  IMO it should be the opposite, but many OSes seem not
> > to have a good POSIX threading package.
> 
> Do you know of any tradition to follow from other packages?  If we're 
> going to require a flag to get all of the functionality, it should be 
> the same everywhere.

gcc for example use those bits:
AC_ARG_ENABLE(threads,
[  --enable-threads        enable thread usage for target GCC.
  --enable-threads=LIB    use LIB thread package for target GCC.],
if test x$enable_threads = xno; then
        enable_threads=''
fi,
enable_threads='')

--enable-threads.   But I got no intention in providing support
other then POSIX pthreads,  So instead of --with-thread, I can go
--enable-threads where enable means pthread and a check will
be done to see if the pthread functions are in libc.so are in a
separate thread usually libpthread.so(Solaris).

The question is: should --enable-thread be the default ?

> > 
> > I see if I can clear this out tonight.
> 
> Okay.  If there's something you need, let me know.

okdoke, I'll ping again for a recompile/test after the changes.

> > > These errors in the pthread.h start right after:
> > > 
> > > #ifdef __USE_UNIX98
> > > /* Functions for handling read-write locks.  */
> > 
> > This looks like a bug in the include files<pthread.h>, the idea was to let
> > one pick different namespaces(implementations) there was a lot of
> > noise in the glibc list about this and that it was a bad thing.
> 
> Do you want me to do anything on this?

I'm not sure, meaning I do not know if this a bug in your snapshot glibc
or a illegal use of __USE_UNIX98.  Here is a simple test
does it fail ? when compiling with -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations

meaning I want to see if the pthread_rwlock* declarations are available.
-------------------------------------------
/* We need to get the unix98 rwlock declarations.  */
#define __USE_UNIX98
#include <pthread.h>
#include <stdio.h>

int
main ()
{
    pthread_rwlock_t rwlock;
    int status = pthread_rwlock_init (&rwlock, NULL);
    if (status != 0)
        fprintf (stderr, "rwlock_init failed: %s\n", strerror (status));
    return 0;
}
-------------------------------------------


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]