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 <[email protected]>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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected] >>>>>> > >>>>>> 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 >>>>>>>> >>>>>>>> >>>> >> > >
