All of lore.kernel.org
 help / color / mirror / Atom feed
* Strange header file error
@ 2008-07-14 19:58 E Robertson
  2008-07-15  2:06 ` Khem Raj
  0 siblings, 1 reply; 5+ messages in thread
From: E Robertson @ 2008-07-14 19:58 UTC (permalink / raw)
  To: openembedded-devel

Hi All,
I'm trying to explain this pthread.h header file error.
I include this header file in my program. The snip of interest is this:

#ifndef _PTHREAD_H
#define _PTHREAD_H  1

#include <features.h>

#include <sched.h>
#include <time.h>

#define __need_sigset_t
#include <signal.h>
#include <bits/pthreadtypes.h>
#include <bits/initspin.h>

__BEGIN_DECLS

/* Initializers.  */

#define PTHREAD_MUTEX_INITIALIZER \
  {0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, __LOCK_INITIALIZER}
#ifdef __USE_GNU
# define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
  {0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, __LOCK_INITIALIZER}
# define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
  {0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, __LOCK_INITIALIZER}
# define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
  {0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, __LOCK_INITIALIZER}
#endif


This is included in another header file where I place some #ifdef
statements for  _PTHREAD_H,
PTHREAD_MUTEX_INITIALIZER, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, and
__USE_GNU.
I also defined __USE_GNU just before the header file and none of these
are redefined anywhere else.

From this I notice all these defines are valid and present _except_
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP.
I haven't figured out why this is so wired I don't see any possible
reason how this could be possible.
Am I out of my mind here? Is this really possible? Unless my
arm-uclibc is doing something strange, I don't see how this could be.
Anyone seen this before?  Thanks much.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Strange header file error
  2008-07-14 19:58 Strange header file error E Robertson
@ 2008-07-15  2:06 ` Khem Raj
  2008-07-15 15:06   ` E Robertson
  0 siblings, 1 reply; 5+ messages in thread
From: Khem Raj @ 2008-07-15  2:06 UTC (permalink / raw)
  To: openembedded-devel; +Cc: openembedded-devel



On Mon, 2008-07-14 at 14:58 -0500, E Robertson wrote:
> Hi All,
> I'm trying to explain this pthread.h header file error.
> I include this header file in my program. The snip of interest is this:
> 
> #ifndef _PTHREAD_H
> #define _PTHREAD_H  1
> 
> #include <features.h>
> 
> #include <sched.h>
> #include <time.h>
> 
> #define __need_sigset_t
> #include <signal.h>
> #include <bits/pthreadtypes.h>
> #include <bits/initspin.h>
> 
> __BEGIN_DECLS
> 
> /* Initializers.  */
> 
> #define PTHREAD_MUTEX_INITIALIZER \
>   {0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, __LOCK_INITIALIZER}
> #ifdef __USE_GNU
> # define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
>   {0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, __LOCK_INITIALIZER}
> # define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
>   {0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, __LOCK_INITIALIZER}
> # define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
>   {0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, __LOCK_INITIALIZER}
> #endif
> 
> 
> This is included in another header file where I place some #ifdef
> statements for  _PTHREAD_H,
> PTHREAD_MUTEX_INITIALIZER, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, and
> __USE_GNU.
> I also defined __USE_GNU just before the header file and none of these
> are redefined anywhere else.
> 
> >From this I notice all these defines are valid and present _except_
> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP.
> I haven't figured out why this is so wired I don't see any possible
> reason how this could be possible.
> Am I out of my mind here? Is this really possible? Unless my
> arm-uclibc is doing something strange, I don't see how this could be.
> Anyone seen this before?  Thanks much.
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel




Its not clear from your email what you might be facing. You can
preprocess your source file with -E and see whats getting included

what happens when you use  -D_GNU_SOURCE ?

Thx

-Khem




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Strange header file error
  2008-07-15  2:06 ` Khem Raj
@ 2008-07-15 15:06   ` E Robertson
  2008-07-15 15:22     ` Khem Raj
  0 siblings, 1 reply; 5+ messages in thread
From: E Robertson @ 2008-07-15 15:06 UTC (permalink / raw)
  To: openembedded-devel; +Cc: openembedded-devel

On Mon, Jul 14, 2008 at 9:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>
> On Mon, 2008-07-14 at 14:58 -0500, E Robertson wrote:
>> Hi All,
>> I'm trying to explain this pthread.h header file error.
>> I include this header file in my program. The snip of interest is this:
>>
>> #ifndef _PTHREAD_H
>> #define _PTHREAD_H  1
>>
>> #include <features.h>
>>
>> #include <sched.h>
>> #include <time.h>
>>
>> #define __need_sigset_t
>> #include <signal.h>
>> #include <bits/pthreadtypes.h>
>> #include <bits/initspin.h>
>>
>> __BEGIN_DECLS
>>
>> /* Initializers.  */
>>
>> #define PTHREAD_MUTEX_INITIALIZER \
>>   {0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, __LOCK_INITIALIZER}
>> #ifdef __USE_GNU
>> # define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
>>   {0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, __LOCK_INITIALIZER}
>> # define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
>>   {0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, __LOCK_INITIALIZER}
>> # define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
>>   {0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, __LOCK_INITIALIZER}
>> #endif
>>
>>
>> This is included in another header file where I place some #ifdef
>> statements for  _PTHREAD_H,
>> PTHREAD_MUTEX_INITIALIZER, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, and
>> __USE_GNU.
>> I also defined __USE_GNU just before the header file and none of these
>> are redefined anywhere else.
>>
>> >From this I notice all these defines are valid and present _except_
>> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP.
>> I haven't figured out why this is so wired I don't see any possible
>> reason how this could be possible.
>> Am I out of my mind here? Is this really possible? Unless my
>> arm-uclibc is doing something strange, I don't see how this could be.
>> Anyone seen this before?  Thanks much.
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
>
>
> Its not clear from your email what you might be facing. You can
> preprocess your source file with -E and see whats getting included
>
> what happens when you use  -D_GNU_SOURCE ?

