[hwloc-devel] Create success (hwloc r1.5.3rc1r5595)

[MPI Team]

Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.5.3rc1r5595
Start time: Tue May  7 21:14:17 EDT 2013
End time:   Tue May  7 21:18:21 EDT 2013

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc r1.7.1rc1r5593)

[MPI Team]

Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.7.1rc1r5593
Start time: Tue May  7 21:05:39 EDT 2013
End time:   Tue May  7 21:09:53 EDT 2013

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc r1.8a1r5606)

[MPI Team]

Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.8a1r5606
Start time: Tue May  7 21:01:01 EDT 2013
End time:   Tue May  7 21:05:39 EDT 2013

Your friendly daemon,
Cyrador

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

How's this patch?

The only question I have is: how do we figure out what libraries to put in the 
.pc file in the --disable-shared --enable-static case?


On May 7, 2013, at 8:24 PM, Samuel Thibault  wrote:

> Jeff Squyres (jsquyres), le Wed 08 May 2013 02:21:02 +0200, a écrit :
>> On May 7, 2013, at 6:25 PM, Brice Goglin  wrote:
>> 
>>> I don't have anything against this. What was the reason for not using
>>> the default/system libltdl in OMPI? libtool was buggy when you started
>>> using it?
>> 
>> 
>> I neglected to answer this.
>> 
>> Yes, plus libltdl grew new functionality that we needed (global/local symbol 
>> visibility).
>> 
>> We might be getting to the point soon where we can rely on the installed 
>> libltdl to be new enough everywhere, but we haven't had that conversation.
> 
> We could already check that the installed version is new enough for our
> needs.
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/


no-embed-libltdl.diff
Description: no-embed-libltdl.diff

Re: [hwloc-devel] hwloc embedding vs libltdl

[Samuel Thibault]

Jeff Squyres (jsquyres), le Wed 08 May 2013 02:21:02 +0200, a écrit :
> On May 7, 2013, at 6:25 PM, Brice Goglin  wrote:
> 
> > I don't have anything against this. What was the reason for not using
> > the default/system libltdl in OMPI? libtool was buggy when you started
> > using it?
> 
> 
> I neglected to answer this.
> 
> Yes, plus libltdl grew new functionality that we needed (global/local symbol 
> visibility).
> 
> We might be getting to the point soon where we can rely on the installed 
> libltdl to be new enough everywhere, but we haven't had that conversation.

We could already check that the installed version is new enough for our
needs.

Samuel

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

Er... here's the patch I forgot to attach.  :-)



On May 7, 2013, at 6:00 PM, "Jeff Squyres (jsquyres)"  
wrote:

