Dave is correct, I am using an "i686" 64-bit x86 mac. For some reason it is still looking for the PPC mac header file. The ./configure stage correctly identifies my system, so it's a bit strange. Also GSL installs without errors when I do it from MacPorts, and MacPorts doesn't seem to do anything other than ./configure && make, from my reading of the portfile.
When I get back to my Mac, I will look at the NOTES file to see if anything needs to be done for 10.9. Jean-François On 3/19/14, Dave Allured - NOAA Affiliate <dave.allu...@noaa.gov> wrote: > Confusion? The OP said he has an x86 mac, not a PPC mac. I don't think > you want to be chasing down a PPC architecture file for this one, unless I > am the one confused. > > --Dave > > > On Wed, Mar 19, 2014 at 4:01 PM, Patrick Alken > <patrick.al...@colorado.edu>wrote: > >> also the ieee-utils/NOTES file contains some useful info on adding >> support >> for your machine; hopefully the new MacOS version didn't change the fpu >> interface too drastically >> >> On 03/19/2014 03:55 PM, Patrick Alken wrote: >> >>> Unfortunately that code in ieee-utils is completely platform dependent >>> and relies on OS-specific header files (architecture/ppc/fp-regs.h in >>> the case of powerpc-darwin). When an OS upgrades and changes those >>> header files it would break the GSL build since there is no portable way >>> to handle it. >>> >>> I found a copy of that particular header file here: >>> >>> http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/ >>> EXTERNAL_HEADERS/architecture/ppc/fp_regs.h >>> >>> Maybe you could look around on your system and see if you can find the >>> corresponding file, then you could modify ieee-utils/fp-darwin.c to >>> point to the correct header file. >>> >>> I suppose we could add an autoconf check for this header file when a >>> darwin host is detected. Its difficult for me to do this since I don't >>> have a similar machine to test it on. >>> >>> Patrick >>> >>> On 03/19/2014 03:39 PM, Jean-Francois Caron wrote: >>> >>>> Weird, it definitely failed 2 tests before, but I guess when I re-ran >>>> it (to get the stuff to paste), the failures were no longer present. >>>> Or maybe it was after "make install"? After a bunch of tests, I still >>>> get this linker error when doing "make check": >>>> >>>> Making check in siman >>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make test >>>> /bin/sh ../libtool --mode=link /usr/bin/clang -g -o test test.o >>>> libgslsiman.la ../rng/libgslrng.la ../ieee-utils/libgslieeeutils.la >>>> ../err/libgslerr.la ../test/libgsltest.la ../sys/libgslsys.la >>>> ../utils/libutils.la -lm >>>> /usr/bin/clang -g -o test test.o ./.libs/libgslsiman.a >>>> ../rng/.libs/libgslrng.a ../ieee-utils/.libs/libgslieeeutils.a >>>> ../err/.libs/libgslerr.a ../test/.libs/libgsltest.a >>>> ../sys/.libs/libgslsys.a ../utils/.libs/libutils.a -lm >>>> Undefined symbols for architecture x86_64: >>>> "_square", referenced from: >>>> _E1 in test.o >>>> ld: symbol(s) not found for architecture x86_64 >>>> clang: error: linker command failed with exit code 1 (use -v to see >>>> invocation) >>>> make[2]: *** [test] Error 1 >>>> make[1]: *** [check-am] Error 2 >>>> make: *** [check-recursive] Error 1 >>>> >>>> But that's definitely from commenting out the ieee-utils section of >>>> config.h as recommended in that old post I linked. >>>> >>>> Before I try to write a "how I got this to work" guide, I'll start >>>> over from scratch to make sure I got everything right. >>>> >>>> Jean-François >>>> >>>> On 3/19/14, Patrick Alken <patrick.al...@colorado.edu> wrote: >>>> >>>>> I don't see the make check failures in your bpaste.net post, if there >>>>> are only 2 could you post them to the list? >>>>> >>>>> It sounds like you fixed your compile issues - could you write a short >>>>> text on exactly what you did so I can add it to the INSTALL file to >>>>> help >>>>> others down the road? Do you think there is an autoconf check that >>>>> could >>>>> detect the problem and automatically adjust the config.h to compile >>>>> correctly? >>>>> >>>>> Perhaps you could run 'make check' under 'script' and send me the >>>>> typescript file so I can see the exact errors you are getting. >>>>> >>>>> Patrick >>>>> >>>>> On 03/19/2014 12:37 PM, Jean-François Caron wrote: >>>>> >>>>>> I eventually found this post: >>>>>> http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/173 >>>>>> >>>>>> After doing the suggested commenting, GSL now fully completes "make", >>>>>> but >>>>>> "make check" claims to find two errors, here is the log: >>>>>> http://bpaste.net/show/190944/ >>>>>> >>>>>> "make check" also prints a bunch of warnings about printf format >>>>>> strings >>>>>> on stderr, but more worryingly, at the end it also prints this to >>>>>> stderr: >>>>>> 94 warnings generated. >>>>>> Undefined symbols for architecture x86_64: >>>>>> "_square", referenced from: >>>>>> _E1 in test.o >>>>>> ld: symbol(s) not found for architecture x86_64 >>>>>> clang: error: linker command failed with exit code 1 (use -v to see >>>>>> invocation) >>>>>> make[2]: *** [test] Error 1 >>>>>> make[1]: *** [check-am] Error 2 >>>>>> make: *** [check-recursive] Error 1 >>>>>> >>>>>> So I guess it couldn't compile one of the test programs? >>>>>> >>>>>> After "make install", I tried "make check" again, and now I get: >>>>>> test_static(20591,0x7fff73220310) malloc: *** error for object >>>>>> 0x7f9420500128: incorrect checksum for freed object - object was >>>>>> probably >>>>>> modified after being freed. >>>>>> *** set a breakpoint in malloc_error_break to debug >>>>>> /bin/sh: line 1: 20591 Abort trap: 6 ${dir}$tst >>>>>> FAIL: test_static >>>>>> >>>>>> Should I be worried about these tests failing, or can I ignore them >>>>>> and >>>>>> proceed to try to integrate my code into GSL? >>>>>> >>>>>> Jean-François >>>>>> >>>>>> On Mar 19, 2014, at 10:29 , Jean-François Caron <jfca...@phas.ubc.ca> >>>>>> wrote: >>>>>> >>>>>> Make is the command that is failing. I do the following: >>>>>>> CC=/usr/bin/clang CFLAGS=-g ./configure --disable-shared >>>>>>> --prefix=/Users/jfcaron/Projects/GSL/compiled >>>>>>> make >>>>>>> >>>>>>> I use --disable-shared because the MacOS section of INSTALL >>>>>>> recommends it, >>>>>>> but removing it changes nothing. >>>>>>> >>>>>>> Many things are compiled (with clang), and eventually I reach this >>>>>>> error >>>>>>> message: >>>>>>> Making all in ieee-utils >>>>>>> /bin/sh ../libtool --mode=compile /usr/bin/clang -DHAVE_CONFIG_H -I. >>>>>>> -I. >>>>>>> -I.. -I.. -g -c -o print.lo `test -f 'print.c' || echo >>>>>>> './'`print.c >>>>>>> /usr/bin/clang -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -c print.c -o >>>>>>> print.o >>>>>>> echo timestamp > print.lo >>>>>>> /bin/sh ../libtool --mode=compile /usr/bin/clang -DHAVE_CONFIG_H -I. >>>>>>> -I. >>>>>>> -I.. -I.. -g -c -o make_rep.lo `test -f 'make_rep.c' || echo >>>>>>> './'`make_rep.c >>>>>>> /usr/bin/clang -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -c make_rep.c -o >>>>>>> make_rep.o >>>>>>> echo timestamp > make_rep.lo >>>>>>> /bin/sh ../libtool --mode=compile /usr/bin/clang -DHAVE_CONFIG_H -I. >>>>>>> -I. >>>>>>> -I.. -I.. -g -c -o env.lo `test -f 'env.c' || echo './'`env.c >>>>>>> /usr/bin/clang -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -c env.c -o >>>>>>> env.o >>>>>>> echo timestamp > env.lo >>>>>>> /bin/sh ../libtool --mode=compile /usr/bin/clang -DHAVE_CONFIG_H -I. >>>>>>> -I. >>>>>>> -I.. -I.. -g -c -o fp.lo `test -f 'fp.c' || echo './'`fp.c >>>>>>> /usr/bin/clang -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -c fp.c -o fp.o >>>>>>> In file included from fp.c:34: >>>>>>> ./fp-darwin.c:20:10: fatal error: 'architecture/ppc/fp_regs.h' file >>>>>>> not >>>>>>> found >>>>>>> #include <architecture/ppc/fp_regs.h> >>>>>>> ^ >>>>>>> 1 error generated. >>>>>>> make[2]: *** [fp.lo] Error 1 >>>>>>> make[1]: *** [all-recursive] Error 1 >>>>>>> make: *** [all] Error 2 >>>>>>> >>>>>>> I have read the INSTALL sections about MacOS and PPC platforms, but >>>>>>> they >>>>>>> don't seem to be relevant to this issue. The compilation error >>>>>>> occurs >>>>>>> while making the ieee-utils target, in the file fp-darwin.c. It >>>>>>> seems >>>>>>> that something expects all MacOS hosts to still be PPC machines? >>>>>>> The >>>>>>> ./configure step is able to figure it out: >>>>>>> >>>>>>> checking build system type... i686-apple-darwin13.1.0 >>>>>>> >>>>>>> Here is the output of sw_vers and clang -v on my system: >>>>>>> >>>>>>> jfcaron@dhcp-128-189-78-242:~/Projects/GSL/gsl-1.6$ sw_vers >>>>>>> ProductName: Mac OS X >>>>>>> ProductVersion: 10.9.2 >>>>>>> BuildVersion: 13C64 >>>>>>> jfcaron@dhcp-128-189-78-242:~/Projects/GSL/gsl-1.6$ clang -v >>>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>>> Target: x86_64-apple-darwin13.1.0 >>>>>>> Thread model: posix >>>>>>> >>>>>>> Thanks for the help so far. Let me know if I should paste the >>>>>>> entire >>>>>>> configure & make logs, or if I can provide other information for >>>>>>> figuring >>>>>>> this out. >>>>>>> >>>>>>> Jean-François >>>>>>> >>>>>>> On Mar 18, 2014, at 18:14 , Patrick Alken >>>>>>> <patrick.al...@colorado.edu >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>>> >>>>>>>> Could you be more specific about the errors you are getting? Does >>>>>>>> configure fail or does make fail? >>>>>>>> >>>>>>>> There is also a section on MacOS compilation in the INSTALL file >>>>>>>> (search >>>>>>>> for Hints for MacOS X and PowerPC) >>>>>>>> >>>>>>>> As far as testing, you could edit interpolation/test.c and add a >>>>>>>> new >>>>>>>> routine test_steffen(). >>>>>>>> >>>>>>>> You could also simply write a standalone test program and link it >>>>>>>> again >>>>>>>> the GSL library, without needing to compile it into GSL. >>>>>>>> >>>>>>>> On 03/18/2014 05:47 PM, Jean-François Caron wrote: >>>>>>>> >>>>>>>>> Hi, several times now I've needed a monotonic interpolation >>>>>>>>> method. >>>>>>>>> I >>>>>>>>> saw some posts from 2 years ago on this list from someone who >>>>>>>>> implemented the method from Steffen (1990), but it never got >>>>>>>>> integrated >>>>>>>>> into GSL and I couldn't contact that person. >>>>>>>>> >>>>>>>>> I have now also implemented Steffen's interpolation algorithm by >>>>>>>>> copying the existing akima.c file, but I am quite at a loss as to >>>>>>>>> how >>>>>>>>> to compile & test the code. I normally use GSL installed from >>>>>>>>> MacPorts >>>>>>>>> which handles all the compilation. I tried wget'ing the archive >>>>>>>>> for >>>>>>>>> GSL 1.6 and doing ./configure && make, but then I get errors about >>>>>>>>> the >>>>>>>>> PPC architecture (this is an x86 mac). >>>>>>>>> >>>>>>>>> Could someone walk me through the steps for compiling & testing my >>>>>>>>> steffen.c code? My starting point: >>>>>>>>> - a fresh download and ./configure of GSL 1.6 >>>>>>>>> - steffen.c placed in $GSL/interpolation >>>>>>>>> >>>>>>>>> I don't need people to write the test program itself, I just need >>>>>>>>> to >>>>>>>>> get to something that will compile with "int main(void){return >>>>>>>>> 0;}". I >>>>>>>>> can probably handle the rest of the testing. >>>>>>>>> >>>>>>>>> Thanks for any help, >>>>>>>>> Jean-François Caron >>>>>>>>> >>>>>>>>> Old posts about this: >>>>>>>>> http://lists.gnu.org/archive/html/help-gsl/2012-03/msg00009.html >>>>>>>>> >>>>>>>>> >>>>> >>> >> >> >