I've always used -D_GNU_SOURCE to get around the problem but "why?" is
the question I'm trying to answer.
Clearly USE_GNU is defined so the only way I can try to determine
problem is to dig deeper.
I must point out however that if I use I define _GNU_SOURCE just
before the pthread.h header file is included
I get the same result (as oppose to -D_GNU_SOURCE in the cc path).

I tried the -E option and it appears that all the necessary files are
included. I don't see anything unusual.
These are the header files included:
/opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/stdio.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/features.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/uClibc_config.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/uClibc_arch_features.h
\
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/sys/cdefs.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/types.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/wordsize.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/kernel_types.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/typesizes.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/pthreadtypes.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/sched.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/uClibc_stdio.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/wchar.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/wchar.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/uClibc_mutex.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/pthread.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/sched.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/time.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/time.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/uClibc_clk_tck.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/signal.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/sigset.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/initspin.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/sigthread.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/uClibc_pthread.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/stdio_lim.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/stdlib.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/sys/types.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/endian.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/endian.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/sys/select.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/select.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/sys/sysmacros.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/alloca.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/signum.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/siginfo.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/sigaction.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/sigcontext.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/asm/sigcontext.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/sigstack.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/string.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/errno.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/errno.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/errno_values.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/unistd.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/posix_opt.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/confname.h \
  /opt/OE/stuff/tmp/staging/arm-linux-uclibc/usr/include/bits/getopt.h

Thanks.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Strange header file error
  2008-07-15 15:06   ` E Robertson
@ 2008-07-15 15:22     ` Khem Raj
  2008-07-15 16:08       ` E Robertson
  0 siblings, 1 reply; 5+ messages in thread
From: Khem Raj @ 2008-07-15 15:22 UTC (permalink / raw)
  To: openembedded-devel; +Cc: openembedded-devel

On Tue, 2008-07-15 at 10:06 -0500, E Robertson wrote:

> > Its not clear from your email what you might be facing. You can
> > preprocess your source file with -E and see whats getting included
> >
> > what happens when you use  -D_GNU_SOURCE ?
> 
> I've always used -D_GNU_SOURCE to get around the problem but "why?" is
> the question I'm trying to answer.

These are Non Posix noticed (_NP) ? thats why you need _GNU_SOURCE which
tells compiler that you want this code.

> Clearly USE_GNU is defined so the only way I can try to determine
> problem is to dig deeper.

Can you formulate the problem once again

> I must point out however that if I use I define _GNU_SOURCE just
> before the pthread.h header file is included
> I get the same result (as oppose to -D_GNU_SOURCE in the cc path).

having this define on GCC commandline is correct thing to do.
> 
> I tried the -E option and it appears that all the necessary files are
> included. I don't see anything unusual.

Khem




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Strange header file error
  2008-07-15 15:22     ` Khem Raj
@ 2008-07-15 16:08       ` E Robertson
  0 siblings, 0 replies; 5+ messages in thread
From: E Robertson @ 2008-07-15 16:08 UTC (permalink / raw)
  To: openembedded-devel

On Tue, Jul 15, 2008 at 10:22 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, 2008-07-15 at 10:06 -0500, E Robertson wrote:
>
>> > Its not clear from your email what you might be facing. You can
>> > preprocess your source file with -E and see whats getting included
>> >
>> > what happens when you use  -D_GNU_SOURCE ?
>>
>> I've always used -D_GNU_SOURCE to get around the problem but "why?" is
>> the question I'm trying to answer.
>
> These are Non Posix noticed (_NP) ? thats why you need _GNU_SOURCE which
> tells compiler that you want this code.
>
>> Clearly USE_GNU is defined so the only way I can try to determine
>> problem is to dig deeper.
>
> Can you formulate the problem once again

Sure.
I got the error 'PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP' undeclared
from src/nanox/srvmain.c
when compiling the microwindow source. For threadsafe support,
pthread.h is needed which is included
in lock.h. Here is also where USE_GNU is defined so as to include the
thread _NP.
In any case in this file (lock.h) I added several directives similar to this one
#ifndef __USE_GNU
#error USE_GNU not defines
#endif
I this this for the _NPs as well, before and after the include. It's a
bit crude but it works.
I noticed __USE_GNU was defined before and after the pthread.h is
included but not inside pthread.h (edited for #ifdef).
as a result the _NPs are not defined.

Now this sort of make sense because #include <features.h> undefined
__USE_GNU and if __GNU_SOURCE is not defined
then __USE_GNU will remain undefined. In such a case the the __USE_GNU
should not be defined after the header file, correct?
This behaviour is consistent because if I define _GNU_SOURCE also
before the pthread.h is defined but it did not have any effect.

Thanks.

>> I must point out however that if I use I define _GNU_SOURCE just
>> before the pthread.h header file is included
>> I get the same result (as oppose to -D_GNU_SOURCE in the cc path).
>
> having this define on GCC commandline is correct thing to do.
>>
>> I tried the -E option and it appears that all the necessary files are
>> included. I don't see anything unusual.
>
> Khem
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-07-15 16:09 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-14 19:58 Strange header file error E Robertson
2008-07-15  2:06 ` Khem Raj
2008-07-15 15:06   ` E Robertson
2008-07-15 15:22     ` Khem Raj
2008-07-15 16:08       ` E Robertson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.