> Sorry for the high latency reply.
>
> I thought about this quite a bit today.  Here's a thinking-out-of-the-box 
> question: should we just use the default/system installed libltdl instead of 
> embedding?  If we don't embed, many of these problems go away, right?  I.e., 
> we can still have the same options for plugins: non-default, but available if 
> you ask for it *and* there's a system-level libltdl available.
>
> FWIW: I see RHEL 6.x uses libtool/libltdl 2.2.6.  Do we:
>
> a) care about supporting plugins by default on distros with older ltdl 
> versions?
> b) use any functionality beyond libltdl 2.2.6?  (or some other 
> older/benchmark distro ltdl version that we care about supporting)
>
> Attached is a patch that does a few minor things:
>
> - avoid the use of AM_CONDITIONAL for the libltdl subdir
> - ensure to have libtool avoid setting up Fortran and C++ (a trick we learned 
> from MPICH :-) )
> - disallow embedded mode and plugins (per our phone discussion the other day)
> - reorder the plugins support AC_MSG_RESULT to come before any WARN/ERROR 
> messages
>
>
> On Apr 30, 2013, at 5:30 AM, Brice Goglin  wrote:
>
>> Jeff,
>>
>> I've been working on making hwloc v1.7 pass our tests/embedded scripts
>> in the last days. I fixed some minor issues but here's the remaining
>> (big) one.
>>
>> First problem is that we need the AM_CONDITIONAL for HWLOC_LTDL_INCLUDED
>> to be executed when embedded. I can fix this by moving into
>> HWLOC_DO_AM_CONDITIONAL. But...
>>
>> We conditionally enable SUBDIRS=libltdl (in src/Makefile.am) when
>> plugins are enabled and the internal ltdl is used. Assuming embedders
>> don't want hwloc plugins, this builds fine since we don't enter libltdl
>> during "make", and we can avoid the (ugly) ltdl configuration entirely
>> [1]. But "make distclean" still enters libltdl unconditionally, and it
>> fails if LTDL wasn't configured because the Makefile is missing.
>>
>> For the record, you had a similar issue with doc/tests/tools where you
>> don't even have a Makefile.am in these directories in OMPI. You fixed it
>> by doing DIST_SUBDIRS=$(SUBDIRS). It means that distclean doesn't enter
>> those directories at all. But it also means that you don't get
>> doc/tests/tools in make dist when embedded is enabled. We don't build
>> hwloc tarballs in embedded mode so that's fine. Using the same idea for
>> my issue would require to build hwloc tarballs with plugins enabled and
>> ltld included (both non default), I don't thing we should to this way.
>>
>> So we need a way to have src/libltdl stay in DIST_SUBDIRS by default, go
>> in SUBDIRS when needed, and disappear totally when embedded. So here's
>> the only solution I finally found: hwloc configure.ac sets a shell
>> variable to yes, and a new AM_CONDITIONAL adds src/libltdl to
>> DIST_SUBDIRS only when this variable is "yes".
>> This still causes hwloc tarballs to contain libltdl (because hwloc
>> configure.ac sets the variable to yes). It's still enabled only when the
>> system doesn't have libltdl installed or --with-included-ltdl is given,
>> as previously. And embedders totally ignore src/libltdl, including in
>> distclean, because they don't set the variable to yes.
>>
>> If an embedder ever wants to use hwloc plugins, he will have to
>> duplicate what the hwloc configure.ac does [1], and it can still link
>> with another libltdl if needed (to be tested).
>>
>> Patch attached, on top of trunk. Note that you may need these additional
>> commits if you or Pavan want to test things [2]
>>
>> Let me know what you think because you have the same problem as Pavan
>> when OMPI switches to hwloc v1.6+
>>
>> Brice
>>
>>
>>
>>
>> [1] Enabling ltdl requires some code like below:configure.ac
>> AM_PROG_LIBTOOL([dlopen win32-dll])
>> LT_LANG([C])
>> # Here's what we need to configure ltdl properly
>> LT_CONFIG_LTDL_DIR([src/libltdl])
>> LTDL_INIT([recursive convenience])
>> AC_CONFIG_FILES([src/libltdl/Makefile])
>> # Tell src/Makefile.am that things were configured under src/libltdl/
>> hwloc_mayenter_src_libltdl=yes
>>
>> libtool doesn't seem to like having it in a HWLOC_SETUP_LTDL macro
>> outside of the main, and I think we have to let embedders call
>> AM_PROG_LIBTOOL() directly in case they need other options.
>>
>> There's also a hack below these lines that is specific to the
>> "recursive" mode, but we may switch to "subproject" mode  (hwloc
>> configure explicitly calls libltdl configure) at some point if libtool
>> doesn't fix the issue.
>>
>> [2]
>> https://svn.open-mpi.org/trac/hwloc/changeset/5563
>> https://svn.open-mpi.org/trac/hwloc/changeset/5562
>>
>> 
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
>
> ___
> 

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

Sorry for the high latency reply.

I thought about this quite a bit today.  Here's a thinking-out-of-the-box 
question: should we just use the default/system installed libltdl instead of 
embedding?  If we don't embed, many of these problems go away, right?  I.e., we 
can still have the same options for plugins: non-default, but available if you 
ask for it *and* there's a system-level libltdl available.

FWIW: I see RHEL 6.x uses libtool/libltdl 2.2.6.  Do we:

a) care about supporting plugins by default on distros with older ltdl versions?
b) use any functionality beyond libltdl 2.2.6?  (or some other older/benchmark 
distro ltdl version that we care about supporting)

Attached is a patch that does a few minor things:

- avoid the use of AM_CONDITIONAL for the libltdl subdir
- ensure to have libtool avoid setting up Fortran and C++ (a trick we learned 
from MPICH :-) )
- disallow embedded mode and plugins (per our phone discussion the other day)
- reorder the plugins support AC_MSG_RESULT to come before any WARN/ERROR 
messages


On Apr 30, 2013, at 5:30 AM, Brice Goglin  wrote:

