Re: [Help-gsl] Compiling & Testing New Interpolation Type

[Patrick Alken]

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 <address@hidden> 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
>> <address@hidden>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 <address@hidden> 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 <address@hidden>
>>>>>>> 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:
>>>>>>>>
>>>>>>>> address@hidden:~/Projects/GSL/gsl-1.6$ sw_vers
>>>>>>>> ProductName:    Mac OS X
>>>>>>>> ProductVersion: 10.9.2
>>>>>>>> BuildVersion:   13C64
>>>>>>>> address@hidden:~/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
>>>>>>>> <address@hidden
>>>>>>>>>
>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
>