[Top][All Lists]
[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 !!!