> Jeff,
> 
> I've been working on making hwloc v1.7 pass our tests/embedded scripts
> in the last days. I fixed some minor issues but here's the remaining
> (big) one.
> 
> First problem is that we need the AM_CONDITIONAL for HWLOC_LTDL_INCLUDED
> to be executed when embedded. I can fix this by moving into
> HWLOC_DO_AM_CONDITIONAL. But...
> 
> We conditionally enable SUBDIRS=libltdl (in src/Makefile.am) when
> plugins are enabled and the internal ltdl is used. Assuming embedders
> don't want hwloc plugins, this builds fine since we don't enter libltdl
> during "make", and we can avoid the (ugly) ltdl configuration entirely
> [1]. But "make distclean" still enters libltdl unconditionally, and it
> fails if LTDL wasn't configured because the Makefile is missing.
> 
> For the record, you had a similar issue with doc/tests/tools where you
> don't even have a Makefile.am in these directories in OMPI. You fixed it
> by doing DIST_SUBDIRS=$(SUBDIRS). It means that distclean doesn't enter
> those directories at all. But it also means that you don't get
> doc/tests/tools in make dist when embedded is enabled. We don't build
> hwloc tarballs in embedded mode so that's fine. Using the same idea for
> my issue would require to build hwloc tarballs with plugins enabled and
> ltld included (both non default), I don't thing we should to this way.
> 
> So we need a way to have src/libltdl stay in DIST_SUBDIRS by default, go
> in SUBDIRS when needed, and disappear totally when embedded. So here's
> the only solution I finally found: hwloc configure.ac sets a shell
> variable to yes, and a new AM_CONDITIONAL adds src/libltdl to
> DIST_SUBDIRS only when this variable is "yes".
> This still causes hwloc tarballs to contain libltdl (because hwloc
> configure.ac sets the variable to yes). It's still enabled only when the
> system doesn't have libltdl installed or --with-included-ltdl is given,
> as previously. And embedders totally ignore src/libltdl, including in
> distclean, because they don't set the variable to yes.
> 
> If an embedder ever wants to use hwloc plugins, he will have to
> duplicate what the hwloc configure.ac does [1], and it can still link
> with another libltdl if needed (to be tested).
> 
> Patch attached, on top of trunk. Note that you may need these additional
> commits if you or Pavan want to test things [2]
> 
> Let me know what you think because you have the same problem as Pavan
> when OMPI switches to hwloc v1.6+
> 
> Brice
> 
> 
> 
> 
> [1] Enabling ltdl requires some code like below:configure.ac
> AM_PROG_LIBTOOL([dlopen win32-dll])
> LT_LANG([C])
> # Here's what we need to configure ltdl properly
> LT_CONFIG_LTDL_DIR([src/libltdl])
> LTDL_INIT([recursive convenience])
> AC_CONFIG_FILES([src/libltdl/Makefile])
> # Tell src/Makefile.am that things were configured under src/libltdl/
> hwloc_mayenter_src_libltdl=yes
> 
> libtool doesn't seem to like having it in a HWLOC_SETUP_LTDL macro
> outside of the main, and I think we have to let embedders call
> AM_PROG_LIBTOOL() directly in case they need other options.
> 
> There's also a hack below these lines that is specific to the
> "recursive" mode, but we may switch to "subproject" mode  (hwloc
> configure explicitly calls libltdl configure) at some point if libtool
> doesn't fix the issue.
> 
> [2]
> https://svn.open-mpi.org/trac/hwloc/changeset/5563
> https://svn.open-mpi.org/trac/hwloc/changeset/5562
> 
> 


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] RPATH issues when building in Fedora 18

[Jiri Hladky]

Thanks a lot for all the feedback !!!

I went with
autoreconf --force --install

which solved a problem.

@Jeff: the versions of your quadtuple looks good to me! I'm using the same
with the exception of automake (1.12.2 which is even older than yours).

I have now successfully created rpm for hwloc 1.7 for Fedora.

Jirka

On Wed, Apr 24, 2013 at 2:52 PM, Jeff Squyres (jsquyres)  wrote:

