Re: [Help-gsl] Compiling Testing New Interpolation Type
Oh my god, I just noticed that I was trying to use version 1.6 all along, not 1.16! I finally noticed when I tried using the same grep commands as Dave Allured to summarize the tests, but zero lines from my test log were matching, so I looked more closely. 1.6 doesn’t have DARWIN86 as one of the ieee-utils options, hence why stuff wasn’t working. Not to excuse my lack of attention/stupidity, but on the main GSL page it says in text that the current version is 1.16, but the download link goes to a plain index page that includes tons of versions - including future versions that are probably not expected to work. Is it possible to add a single link to the current version on the main page, or in the FTP listing, have a duplicate entry for 1.16 which is explicitly called CURRENT or something? When I use 1.16 everything works out of the box. Sorry for the noise. (1.6 did work out of the box on an Ubuntu 12 machine that I tried). My original problem was that I wanted to add an interpolation type to GSL. Specifically I want monotonic cubic-splines following the description in Steffen (1990): http://adsabs.harvard.edu/full/1990A%26A...239..443S I have successfully written a steffen.c file, modelled after akima.c. It compiles and seems to do the interpolation correctly with my basic (non-automated) tests. I am wondering now what are the steps to trying to get my enhancement included in gsl itself? Things like code review, style checking, etc. I’ve never contributed actual code to an open-source project before, so I might need some hand-holding. Should I start a new thread about this? I read somewhere that GSL is considered “feature complete”, but I’ve seen other people asking for monotonic interpolation from GSL before, and it’s just a new 9407 byte file and some trivial additions to gsl_interp.h and the configuration files. I hope it’s an appropriate (and welcome) addition to GSL. Jean-François On Mar 19, 2014, at 18:40 , Dave Allured - NOAA Affiliate dave.allu...@noaa.gov wrote: More data. I tried the same plain build recipe, GSL 1.16 on our test machine which is at Mac OS 10.9.3. Got another perfect build, no make check errors, no PPC-related issues. Outputs on request, please be specific. CC=clang CFLAGS=-g ./configure --prefix /Users/dallured/Disk/3rd/gsl/1.16.os10.9 mac27:~/Disk/3rd/gsl/1.16.os10.9 57 sw_vers ProductName: Mac OS X ProductVersion: 10.9.3 BuildVersion: 13D17 mac27:~/Disk/3rd/gsl/1.16.os10.9/src 36 \ ? grep -i '# [a-z]' ../logfiles/make-check.0319a.log | sort | uniq -c 45 # ERROR: 0 45 # FAIL: 0 42 # PASS: 1 3 # PASS: 2 45 # SKIP: 0 42 # TOTAL: 1 3 # TOTAL: 2 45 # XFAIL: 0 45 # XPASS: 0 mac27:~/Disk/3rd/gsl/1.16.os10.9 62 \ ? grep -c -i ppc logfiles/*319a*log logfiles/configure.0319a.os10.9.log:0 logfiles/install.0319a.log:0 logfiles/make-check.0319a.log:0 logfiles/make.0319a.log:0 mac27:~/Disk/3rd/gsl/1.16.os10.9 65 \ ? grep -i ppc src/config.h src/config.log src/config.status src/config.h:/* #undef HAVE_GNUPPC_IEEE_INTERFACE */ src/config.log:HAVE_GNUPPC_IEEE_INTERFACE='' src/config.status:S[HAVE_GNUPPC_IEEE_INTERFACE]= --Dave On Wed, Mar 19, 2014 at 5:27 PM, Jean-Francois Caron jfca...@phas.ubc.ca wrote: 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
Re: [Help-gsl] Compiling Testing New Interpolation Type
I did notice you talking about 1.6 in your earlier messages, but assumed it was a typo and you meant 1.16, oops. On 03/20/2014 11:11 AM, Jean-François Caron wrote: My original problem was that I wanted to add an interpolation type to GSL. Specifically I want monotonic cubic-splines following the description in Steffen (1990): http://adsabs.harvard.edu/full/1990A%26A...239..443S I took a quick look at your code earlier and it looks pretty nice. I noticed you commented out the _integ function - is this something you could add to make it feature complete with the other interpolation types? It is important to add automated tests for this. Can you look at interpolation/test.c and design similar tests for your new method? Also I think it would be nice to add a figure to the manual illustrating the differences between cubic, akima, and your new steffen method (similar to the figures in the Steffen paper). This would help users a lot when trying to decide what method to use. Do you happen to have a dataset which shows a nice contrast like Figs 1, 3 and 8 from that paper? When everything is ready I would be happy to add it to GSL, as we are already planning to update the interpolation module for the next release. When I find some time I want to import the 2D interpolation extension discussed previously, and also add Hermite interpolation. It would be easiest for us if you could clone the GSL git repository and make your changes there. You could make a new branch called 'steffen' or something and publish it to github, or just send a patch file to me, whichever is easiest. Patrick On Mar 19, 2014, at 18:40 , Dave Allured - NOAA Affiliate dave.allu...@noaa.gov wrote: More data. I tried the same plain build recipe, GSL 1.16 on our test machine which is at Mac OS 10.9.3. Got another perfect build, no make check errors, no PPC-related issues. Outputs on request, please be specific. CC=clang CFLAGS=-g ./configure --prefix /Users/dallured/Disk/3rd/gsl/1.16.os10.9 mac27:~/Disk/3rd/gsl/1.16.os10.9 57 sw_vers ProductName: Mac OS X ProductVersion: 10.9.3 BuildVersion: 13D17 mac27:~/Disk/3rd/gsl/1.16.os10.9/src 36 \ ? grep -i '# [a-z]' ../logfiles/make-check.0319a.log | sort | uniq -c 45 # ERROR: 0 45 # FAIL: 0 42 # PASS: 1 3 # PASS: 2 45 # SKIP: 0 42 # TOTAL: 1 3 # TOTAL: 2 45 # XFAIL: 0 45 # XPASS: 0 mac27:~/Disk/3rd/gsl/1.16.os10.9 62 \ ? grep -c -i ppc logfiles/*319a*log logfiles/configure.0319a.os10.9.log:0 logfiles/install.0319a.log:0 logfiles/make-check.0319a.log:0 logfiles/make.0319a.log:0 mac27:~/Disk/3rd/gsl/1.16.os10.9 65 \ ? grep -i ppc src/config.h src/config.log src/config.status src/config.h:/* #undef HAVE_GNUPPC_IEEE_INTERFACE */ src/config.log:HAVE_GNUPPC_IEEE_INTERFACE='' src/config.status:S[HAVE_GNUPPC_IEEE_INTERFACE]= --Dave On Wed, Mar 19, 2014 at 5:27 PM, Jean-Francois Caron jfca...@phas.ubc.ca wrote: 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
Re: [Help-gsl] Compiling Testing New Interpolation Type
Yes, I didn’t bother doing the integration function at the time because I was having trouble just compiling. I will add the integration function, and re-write the eval and deriv/deriv2 functions to use Horner’s scheme for the polynomials. I can generate some comparison graphs using fake data like in Steffen’s paper, that sounds easy enough. I’ll look at the interpolation/test.c file and see if I can come up with similar tests. Thanks for offering to help with the integration into GSL itself. I don’t know a lot of the procedures (or even politics sometimes!) involved. Jean-François On Mar 20, 2014, at 10:22 , Patrick Alken patrick.al...@colorado.edu wrote: I did notice you talking about 1.6 in your earlier messages, but assumed it was a typo and you meant 1.16, oops. On 03/20/2014 11:11 AM, Jean-François Caron wrote: My original problem was that I wanted to add an interpolation type to GSL. Specifically I want monotonic cubic-splines following the description in Steffen (1990): http://adsabs.harvard.edu/full/1990A%26A...239..443S I took a quick look at your code earlier and it looks pretty nice. I noticed you commented out the _integ function - is this something you could add to make it feature complete with the other interpolation types? It is important to add automated tests for this. Can you look at interpolation/test.c and design similar tests for your new method? Also I think it would be nice to add a figure to the manual illustrating the differences between cubic, akima, and your new steffen method (similar to the figures in the Steffen paper). This would help users a lot when trying to decide what method to use. Do you happen to have a dataset which shows a nice contrast like Figs 1, 3 and 8 from that paper? When everything is ready I would be happy to add it to GSL, as we are already planning to update the interpolation module for the next release. When I find some time I want to import the 2D interpolation extension discussed previously, and also add Hermite interpolation. It would be easiest for us if you could clone the GSL git repository and make your changes there. You could make a new branch called 'steffen' or something and publish it to github, or just send a patch file to me, whichever is easiest. Patrick On Mar 19, 2014, at 18:40 , Dave Allured - NOAA Affiliate dave.allu...@noaa.gov wrote: More data. I tried the same plain build recipe, GSL 1.16 on our test machine which is at Mac OS 10.9.3. Got another perfect build, no make check errors, no PPC-related issues. Outputs on request, please be specific. CC=clang CFLAGS=-g ./configure --prefix /Users/dallured/Disk/3rd/gsl/1.16.os10.9 mac27:~/Disk/3rd/gsl/1.16.os10.9 57 sw_vers ProductName: Mac OS X ProductVersion: 10.9.3 BuildVersion: 13D17 mac27:~/Disk/3rd/gsl/1.16.os10.9/src 36 \ ? grep -i '# [a-z]' ../logfiles/make-check.0319a.log | sort | uniq -c 45 # ERROR: 0 45 # FAIL: 0 42 # PASS: 1 3 # PASS: 2 45 # SKIP: 0 42 # TOTAL: 1 3 # TOTAL: 2 45 # XFAIL: 0 45 # XPASS: 0 mac27:~/Disk/3rd/gsl/1.16.os10.9 62 \ ? grep -c -i ppc logfiles/*319a*log logfiles/configure.0319a.os10.9.log:0 logfiles/install.0319a.log:0 logfiles/make-check.0319a.log:0 logfiles/make.0319a.log:0 mac27:~/Disk/3rd/gsl/1.16.os10.9 65 \ ? grep -i ppc src/config.h src/config.log src/config.status src/config.h:/* #undef HAVE_GNUPPC_IEEE_INTERFACE */ src/config.log:HAVE_GNUPPC_IEEE_INTERFACE='' src/config.status:S[HAVE_GNUPPC_IEEE_INTERFACE]= --Dave On Wed, Mar 19, 2014 at 5:27 PM, Jean-Francois Caron jfca...@phas.ubc.ca wrote: 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
Re: [Help-gsl] Compiling Testing New Interpolation Type
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/msg9.html
Re: [Help-gsl] Compiling Testing New Interpolation Type
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
Re: [Help-gsl] Compiling Testing New Interpolation Type
This may be of some help for debugging. i would like to report a
problem-free build of GSL 1.16 on Mac OS. I sent this to
Jean-François yesterday,
but forgot to CC the mailing list.
One significant difference is that Jean-François's Mac OS version is 10.9.2,
mine is 10.8.5.
I used clang, the LLVM/Apple C compiler, not GCC which sometimes gives me
invalid dynamic libraries on Mac. I think that GCC would be fine if you
are just making a static build. However, I made and tested the combined
static and dynamic build, which is the package default.
I made no modifications whatsoever to the GSL 1.16 source. There were no
problems with either make check or my application program which uses the
dynamic library.
CC=clang
CFLAGS=-g
./configure --prefix /Users/dallured/Disk/3rd/gsl/1.16
Then the usual autotools recipe: make, make check, make install. No sudo
because I install to a custom path in my user space.
Platform info:
mac56:~/Disk/3rd/gsl/1.16/logfiles 9 sw_vers
ProductName: Mac OS X
ProductVersion: 10.8.5
BuildVersion: 12F45
mac56:~/Disk/3rd/gsl/1.16/logfiles 10 clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
I have no idea where the PPC complaints are coming from. I can send or
post my configure and build logs, if that would be of any help
--Dave
On Wed, Mar 19, 2014 at 12:37 PM, Jean-François Caron
jfca...@phas.ubc.cawrote:
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
Re: [Help-gsl] Compiling Testing New Interpolation Type
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
Re: [Help-gsl] Compiling Testing New Interpolation Type
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
Re: [Help-gsl] Compiling Testing New Interpolation Type
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.eduwrote: 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
Re: [Help-gsl] Compiling Testing New Interpolation Type
Can you try uncommenting the line in config.h: #define HAVE_DARWIN86_IEEE_INTERFACE 1 and see if make check works? If this works then we just need to modify autoconf to correctly identify x86 vs ppc. Also it would help if you could post the entire output of ./configure On 03/19/2014 05:27 PM, Jean-Francois Caron wrote: 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.eduwrote: 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]:
Re: [Help-gsl] Compiling Testing New Interpolation Type
More data. I tried the same plain build recipe, GSL 1.16 on our test machine which is at Mac OS 10.9.3. Got another perfect build, no make check errors, no PPC-related issues. Outputs on request, please be specific. CC=clang CFLAGS=-g ./configure --prefix /Users/dallured/Disk/3rd/gsl/1.16.os10.9 mac27:~/Disk/3rd/gsl/1.16.os10.9 57 sw_vers ProductName: Mac OS X ProductVersion: 10.9.3 BuildVersion: 13D17 mac27:~/Disk/3rd/gsl/1.16.os10.9/src 36 \ ? grep -i '# [a-z]' ../logfiles/make-check.0319a.log | sort | uniq -c 45 # ERROR: 0 45 # FAIL: 0 42 # PASS: 1 3 # PASS: 2 45 # SKIP: 0 42 # TOTAL: 1 3 # TOTAL: 2 45 # XFAIL: 0 45 # XPASS: 0 mac27:~/Disk/3rd/gsl/1.16.os10.9 62 \ ? grep -c -i ppc logfiles/*319a*log logfiles/configure.0319a.os10.9.log:0 logfiles/install.0319a.log:0 logfiles/make-check.0319a.log:0 logfiles/make.0319a.log:0 mac27:~/Disk/3rd/gsl/1.16.os10.9 65 \ ? grep -i ppc src/config.h src/config.log src/config.status src/config.h:/* #undef HAVE_GNUPPC_IEEE_INTERFACE */ src/config.log:HAVE_GNUPPC_IEEE_INTERFACE='' src/config.status:S[HAVE_GNUPPC_IEEE_INTERFACE]= --Dave On Wed, Mar 19, 2014 at 5:27 PM, Jean-Francois Caron jfca...@phas.ubc.ca wrote: 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
Re: [Help-gsl] Compiling Testing New Interpolation Type
I figured the first thing someone would ask is to show the code, so I am
pre-empting that here:
http://bazaar.launchpad.net/~jfcaron/+junk/my_steffen/view/head:/steffen.c
Jean-François
On Mar 18, 2014, at 16:47 , Jean-François Caron jfca...@phas.ubc.ca 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/msg9.html
Re: [Help-gsl] Compiling Testing New Interpolation Type
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/msg9.html
