My $0.02 is that we should disable FFS on all versions of that compiler. It's
not like this is performance-critical code. I'd rather it be "slow" and
guaranteed correct than fast and maybe wrong.
Meaning: I'm good with Paul's patch. I'll commit, since no one has posted any
alternatives.
Paul H. Hargrove, le Thu 02 Feb 2012 02:29:08 +0100, a écrit :
> + 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
>
>Would that work?
Nope, I tried to address that question in a comment in the patch.
The link succeeds and the problem only occurs when the executable is RUN.
So one would need AC_TRY_RUN; and then one has openned the the
cross-compilation can-of-worms.
-Paul
On 2/1/2012 9:51 PM, Brice
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?
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
The problem I described below is ALSO present in hwloc-1.4
-Paul
On 1/31/2012 4:57 PM, Paul H. Hargrove wrote:
This report is the flip-side of the problem w/ Solaris Studio
compilers on x86-64.
With Solaris-10 on SPARC, I find I *can* build hwloc-1.3.1 w/ SS12.x,
but instead am failing w/ gcc.