> I'm a little late to this thread, but I just changed the build machine to
> build hwloc trunk tarballs with the same versions of Autotools as the v1.7
> tarballs:
>
> AC 2.69
> AM 1.13.1
> LT 2.4.2
> GM4 1.4.16
>
> Let me know if that's good.  If not, I can install any quadtuple (use that
> in a sentence today) of versions that we need.
>
>
>
> On Apr 24, 2013, at 3:48 AM, Brice Goglin  wrote:
>
> > Le 24/04/2013 08:05, Paul Hargrove a écrit :
> >>
> >> Ok, thanks. So our configure indeed generates libtool script that
> >> depends on where the tarball was generated. That's a bit disturbing.
> >>
> >>
> >> It is not quite as you describe because I was talking about Fedora's
> libtool.m4 doing the hardcoding.
> >> The libtool.m4 logic that is distributed with hwloc *tries* to perform
> a configure probe to determine the dynamic lib search path.
> >> Unfortunately, that probe isn't smart enough to get the right answer on
> all Linux distros.
> >> So, the libtool.m4 from Fedora is the one I see hardcoding the correct
> answer.
> >> Again: libtool in the official tarball of hwloc-1.7 does NOT do
> something as horrible as hardcode the wrong answer from the distro where
> one built the tarball (but it probably would it you built the tarball on
> Fedora).
> >
> > Well, it's the same idea in the end. The libtool.m4 in the hwloc tarball
> is placed there by autoreconf, so it comes from the Debian machine where I
> generate the tarballs. I could generate official tarballs on Fedora to work
> around the issue (some nightly builds are generated this way, but not the
> official ones from the website (RHEL4 iirc).
> >
> >> It appears somebody has been bugging the libtool developers about this
> since June 2010:
> >>
> http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00141.html
> >
> > That "somebody" is the person who opened this hwloc thread yesterday :)
> >
> >> In my testing on Fedora 17, the patch below applied to hwloc-1.7
> produces an accurate sys_lib_dlsearch_path_spec
> >
> > It's crazy that this hasn't been resolved earlier. Many projects may
> have the same problem. Maybe many of them ignore it because they build
> their tarballs on distros with a patched libtool.
> >
> > Anyway, we can't easily patch hwloc's libtool.m4 since we'd have to do
> that during autogen (after libtool.m4 gets copied), and the patch may fail
> against some versions of libtool. We could patch during the release tarball
> generation since we enforce the libtool version there, but I still don't
> fully like the idea.
> >
> >
> > Let's see if Jirka can work around the problem by autoreconfing during
> the RPM build and ping the libtool maintainers to finally fix this.
> >
> > Brice
> >
> > ___
> > hwloc-devel mailing list
> > hwloc-de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
>

Re: [hwloc-devel] hwloc-1.7 issue roundup

[Pavan Balaji]

Perfect.  Thanks.

 -- Pavan

