[Resolved] [svn 1818] error from PTHREAD_MUTEX_NORMAL

[hunterk]

Hi, I'm compiling on Ubuntu 8.10 64-bit and I've started running into this error using svn version 1818:

Code: Select all

hb.c: In function 'hb_get_preview':
hb.c:358: warning: ignoring return value of 'fread', declared with attribute warn_unused_result
hb.c: In function 'hb_detect_comb':
hb.c:454: warning: unused variable 'flag'
Cc ports.o
echo cc -I../contrib/include -D__LIBHB__ -DUSE_PTHREAD -DSYS_LINUX  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -O3 -funroll-loops
cc -I../contrib/include -D__LIBHB__ -DUSE_PTHREAD -DSYS_LINUX -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -O3 -funroll-loops
ports.c: In function 'hb_lock_init':
ports.c:415: warning: implicit declaration of function 'pthread_mutexattr_settype'
ports.c:415: error:'PTHREAD_MUTEX_NORMAL' undeclared (first use in this function)
ports.c:415: error: (Each undeclared identifier is reported only once
ports.c:415: error: for each function it appears in.)
Compile line for ports.o was:
cc -I../contrib/include -D__LIBHB__ -DUSE_PTHREAD -DSYS_LINUX -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -O3 -funroll-loops -o ports.o -c ports.c
make[1]: *** [ports.o] Error 1
make: *** [libhb/libhb.a] Error 2

I've compiled from SVN plenty of times, so I don't think it's a problem on my end. However, I noticed that commit 1817 was a change to the way pthread mutex was handled, so I thought this problem could be related.

[jbrjake]

All of that stuff is defined in pthread.h which your system should certainly have.

[hunterk]

hey, thanks for the quick reply jbrjake.

I indeed have it, located at /usr/include/pthread.h, so I'm not sure why there would be a problem here. Any thoughts?

Also, if you could tell me how to check out an earlier version (e.g., 1816), I could verify whether this commit is what broke it for me.

[rhester]

svn -r 1816 co svn://svn.handbrake.fr/HandBrake/trunk HandBrake-r1816

Rodney

[hunterk]

Thanks for the info Rodney!

I was able to compile 1816 with no trouble, but 1817 failed with the same error as 1818, so I can confirm that it was this commit that broke it for me. Let me know if you guys need any more info, or if there's anything else I can do to help (other than writing actual code ).

btw, there have been some pretty great improvements checked-in lately, and it just keeps getting better. It looks like 0.9.3 is going to be a big step up from the last release! keep up the good work!

[maestro371]

Same problem here on Debian Etch with 1819. I'll root around a bit and see if I can find anything.

Code: Select all

Cc ports.o
echo cc -I../contrib/include -D__LIBHB__ -DUSE_PTHREAD -DSYS_LINUX  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -O3 -funroll-loops
cc -I../contrib/include -D__LIBHB__ -DUSE_PTHREAD -DSYS_LINUX -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -O3 -funroll-loops
ports.c: In function 'hb_lock_init':
ports.c:415: warning: implicit declaration of function 'pthread_mutexattr_settype'
ports.c:415: error: 'PTHREAD_MUTEX_NORMAL' undeclared (first use in this function)
ports.c:415: error: (Each undeclared identifier is reported only once
ports.c:415: error: for each function it appears in.)
Compile line for ports.o was:
cc -I../contrib/include -D__LIBHB__ -DUSE_PTHREAD -DSYS_LINUX -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -g -O3 -funroll-loops -o ports.o -c ports.c
make[1]: *** [ports.o] Error 1
make: *** [libhb/libhb.a] Error 2

[maestro371]

Okay, it seems that PTHREAD_MUTEX_NORMAL is set conditionally upon __USE_UNIX98 being set:

From /usr/include/pthread.h

Code: Select all

#ifdef __USE_UNIX98
  ,
  PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_TIMED_NP,
  PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
  PTHREAD_MUTEX_ERRORCHECK = PTHREAD_MUTEX_ERRORCHECK_NP,
  PTHREAD_MUTEX_DEFAULT = PTHREAD_MUTEX_NORMAL
#endif

It appears that whatever that flag (UNIX98) is, it's not set. When I comment the ifdef clause out of pthread.h, HB seems to compile that portion of libhb and is able to complete the overall compilation. I can't imagine that commenting out lines in system headers is a good thing, though.

[maestro371]

Fixed in 1824. Rock on.

Thanks!