This is interesting... I wrote codes that use PLPA and I include these three headers in following order:

#include <pthread.h>
#include <sched.h>
#include "plpa.h"

and got no problems compiling at all. I use PLPA 1.3 and gcc 4.3.2 on Linux.

I looked deeper in the plpa.h and saw that it actually renames "cpu_set_t" to "plpa_cpu_set_t" using the PLPA_NAME() macro. plpa.h line 116 reads:

typedef struct { PLPA_NAME(bitmask_t) bitmask[PLPA_BITMASK_NUM_ELEMENTS]; } PLPA_NAME(cpu_set_t);

Which declares papi_cpu_set_t, but not cpu_set_t. In fact, for the very same reason I must use the following block to suppress PLPA on systems which this library is not installed:

#ifdef SUPPRESS_PLPA
 #define plpa_cpu_set_t  cpu_set_t
 #define plpa_sched_setaffinity  sched_setaffinity 
 #define plpa_sched_getaffinity  sched_getaffinity 
 #define PLPA_CPU_ZERO  CPU_ZERO 
 #define PLPA_CPU_SET  CPU_SET 
 #define PLPA_CPU_CLR  CPU_CLR 
 #define PLPA_CPU_ISSET  CPU_ISSET 
#else
 #include "plpa.h"
#endif

And always use plpa_ extension throughout the code.

And you can always check the final code generated by GCC's preprocessor using the -E flag and make sure that PLPA_NAME() works correctly for you. I hope this helps!...

A note to Jeff and all other HWLOC developers: hwloc is a dream came true, thank you for your great work! I particularly enjoyed the lstopo utility and the ability to drill down in memory hierarchies at runtime!! (could we do that with PLPA? Maybe but I am not sure). Hwloc helped me realize the interleaved processor enumeration on NUMA architectures (0-2-4-6 goes on socket 0, for example). Looks like I was using an incorrect CPU affinity before, which hurts the performance a lot. Way to go guys!

-Mehmet


On Wed, Dec 9, 2009 at 11:03 AM, Jeff Squyres <jsquyres@cisco.com> wrote:
Oy -- I had forgotten about that.  Sorry!

I think your only option at the moment is to separate the use of threads from your plpa_runtime.c file.  I realize that that's a sucky answer, but that might be the final/only answer for PLPA.  Sorry.  :-(

hwloc is probably the best answer for the future -- as I mentioned, the embedding work is occurring right now and will be included in v1.0.  It will not have this "override cpu_set_t" issue that PLPA does.


On Dec 7, 2009, at 10:03 AM, Allen Chen wrote:

> sorry for the delay...
> I followed this example in the README:
>
> ----------
> shell$ cd sandbox
> shell$ cp -r /somewhere/else/plpa-<version> plpa
> shell$ edit acinclude.m4
> ...add the line "m4_include(plpa/config/plpa.m4)"...
> shell$ edit Makefile.am
> ...add "plpa" to SUBDIRS...
> ...add "$(top_builddir)/plpa/src/libplpa/libplpa_included.la" to
>    my executable's LDADD line...
> ...add "-I$(top_builddir)/plpa/src/libplpa" to AM_CPPFLAGS
> shell$ edit configure.ac
> ...add "PLPA_INCLUDED" line...
> ...add "PLPA_SET_SYMBOL_PREFIX(sandbox_plpa_)" line...
> ...add "PLPA_INIT([./plpa], [plpa_happy=yes], [plpa_happy=no])" line...
> ...add error checking for plpa_happy=no case...
> shell$ edit src/my_program.c
> ...add #include <plpa.h>...
> ...add calls to sandbox_plpa_sched_setaffinity()...
> shell$ aclocal
> shell$ autoconf
> shell$ libtoolize --automake
> shell$ automake -a
> shell$ ./configure
> ...lots of output...
> shell$ make
> ...lots of output...
> ----------
>
> On the last line..when I try to run make I get this error:
>
> Making all in src
> make[1]: Entering directory `/home/achen/test/plpa/src'
> Making all in libplpa
> make[2]: Entering directory `/home/achen/test/plpa/src/libplpa'
> make  all-am
> make[3]: Entering directory `/home/achen/test/plpa/src/libplpa'
> depbase=`echo plpa_runtime.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \
>         if /bin/sh ../../libtool --tag=CC --mode=compile gcc
> -DHAVE_CONFIG_H -I. -I. -I. -I.      -MT plpa_runtime.lo -MD -MP -MF
> "$depbase.Tpo" -c -o plpa_runtime.lo plpa_runtime.c; \
>         then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f
> "$depbase.Tpo"; exit 1; fi
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -MT
> plpa_runtime.lo -MD -MP -MF .deps/plpa_runtime.Tpo -c plpa_runtime.c
> -fPIC -DPIC -o .libs/plpa_runtime.o
> In file included from /usr/include/sched.h:32,
>                  from /usr/include/pthread.h:24,
>                  from plpa_runtime.c:10:
> /usr/include/bits/sched.h:114: error: conflicting types for ‘cpu_set_t’
> plpa.h:116: error: previous declaration of ‘cpu_set_t’ was here
>
>
>
> I looked into plpa.h and found this comment:
>
> /* Absolutely must not include <sched.h> here or it will generate
>    conflicts. */
>
> How can I prevent sched.h from being included, since it is required by
> pthread.h?
>
>
> Thanks,
> Allen
>
>
> On Thu, 2009-12-03 at 16:04 -0500, Jeff Squyres wrote:
> > FWIW, I have not had such problems.
> >
> > Can you provide more details?
> >
> > Additionally, have you looked at hwloc?  hwloc is the successor to PLPA -- it has much more capabilities.  hwloc does not yet have the included mode that PLPA has, but I'm literally working on that right now...
> >
> >
> > On Dec 3, 2009, at 3:56 PM, Allen Chen wrote:
> >
> > > Hi,
> > > I am trying to compile in include mode, but seem to have some trouble...
> > > I followed all of the steps in the README, but when i attempt the last
> > > step, make i get a conflicting types error.
> > > The problem is that I cannot compile plpa.h with sched.h included.
> > > However, plpa_runtime.c includes pthread.h, which includes sched.h. Am I
> > > missing something here???
> > > Also, does this mean I cannot include pthread.h in my program which
> > > intends to use plpa.h as well?
> > >
> > > Thanks,
> > > Allen
> > >
> > > _______________________________________________
> > > plpa-users mailing list
> > > plpa-users@open-mpi.org
> > > http://www.open-mpi.org/mailman/listinfo.cgi/plpa-users
> >
> >
> --
> Allen Chen
> Software Engineer
> CSA Group, LLC
> 140 Broadway, 38th Floor
> New York, NY 10005
> +1 (646) 845-0038
>
> _______________________________________________
> plpa-users mailing list
> plpa-users@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/plpa-users
>


--
Jeff Squyres
jsquyres@cisco.com


_______________________________________________
plpa-users mailing list
plpa-users@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/plpa-users