On 05/07/2013 10:07 AM US Central Time, Brice Goglin wrote:
> We got several important bug reports (and fixes) in the last days. I
> think we don't need anything new aside from the pending LTDL fix. So
> let's say within 2 weeks.
> 
> Brice
> 
> 
> Le 07/05/2013 16:59, Pavan Balaji a écrit :
>> Thanks Brice.  What's the timeframe for 1.7.1?  I want to see if we can
>> move to that for our mpich-3.1 release.
>>
>>  -- Pavan
>>
>> On 05/07/2013 09:53 AM US Central Time, Brice Goglin wrote:
>>> Pavan,
>>>
>>> I just pushed another round of commits to trunk, which hopefully address
>>> everything said earlier (except the LDTL problem waiting for Jeff's review).
>>>
>>> 1) autogen args
>>> https://svn.open-mpi.org/trac/hwloc/changeset/5586
>>> 2) sys/sysctl.h #ifdef fix
>>> https://svn.open-mpi.org/trac/hwloc/changeset/5587
>>> 3) sysctl/sysctlbyname check fix (include additional fix for icc)
>>> https://svn.open-mpi.org/trac/hwloc/changeset/5598
>>> 4) HWLOC_CHECK_DECL improvement
>>> https://svn.open-mpi.org/trac/hwloc/changeset/5599
>>> 5) strtoull check
>>> https://svn.open-mpi.org/trac/hwloc/changeset/5600
>>>
>>> (1) and (2) will be backported to v1.7 once regression testing is done.
>>> (5) should likely be OK too.
>>> (3) and more importantly (4) touch ugly configury, I am not sure I want
>>> to backport these. Or maybe later, in case we get more testing before
>>> v1.7.1 occurs.
>>>
>>> Brice
>>>
>>>
>>>
>>>
>>> Le 05/05/2013 18:18, Pavan Balaji a écrit :
 All,

 Sorry for starting a new thread.  I'm trying to round-up all the issues
 I've reported for hwloc-1.7 so far into a more manageable format.

 1. We had noticed errors with -D_POSIX_SOURCE that I had reported here:

 http://www.open-mpi.org/community/lists/hwloc-devel/2013/04/3649.php

 The error with POSIX_SOURCE itself was pretty straightforward.  I was
 able to fix it in the mpich version:

 http://git.mpich.org/mpich.git/commitdiff/255da3f6

 However, with our complete strict build flags, there were more errors.
 Here's a summary and the relevant fixes:

  - hwloc's check for whether an explicitly function declaration is
 needed (using _HWLOC_CHECK_DECL) was relying on whether a dummy call to
 the function throws an error.  This only works if the function
 declaration is already present in one of the headers.  If such a
 declaration is not present, the test might fail with "implicit function
 declaration" with the right CFLAGS.  This leads the m4 macro to think
 that the declaration is already there in one of the headers and an
 additional declaration is not needed.

 The below commit fixes this by adding a dummy function declaration,
 together with the dummy function definition:

 http://git.mpich.org/mpich.git/commitdiff/90da6e90

 FWIW, mpich's version of this macro also uses a similar dummy function
 declaration together with the dummy call to the function:

 http://git.mpich.org/mpich.git/blob/HEAD:/confdb/aclocal_cc.m4#l1215

  - For sysctl and sysctlbyname, I've updated hwloc/config.m4 to use a
 full link test instead of just using AC_CHECK_FUNCS, which only checks
 to see if the symbol exists or not.  For example, the prototype of
 sysctl uses u_int, which on some platforms (such as FreeBSD) is only
 defined under __BSD_VISIBLE, __USE_BSD or other similar definitions.  So
 while the symbols "sysctl" and "sysctlbyname" might still be available
 in libc (which autoconf checks for), they might not be actually usable.

 The below commit fixes this:

 http://git.mpich.org/mpich.git/commitdiff/db276e4e

  - A minor error where strings.h was not included for strcasecmp.

 http://git.mpich.org/mpich.git/commitdiff/d2338c2d

 2. I had reported an issue with libltdl in embedded mode (also in the
 above thread).  I believe Brice is looking into this, so I didn't
 investigate it further.  I'm using a disgusting, but workable, patch to
 workaround this error in mpich (see the
 src/pm/hydra/tools/topo/hwloc/hwloc/src/Makefile.am part of the below
 patch):

 http://git.mpich.org/mpich.git/commitdiff/a3bce754

 I'd appreciate a cleaner fix to this issue.

 3. I had reported an issue with the usage of getpagesize() instead of
 hwloc_getpagesize() on the Mac.

 http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3662.php

 I believe Samuel has already incorporated this in hwloc trunk.  Here is
 the fix I used for your reference:

 http://git.mpich.org/mpich.git/commitdiff/d9a67f40

 4. I had reported some warnings on the FreeBSD strict build here.

 http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3669.php

 I believe Brice and Samuel are looking into it, but I don't have a
 confirmation on 

Re: [hwloc-devel] hwloc-1.7 issue roundup

[Brice Goglin]

We got several important bug reports (and fixes) in the last days. I
think we don't need anything new aside from the pending LTDL fix. So
let's say within 2 weeks.

Brice


