Re: [Bug-gsl] SV decomp failure

[Steve Brosnan]

Hi Rhys,

I believe that I've done as you requested. I downloaded the GSL versions 1.14, 
1.13, 1.12, and 1.11, did the './configure && make && make -C linalg check' 
sequence, and found that all versions failed in the same way as before.

One caveat -- since my last message I have upgraded my iMac with quad-core i5 
to Mountain Lion (OS X 10.8.2). As an aside, I found that this process erased 
any compilers accessible from the command line. This was upsetting, until I 
learned that these tools could be restored by doing a download/install of the 
'command line tools' from within Xcode. After doing that the compiler that 
'gcc' symbolically links to is still listed as llvm-gcc-4.2, but I have no 
record of pre-upgrade build number or whatever. I do not think that there has 
been any substantive change, so I think that the current tests are indeed 
comparing apples and apples. (Sheepish grin ;-)

Does this mean that the problem is the llvm-gcc compiler?

I just verified that the linalg check of gsl-1.15 succeeds on a 2009 Macbook 
Pro with OS X 10.6.8 and a Core-2 Duo processor. However, gcc is linked to 
gcc-4.2, not llvm-gcc-4.2. Doing 'gcc -v' yields 'gcc version 4.2.1 (Apple Inc. 
build 5666) (dot 3)'. For comparison, 'gcc -v' on the iMac with OS X 10.8.2 
yields 'gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 
2336.11.00)'. 

What follows is my personal opinion/appraisal:  

It seems that Apple is diverging away from gcc compiler code. Perhaps they 
think that LLVM or the Clang compiler does a better job (perhaps in the case of 
multicore processors?) and so do not want to be tied to gnu as progress occurs. 
If so, then some more drastic change may be needed in the gsl ./configure stage 
to allow the use of a different compiler. However, this may be hard, since I 
(after a non-exhaustive search) could not find the location of the Clang 
compiler, which is now the preferred/default in Xcode. And it very well may be 
that the Clang compiler is not interoperable with gcc command-line syntax.

What is left for the Mac numerics person to do? One obvious, if painful, 
solution is to build gsl from within Xcode. I wonder if it is practical to 
distribute such an Xcode project in a .zip file? After all, Xcode is free from 
Apple, and a Mac person is likely to be doing his/her computation from within 
Xcode anyway. I realize that this diverges from the pure unix way, but perhaps 
the time has come? Just a thought...  Humble apologies to folks for whom this 
would royally screw up their workflow.

That's all I have. If I can do more, I will do my best.

Steve


On Oct 25, 2012, at 7:36 AM, Rhys Ulerich <address@hidden> wrote:

> Hi Steve,
> 
>> But in the meantime, Mac people can use the 'export CFLAGS="-Os -g"' trick.
>> 
>> Hope this helps. If you have other suggestions, I will do the best I can.
> 
> I do have a thought.
> 
> Would you try compiling a couple of older GSL versions (say, working
> from 1.14 down to 1.11) without the CFLAGS trick and seeing if
> './configure && make && make -C linalg check' passes?  That will build
> everything but just run the directory with the failing SVD test.
> 
> My thought is that maybe (small probability) the problem is a
> regression.  If we can identify it working at some time but
> subsequently failing, we can bisect our way down to the troublesome
> commit.
> 
> - Rhys