* 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.