Le 07/05/2013 16:59, Pavan Balaji a écrit :
> Thanks Brice.  What's the timeframe for 1.7.1?  I want to see if we can
> move to that for our mpich-3.1 release.
>
>  -- Pavan
>
> On 05/07/2013 09:53 AM US Central Time, Brice Goglin wrote:
>> Pavan,
>>
>> I just pushed another round of commits to trunk, which hopefully address
>> everything said earlier (except the LDTL problem waiting for Jeff's review).
>>
>> 1) autogen args
>> https://svn.open-mpi.org/trac/hwloc/changeset/5586
>> 2) sys/sysctl.h #ifdef fix
>> https://svn.open-mpi.org/trac/hwloc/changeset/5587
>> 3) sysctl/sysctlbyname check fix (include additional fix for icc)
>> https://svn.open-mpi.org/trac/hwloc/changeset/5598
>> 4) HWLOC_CHECK_DECL improvement
>> https://svn.open-mpi.org/trac/hwloc/changeset/5599
>> 5) strtoull check
>> https://svn.open-mpi.org/trac/hwloc/changeset/5600
>>
>> (1) and (2) will be backported to v1.7 once regression testing is done.
>> (5) should likely be OK too.
>> (3) and more importantly (4) touch ugly configury, I am not sure I want
>> to backport these. Or maybe later, in case we get more testing before
>> v1.7.1 occurs.
>>
>> Brice
>>
>>
>>
>>
>> Le 05/05/2013 18:18, Pavan Balaji a écrit :
>>> All,
>>>
>>> Sorry for starting a new thread.  I'm trying to round-up all the issues
>>> I've reported for hwloc-1.7 so far into a more manageable format.
>>>
>>> 1. We had noticed errors with -D_POSIX_SOURCE that I had reported here:
>>>
>>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/04/3649.php
>>>
>>> The error with POSIX_SOURCE itself was pretty straightforward.  I was
>>> able to fix it in the mpich version:
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/255da3f6
>>>
>>> However, with our complete strict build flags, there were more errors.
>>> Here's a summary and the relevant fixes:
>>>
>>>  - hwloc's check for whether an explicitly function declaration is
>>> needed (using _HWLOC_CHECK_DECL) was relying on whether a dummy call to
>>> the function throws an error.  This only works if the function
>>> declaration is already present in one of the headers.  If such a
>>> declaration is not present, the test might fail with "implicit function
>>> declaration" with the right CFLAGS.  This leads the m4 macro to think
>>> that the declaration is already there in one of the headers and an
>>> additional declaration is not needed.
>>>
>>> The below commit fixes this by adding a dummy function declaration,
>>> together with the dummy function definition:
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/90da6e90
>>>
>>> FWIW, mpich's version of this macro also uses a similar dummy function
>>> declaration together with the dummy call to the function:
>>>
>>> http://git.mpich.org/mpich.git/blob/HEAD:/confdb/aclocal_cc.m4#l1215
>>>
>>>  - For sysctl and sysctlbyname, I've updated hwloc/config.m4 to use a
>>> full link test instead of just using AC_CHECK_FUNCS, which only checks
>>> to see if the symbol exists or not.  For example, the prototype of
>>> sysctl uses u_int, which on some platforms (such as FreeBSD) is only
>>> defined under __BSD_VISIBLE, __USE_BSD or other similar definitions.  So
>>> while the symbols "sysctl" and "sysctlbyname" might still be available
>>> in libc (which autoconf checks for), they might not be actually usable.
>>>
>>> The below commit fixes this:
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/db276e4e
>>>
>>>  - A minor error where strings.h was not included for strcasecmp.
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/d2338c2d
>>>
>>> 2. I had reported an issue with libltdl in embedded mode (also in the
>>> above thread).  I believe Brice is looking into this, so I didn't
>>> investigate it further.  I'm using a disgusting, but workable, patch to
>>> workaround this error in mpich (see the
>>> src/pm/hydra/tools/topo/hwloc/hwloc/src/Makefile.am part of the below
>>> patch):
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/a3bce754
>>>
>>> I'd appreciate a cleaner fix to this issue.
>>>
>>> 3. I had reported an issue with the usage of getpagesize() instead of
>>> hwloc_getpagesize() on the Mac.
>>>
>>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3662.php
>>>
>>> I believe Samuel has already incorporated this in hwloc trunk.  Here is
>>> the fix I used for your reference:
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/d9a67f40
>>>
>>> 4. I had reported some warnings on the FreeBSD strict build here.
>>>
>>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3669.php
>>>
>>> I believe Brice and Samuel are looking into it, but I don't have a
>>> confirmation on whether this is fixed.  I didn't fix them in mpich yet.
>>>
>>> As you can tell, we are looking into upgrading to hwloc-1.7 for the next
>>> major release of mpich (3.1).  With the above fixes, it looks like
>>> things 

Re: [hwloc-devel] hwloc-1.7 issue roundup

[Pavan Balaji]

Thanks Brice.  What's the timeframe for 1.7.1?  I want to see if we can
move to that for our mpich-3.1 release.

 -- Pavan

