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?
thanks
Brice
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
HWLOC_HAVE_BROKEN_FFS case.
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@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
_______________________________________________
hwloc-devel mailing list
hwloc-devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel