bug-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gsl] finite deprecated in OSX, iOS


From: Patrick Alken
Subject: Re: [Bug-gsl] finite deprecated in OSX, iOS
Date: Sun, 02 Feb 2014 18:32:38 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Based on what you've written, it looks like this is a problem with

(a) GNU autoconf 2.69 on the iphone platform
(b) a problem in the GSL configure.ac file which autoconf uses to
generate configure.

I did a quick google search and didn't find much to support (a) so I
wonder which directive in configure.ac is causing these problems.

One way to find out would be to make a barebones configure.ac, generate
a configure, and run it. Then add back in directives until you reproduce
that error with the __arm__ define. That at least would tell us what is
causing that problem so we can talk to the autoconf people about it. It
looks like the last autoconf release was april 2012 so I don't know if
its even being developed any more.

Patrick

On 02/02/2014 03:37 PM, Jeff E Mandel wrote:
> After extensive work on this, I’m starting to believe that the problem isn’t 
> finite(), but rather that configure failed, so make doesn’t have the correct 
> flags. Here’s my configuration:
> 
>> It was created by gsl configure 1.16, which was
>> generated by GNU Autoconf 2.69.  Invocation command line was
>>
>>   $ ./configure --host=armv7-apple-darwin --disable-dependency-tracking 
>> --enable-shared=no 
>> CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>>  CFLAGS=-arch armv7 --sysroot 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
>>  -miphoneos-version-min=7.0 CPPFLAGS=-pipe -no-cpp-precomp 
>> -Wno-deprecated-declarations 
>> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/
>>
>> ## --------- ##
>> ## Platform. ##
>> ## --------- ##
>>
>> hostname = Mandel-MacBook-Pro-Retina.local
>> uname -m = x86_64
>> uname -r = 13.0.2
>> uname -s = Darwin
>> uname -v = Darwin Kernel Version 13.0.2: Sun Sep 29 19:38:57 PDT 2013; 
>> root:xnu-2422.75.4~1/RELEASE_X86_64
>>
>> /usr/bin/uname -p = i386
>> /bin/uname -X     = unknown
>>
>> /bin/arch              = unknown
>> /usr/bin/arch -k       = unknown
>> /usr/convex/getsysinfo = unknown
>> /usr/bin/hostinfo      = Mach kernel version:
>>       Darwin Kernel Version 13.0.2: Sun Sep 29 19:38:57 PDT 2013; 
>> root:xnu-2422.75.4~1/RELEASE_X86_64
>> Kernel configured for up to 8 processors.
>> 4 processors are physically available.
>> 8 processors are logically available.
>> Processor type: i486 (Intel 80486)
>> Processors active: 0 1 2 3 4 5 6 7
>> Primary memory available: 16.00 gigabytes
>> Default processor set: 256 tasks, 1412 threads, 8 processors
>> Load average: 1.60, Mach factor: 6.38
>> /bin/machine           = unknown
>> /usr/bin/oslevel       = unknown
>> /bin/universe          = unknown
>>
>> PATH: /opt/local/bin
>> PATH: /opt/local/sbin
>> PATH: /usr/bin
>> PATH: /bin
>> PATH: /usr/sbin
>> PATH: /sbin
>> PATH: /usr/local/bin
>>
> 
> Note that I have MacPorts installed, so I have gcc available if I compile for 
> MacOS.
> 
>  This is how I’m invoking configure:
> 
> ./configure --host=armv7-apple-darwin --disable-dependency-tracking 
> --enable-shared=no \
> CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>  \
> CFLAGS="-arch armv7 --sysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk
>  -miphoneos-version-min=7.0" \
> CPPFLAGS="-pipe -no-cpp-precomp -Wno-deprecated-declarations 
> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/"
> 
> I have played around with the -arch, tried -target, but no significant 
> difference. In config.log, I see:
> 
>> configure:4209: 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>>  -pipe -no-cpp-precomp -Wno-deprecated-declarations 
>> -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/
>>  conftest.c
>> In file included from conftest.c:13:
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/limits.h:63:
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/sys/cdefs.h:655:2:
>>  error: Unsupported architecture
>> #error Unsupported architecture
>>  ^
>> In file included from conftest.c:13:
>> In file included from 
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/limits.h:64:
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/machine/limits.h:8:2:
>>  error: architecture not supported
>> #error architecture not supported
>>  ^
>> conftest.c:17:8: error: unknown type name 'Syntax'
>>                      Syntax error
>>                      ^
>> conftest.c:17:20: error: expected ';' after top level declarator
>>                      Syntax error
>>                                  ^
>>                                  ;
>> 4 errors generated.
> 
> 
> Now, looking at limits.h, I see:
> 
>> #if   defined (__arm__) || defined (__arm64__)
>> #include <arm/limits.h>
>> #else
>> #error architecture not supported
>> #endif
> 
> 
> Which I take to mean that somehow __arm__ is failing to be defined. I’ve 
> tried things like -D__arm__ to no avail. If I add the definition at line 4202 
> in configure:
> #define __arm__
> 
> The “architecture not supported” error goes away, but since I’ve already told 
> configure that I’m using armv7-apple-darwin, this seems unnecessary. 
> 
> The other confusion point is why the “Syntax error” causes clang to die. If I 
> just use ./configure, that line is passed to gcc, which performs as expected, 
> configure proceeds to completion, and make succeeds. If I use clang:
> 
> ./configure \
> CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>  \
> CPPFLAGS="-pipe -no-cpp-precomp --sysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform"
> 
> It dies as well:
> 
>> configure:3478: checking whether the C compiler works
>> configure:3500: 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>>   -pipe -no-cpp-precomp --sysroot 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform  
>> conftest.c  >&5
>> ld: library not found for -lSystem
> 
> 
> OK, I could set -l, but I shouldn’t have to if I specify sysroot, correct?
> 
> So I seem to have 2 issues: __arm__ not being defined, and clang not playing 
> well with your configure file. Having said all of this, if I patch every 
> occurrence of finite() and gsl_finite() in gsl, and compile with clang, I get 
> a library that runs on my iPhone. Go figure. Since I need the app for a demo 
> of our technology tomorrow, and in the long term, we will have to move away 
> from GSL for anything we want to put in the App Store, I’m not sure I’ll work 
> on it any more. Except for being tenacious.
> 
> Thanks for any insight into this.
> 
> Jeff E Mandel MD MS
> Assistant Professor of Anesthesiology
> Perelman School of Medicine at the University of Pennsylvania
> 
> On Jan 30, 2014, at 7:58 PM, Peter Johansson <address@hidden> wrote:
> 
>> Hi Jeff,
>>
>> Please keep gsl list in cc, especially since I'm not maintainer and it's 
>> probably useful for Patrick et al. to see your emails (not to mention other 
>> users). 
>>
>> On 01/30/2014 10:33 PM, Mandel Jeff E MD MS wrote:
>>>
>>> Predictive spell checking munged the text; that should be "isfinite", 
>>> "gsl_finite", …
>>>
>>> Jeff
>>>
>>> Begin forwarded message:
>>>
>>>> From: Jeff E Mandel <address@hidden>
>>>> Subject: Re: [Bug-gsl] finite deprecated in OSX, iOS
>>>> Date: January 30, 2014 6:27:28 AM EST
>>>> To: Peter Johansson <address@hidden>
>>>>
>>>> Configure completes; it fails during Make. I can trace it down to a single 
>>>> compiler level, for instance:
>>>>
>>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>>>>   -I.. -I/usr/include/ -c gsl-1.16/poly/balance.c -o 
>>>> gsl-1.16/poly/balance.o
>>>>
>>>> balance.c:57:24: error: 'gsl_finite' is unavailable: not available on iOS
>>>>       if (s == 0.0 || !gsl_finite(s))
>>
>> This looks very wrong. It looks like the compiler thinks that gsl_finite is 
>> not available. My guess is that it's the deprecation of finite() that 
>> somehow pollutes and effects gsl_finite() too. It's hard to know though 
>> because I cannot find any definition of macro __OSX_AVAILABLE_BUT_DEPRECATED
>>
>>>>                        ^
>>>> ../gsl/gsl_sys.h:45:5: note: function has been explicitly marked 
>>>> unavailable here
>>>> int gsl_finite (const double x);
>>>>     ^
>>
>> And this is not true; the GSL developers has not marked gsl_finite as 
>> unavailable. Again it seems like the compiler is very confused, and 
>> typically this kind of compiler confusion is caused by the preprocessor and 
>> macros trespassing and affecting unexpected parts of the code.
>>
>>>> 1 error generated.
>>>> make[2]: *** [balance.lo] Error 1
>>>> make[1]: *** [all-recursive] Error 1
>>>> make: *** [all] Error 2
>>>>
>>>> will emit that error. If I go into balance.c and replace the calls to 
>>>> finite() with infinite(), t compiles. I also had to do this for the 
>>>> gel_finite() calls, but when I did this for every occurrence in gsl, it 
>>>> succeeded in Make.
>> Yes, that makes sense. As Patrick explained in other email, your fix is not 
>> acceptable to go into GSL though because the reason gsl_finite exists is to 
>> support both modern systems with isfinite and ancient systems with finite(). 
>>
>> The config.h you provided indicates that on your systems the configure 
>> script has detected that you have a function isfinite() but not a finite(). 
>> Hopefully Patrick's last modification fixes you problem (please try) but I 
>> doubt it because it only changes things cquad.c which should not influence 
>> your problems compiling 'balance.c'. If it doesn't work, it might help if 
>> you could find a definition of __OSX_AVAILABLE_BUT_DEPRECATED or if you 
>> could attach the output from 
>>
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>>   -E -I.. -I/usr/include/ gsl-1.16/poly/balance.c 
>>
>> Cheers,
>> Peter
>>
>>
>>>>
>>>
>>>
>>>> Jeff
>>>>
>>>> On Jan 29, 2014, at 10:55 PM, Peter Johansson <address@hidden> wrote:
>>>>
>>>>> Hi Jeff,
>>>>>
>>>>> On 01/30/2014 11:50 AM, Jeff E Mandel wrote:
>>>>>> I’m trying to compile GSL with Xcode 5.02 (clang) on Mavericks for 
>>>>>> iosphoneos and iosphonesimulator. It fails due to deprecation of finite. 
>>>>>> On further investigation:
>>>>>>
>>>>>> %grep -R unavailable gsl-1.16
>>>>>> …
>>>>>> gsl-1.16/config.log:conftest.c:59:10: error: 'finite' is unavailable: 
>>>>>> not available on iOS
>>>>>> …
>>>>>
>>>>> This message says that the configure script has detected that finite is 
>>>>> not available. It will therefore not #define HAVE_DECL_FINITE in 
>>>>> generated 'config.h.'.
>>>>>
>>>>> Can you please give some more details on the error you get. Does 
>>>>> configure go through or abort? If it's at compilation time you get an 
>>>>> error, what is the error message from the compiler? Can you please attach 
>>>>> config.h, which should be in you top directory.
>>>>>
>>>>> Cheers,
>>>>> Peter
>>>>>
>>>>
>>>
>>
>>
>> -- 
>> Peter Johansson
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]