On 05/07/2013 09:53 AM US Central Time, Brice Goglin wrote:
> Pavan,
> 
> I just pushed another round of commits to trunk, which hopefully address
> everything said earlier (except the LDTL problem waiting for Jeff's review).
> 
> 1) autogen args
> https://svn.open-mpi.org/trac/hwloc/changeset/5586
> 2) sys/sysctl.h #ifdef fix
> https://svn.open-mpi.org/trac/hwloc/changeset/5587
> 3) sysctl/sysctlbyname check fix (include additional fix for icc)
> https://svn.open-mpi.org/trac/hwloc/changeset/5598
> 4) HWLOC_CHECK_DECL improvement
> https://svn.open-mpi.org/trac/hwloc/changeset/5599
> 5) strtoull check
> https://svn.open-mpi.org/trac/hwloc/changeset/5600
> 
> (1) and (2) will be backported to v1.7 once regression testing is done.
> (5) should likely be OK too.
> (3) and more importantly (4) touch ugly configury, I am not sure I want
> to backport these. Or maybe later, in case we get more testing before
> v1.7.1 occurs.
> 
> Brice
> 
> 
> 
> 
> Le 05/05/2013 18:18, Pavan Balaji a écrit :
>> All,
>>
>> Sorry for starting a new thread.  I'm trying to round-up all the issues
>> I've reported for hwloc-1.7 so far into a more manageable format.
>>
>> 1. We had noticed errors with -D_POSIX_SOURCE that I had reported here:
>>
>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/04/3649.php
>>
>> The error with POSIX_SOURCE itself was pretty straightforward.  I was
>> able to fix it in the mpich version:
>>
>> http://git.mpich.org/mpich.git/commitdiff/255da3f6
>>
>> However, with our complete strict build flags, there were more errors.
>> Here's a summary and the relevant fixes:
>>
>>  - hwloc's check for whether an explicitly function declaration is
>> needed (using _HWLOC_CHECK_DECL) was relying on whether a dummy call to
>> the function throws an error.  This only works if the function
>> declaration is already present in one of the headers.  If such a
>> declaration is not present, the test might fail with "implicit function
>> declaration" with the right CFLAGS.  This leads the m4 macro to think
>> that the declaration is already there in one of the headers and an
>> additional declaration is not needed.
>>
>> The below commit fixes this by adding a dummy function declaration,
>> together with the dummy function definition:
>>
>> http://git.mpich.org/mpich.git/commitdiff/90da6e90
>>
>> FWIW, mpich's version of this macro also uses a similar dummy function
>> declaration together with the dummy call to the function:
>>
>> http://git.mpich.org/mpich.git/blob/HEAD:/confdb/aclocal_cc.m4#l1215
>>
>>  - For sysctl and sysctlbyname, I've updated hwloc/config.m4 to use a
>> full link test instead of just using AC_CHECK_FUNCS, which only checks
>> to see if the symbol exists or not.  For example, the prototype of
>> sysctl uses u_int, which on some platforms (such as FreeBSD) is only
>> defined under __BSD_VISIBLE, __USE_BSD or other similar definitions.  So
>> while the symbols "sysctl" and "sysctlbyname" might still be available
>> in libc (which autoconf checks for), they might not be actually usable.
>>
>> The below commit fixes this:
>>
>> http://git.mpich.org/mpich.git/commitdiff/db276e4e
>>
>>  - A minor error where strings.h was not included for strcasecmp.
>>
>> http://git.mpich.org/mpich.git/commitdiff/d2338c2d
>>
>> 2. I had reported an issue with libltdl in embedded mode (also in the
>> above thread).  I believe Brice is looking into this, so I didn't
>> investigate it further.  I'm using a disgusting, but workable, patch to
>> workaround this error in mpich (see the
>> src/pm/hydra/tools/topo/hwloc/hwloc/src/Makefile.am part of the below
>> patch):
>>
>> http://git.mpich.org/mpich.git/commitdiff/a3bce754
>>
>> I'd appreciate a cleaner fix to this issue.
>>
>> 3. I had reported an issue with the usage of getpagesize() instead of
>> hwloc_getpagesize() on the Mac.
>>
>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3662.php
>>
>> I believe Samuel has already incorporated this in hwloc trunk.  Here is
>> the fix I used for your reference:
>>
>> http://git.mpich.org/mpich.git/commitdiff/d9a67f40
>>
>> 4. I had reported some warnings on the FreeBSD strict build here.
>>
>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3669.php
>>
>> I believe Brice and Samuel are looking into it, but I don't have a
>> confirmation on whether this is fixed.  I didn't fix them in mpich yet.
>>
>> As you can tell, we are looking into upgrading to hwloc-1.7 for the next
>> major release of mpich (3.1).  With the above fixes, it looks like
>> things are working well.  Of course, we'll be going through a lot more
>> testing before the final release which would be later this year.
>>
>>  -- Pavan
>>
> 

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji

Re: [hwloc-devel] hwloc-1.7 issue roundup

[Brice Goglin]

Pavan,

