Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] hwloc-1.4 "gmake check" failure on Solaris-10/SPARC/gccfss [PATCH]
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2012-02-02 00:51:05

We could also AC_TRY_LINK a program that uses ffsfoo (the one that
actually breaks here).
If it fails, we AC_TRY_LINK a program that uses ffsfoo with the
__ffssi2() definition.
If it fails, we define NEED_FFS_FIX
And we just add the fix under #ifdef NEED_FFS_FIX in private/misc.h.
Would that work?

Le 02/02/2012 02:28, Paul H. Hargrove a écrit :
> On 2/1/2012 11:46 AM, Paul H. Hargrove wrote:
> [snip]
>> So, in short: when building w/ this compiler, hwloc needs to behave
>> as if the system lacks ffs().
>> Making that happen is non-trivial because there are no preprocessor
>> symbols defined by gccfss that would allow compile-time #if checks to
>> distinguish gccfss from "vanilla" gcc. The only difference is in the
>> string value of __VERSION__, which one could check at configure time.
> Attached is a patch, relative to the svn trunk, which fixes this
> problem in my testing.
> As I outlined above, the approach is two-fold:
> 1) Add configure-time logic to ID the buggy compiler
> 2) Restructure include/private/misc.h to include a
> Two things I'd like to note about the approach:
> + The configure-time logic is NOT trying to determine the version
> number, as I don't have a way (yet?) to pinpoint which version(s) work
> correctly, and the Oracle Forums thread on the subject doesn't say.
> So, it is conservatively assuming all "gccfss" versions are broken.
> + The misc.h changes are intentionally "generic" so one could add
> other configure time checks to define HWLOC_HAVE_BROKEN_FFS based on
> problems we've not yet discovered.
> -Paul
> _______________________________________________
> hwloc-devel mailing list
> hwloc-devel_at_[hidden]