I just pushed another round of commits to trunk, which hopefully address
everything said earlier (except the LDTL problem waiting for Jeff's review).

1) autogen args
https://svn.open-mpi.org/trac/hwloc/changeset/5586
2) sys/sysctl.h #ifdef fix
https://svn.open-mpi.org/trac/hwloc/changeset/5587
3) sysctl/sysctlbyname check fix (include additional fix for icc)
https://svn.open-mpi.org/trac/hwloc/changeset/5598
4) HWLOC_CHECK_DECL improvement
https://svn.open-mpi.org/trac/hwloc/changeset/5599
5) strtoull check
https://svn.open-mpi.org/trac/hwloc/changeset/5600

(1) and (2) will be backported to v1.7 once regression testing is done.
(5) should likely be OK too.
(3) and more importantly (4) touch ugly configury, I am not sure I want
to backport these. Or maybe later, in case we get more testing before
v1.7.1 occurs.

Brice




Le 05/05/2013 18:18, Pavan Balaji a écrit :
> All,
>
> Sorry for starting a new thread.  I'm trying to round-up all the issues
> I've reported for hwloc-1.7 so far into a more manageable format.
>
> 1. We had noticed errors with -D_POSIX_SOURCE that I had reported here:
>
> http://www.open-mpi.org/community/lists/hwloc-devel/2013/04/3649.php
>
> The error with POSIX_SOURCE itself was pretty straightforward.  I was
> able to fix it in the mpich version:
>
> http://git.mpich.org/mpich.git/commitdiff/255da3f6
>
> However, with our complete strict build flags, there were more errors.
> Here's a summary and the relevant fixes:
>
>  - hwloc's check for whether an explicitly function declaration is
> needed (using _HWLOC_CHECK_DECL) was relying on whether a dummy call to
> the function throws an error.  This only works if the function
> declaration is already present in one of the headers.  If such a
> declaration is not present, the test might fail with "implicit function
> declaration" with the right CFLAGS.  This leads the m4 macro to think
> that the declaration is already there in one of the headers and an
> additional declaration is not needed.
>
> The below commit fixes this by adding a dummy function declaration,
> together with the dummy function definition:
>
> http://git.mpich.org/mpich.git/commitdiff/90da6e90
>
> FWIW, mpich's version of this macro also uses a similar dummy function
> declaration together with the dummy call to the function:
>
> http://git.mpich.org/mpich.git/blob/HEAD:/confdb/aclocal_cc.m4#l1215
>
>  - For sysctl and sysctlbyname, I've updated hwloc/config.m4 to use a
> full link test instead of just using AC_CHECK_FUNCS, which only checks
> to see if the symbol exists or not.  For example, the prototype of
> sysctl uses u_int, which on some platforms (such as FreeBSD) is only
> defined under __BSD_VISIBLE, __USE_BSD or other similar definitions.  So
> while the symbols "sysctl" and "sysctlbyname" might still be available
> in libc (which autoconf checks for), they might not be actually usable.
>
> The below commit fixes this:
>
> http://git.mpich.org/mpich.git/commitdiff/db276e4e
>
>  - A minor error where strings.h was not included for strcasecmp.
>
> http://git.mpich.org/mpich.git/commitdiff/d2338c2d
>
> 2. I had reported an issue with libltdl in embedded mode (also in the
> above thread).  I believe Brice is looking into this, so I didn't
> investigate it further.  I'm using a disgusting, but workable, patch to
> workaround this error in mpich (see the
> src/pm/hydra/tools/topo/hwloc/hwloc/src/Makefile.am part of the below
> patch):
>
> http://git.mpich.org/mpich.git/commitdiff/a3bce754
>
> I'd appreciate a cleaner fix to this issue.
>
> 3. I had reported an issue with the usage of getpagesize() instead of
> hwloc_getpagesize() on the Mac.
>
> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3662.php
>
> I believe Samuel has already incorporated this in hwloc trunk.  Here is
> the fix I used for your reference:
>
> http://git.mpich.org/mpich.git/commitdiff/d9a67f40
>
> 4. I had reported some warnings on the FreeBSD strict build here.
>
> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3669.php
>
> I believe Brice and Samuel are looking into it, but I don't have a
> confirmation on whether this is fixed.  I didn't fix them in mpich yet.
>
> As you can tell, we are looking into upgrading to hwloc-1.7 for the next
> major release of mpich (3.1).  With the above fixes, it looks like
> things are working well.  Of course, we'll be going through a lot more
> testing before the final release which would be later this year.
>
>  -- Pavan
>