Hi folks, Thanks for the quick help. I do also have numarray installed, so I don't think the NUMARRAY setting is the problem. Jouni, thanks for the attempted fix, but it continues to fail for me, at the same place: gcc: src/_na_transforms.cpp src/_na_transforms.cpp: In member function `Py::Object Bbox::update_numerix(const Py::Tuple&)': src/_na_transforms.cpp:447: error: `isnan' not declared src/_na_transforms.cpp:494: error: `isnan' undeclared (first use this function) src/_na_transforms.cpp:494: error: (Each undeclared identifier is reported only once for each function it appears in.) src/_na_transforms.cpp: In member function `Py::Object Bbox::update_numerix(const Py::Tuple&)': src/_na_transforms.cpp:447: error: `isnan' not declared src/_na_transforms.cpp:494: error: `isnan' undeclared (first use this function) src/_na_transforms.cpp:494: error: (Each undeclared identifier is reported only once for each function it appears in.) error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Isrc -I. -I/usr/local/include -I/usr/include -I/sw/include -I. -I/Library/ Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/_na_transforms.cpp -o build/temp.darwin-7.9.0- Power_Macintosh-2.4/src/_na_transforms.o -DNUMARRAY=1" failed with exit status 1 I've verified that the new "using std::isnan;" line is in _transforms.cpp and is copied to _na_transforms.cpp; it just doesn't seem to satisfy the compiler [gcc 3.3 20030304 (Apple Computer, Inc. build 1671) on 10.3.9]. I'm not a c++ programmer, and I'm stumped as to what further to try. Jouni, did this indeed solve your build problems completely? Anyone have any other suggestions? Thanks, Tom ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
Hmm... I've tested with gcc 3.3 on linux, so I'm not sure why it's breaking. First, check if adding "#include <math.h>" will help. Some other ideas: * Do "man isnan" from the command line and see if it specifies another header file. * Search inside /usr/include for isnan and see what comes up. Good luck, Andrew Tom Loredo wrote: >Hi folks, > >Thanks for the quick help. I do also have numarray installed, so >I don't think the NUMARRAY setting is the problem. > >Jouni, thanks for the attempted fix, but it continues to fail >for me, at the same place: > >gcc: src/_na_transforms.cpp >src/_na_transforms.cpp: In member function `Py::Object > Bbox::update_numerix(const Py::Tuple&)': >src/_na_transforms.cpp:447: error: `isnan' not declared >src/_na_transforms.cpp:494: error: `isnan' undeclared (first use this function) >src/_na_transforms.cpp:494: error: (Each undeclared identifier is reported only > once for each function it appears in.) >src/_na_transforms.cpp: In member function `Py::Object > Bbox::update_numerix(const Py::Tuple&)': >src/_na_transforms.cpp:447: error: `isnan' not declared >src/_na_transforms.cpp:494: error: `isnan' undeclared (first use this function) >src/_na_transforms.cpp:494: error: (Each undeclared identifier is reported only > once for each function it appears in.) >error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic >-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Isrc -I. -I/usr/local/include -I/usr/include -I/sw/include -I. -I/Library/ >Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/_na_transforms.cpp -o build/temp.darwin-7.9.0- >Power_Macintosh-2.4/src/_na_transforms.o -DNUMARRAY=1" failed with exit status 1 > >I've verified that the new "using std::isnan;" line is in _transforms.cpp >and is copied to _na_transforms.cpp; it just doesn't seem to satisfy >the compiler [gcc 3.3 20030304 (Apple Computer, Inc. build 1671) on 10.3.9]. >I'm not a c++ programmer, and I'm stumped as to what further to try. >Jouni, did this indeed solve your build problems completely? Anyone >have any other suggestions? > >Thanks, >Tom > > >------------------------------------------------- >This mail sent through IMP: http://horde.org/imp/ > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Matplotlib-devel mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
Andrew, Thanks for the suggestions, which proved helpful---transforms now builds; the rest of the build is proceeding and my fingers are crossed. Here's what I found/did. Including math.h did not help. Poking around with man and in /usr/include revealed that isnan is defined as a macro, not a function; math.h includes /usr/include/architecture/ppc/math.h and the definition is in there. I did some googling and found one other case of this causing a problem; a workaround is provided here: http://www.ssl.berkeley.edu/pipermail/boinc_dev/2004-October/000529.html It involves including math.h and defining a prototype for isnan explicitly. I tried this and the build failed, but with a slightly different error: gcc: src/_na_transforms.cpp src/_na_transforms.cpp: In member function `Py::Object Bbox::update_numerix(const Py::Tuple&)': src/_na_transforms.cpp:452: error: `isnan' not declared src/_na_transforms.cpp: In member function `Py::Object Bbox::update_numerix(const Py::Tuple&)': src/_na_transforms.cpp:452: error: `isnan' not declared At this point, I commented out the "using..." line that was just added (reasoning that isnan is now in the file's namespace), and the build succeeded. I don't know the build process well enough to know if this can be easily automated in a cross-platform manner, or if there is a better solution. As I write the numarray and scipy builds of _transforms.cpp have both succeeded. Hopefully that's the only stumbling block. -Tom ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
OK, it seems trying to pick up "isnan" from the C/C++ stdlib is riddled with difficulties, at least on Mac OS X. Following numarray's lead, I've implemented our own test "MPL_isnan64". This involved the addition of a new header file in src/ and the patch I'm including. Also included in the patch (and also checked into CVS) is the unit test which shows why this whole change is necessary. This all works for me on Mac OS X 10.4 and Debian sarge AMD64. Tom, maybe you could try it again on Mac OS X 10.3? Cheers! Andrew Tom Loredo wrote: >Andrew, > >Thanks for the suggestions, which proved helpful---transforms now >builds; the rest of the build is proceeding and my fingers are >crossed. Here's what I found/did. > >Including math.h did not help. Poking around with man and in /usr/include >revealed that isnan is defined as a macro, not a function; math.h includes >/usr/include/architecture/ppc/math.h and the definition is in there. I >did some googling and found one other case of this causing a problem; >a workaround is provided here: > >http://www.ssl.berkeley.edu/pipermail/boinc_dev/2004-October/000529.html > >It involves including math.h and defining a prototype for isnan >explicitly. I tried this and the build failed, but with a slightly >different error: > >gcc: src/_na_transforms.cpp >src/_na_transforms.cpp: In member function `Py::Object > Bbox::update_numerix(const Py::Tuple&)': >src/_na_transforms.cpp:452: error: `isnan' not declared >src/_na_transforms.cpp: In member function `Py::Object > Bbox::update_numerix(const Py::Tuple&)': >src/_na_transforms.cpp:452: error: `isnan' not declared > >At this point, I commented out the "using..." line that was just >added (reasoning that isnan is now in the file's namespace), and >the build succeeded. > >I don't know the build process well enough to know if this can be >easily automated in a cross-platform manner, or if there is a >better solution. > >As I write the numarray and scipy builds of _transforms.cpp have >both succeeded. Hopefully that's the only stumbling block. > >-Tom > > > >------------------------------------------------- >This mail sent through IMP: http://horde.org/imp/ > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Matplotlib-devel mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
Andrew, Thanks for the new patch. It works fine on OS 10.3.9/Python 2.4, as far as I can tell. Cool! My tex problem that originally motivated the reinstall appears to be due to problems with my TeTeX install (dvipng is not finding mktex.opt and thus creating blank PNGs, though ). I'll try reinstalling the latest TeTeX; if anyone else has had such problems, I'd be grateful to know how you fixed them. -Tom ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
Tom Loredo <lo...@as...> writes: > http://www.ssl.berkeley.edu/pipermail/boinc_dev/2004-October/000529.html > > It involves including math.h and defining a prototype for isnan > explicitly. I suppose that would work, but then you will take a slight performance hit when calling isnan. It's probably not too bad; depends on how often it gets called. Apple's cmath include file (my version of it, anyway, in /usr/include/gcc/darwin/3.3/c++/) first defines a template function that expands the macro, then undefines the macro and makes the function available in the standard namespace (I've omitted a lot of stuff here): namespace __gnu_cxx { template<typename _Tp> int __capture_isnan(_Tp __f) { return isnan(__f); } } #undef isnan namespace __gnu_cxx { template<typename _Tp> int isnan(_Tp __f) { return __capture_isnan(__f); } } namespace std { using __gnu_cxx::isnan; } So this ensures that when you call std::isnan, it is expanded at compile-time to a call to __capture_isnan, which in turn is expanded to the original isnan macro. It also probably means that including math.h before cmath will have no effect, since cmath will #undef the isnan macro. Including math.h after cmath will also have no effect, since it is guarded with #ifndef __MATH_H__. The solution at the URL you mentioned adds a prototype for the isnan function, which is included in the math library. I think it only handles doubles, not floats or long doubles (and I have absolutely no idea whether casting a float NaN to double works), and a function call causes a minor performance hit. Other than that, I suppose that's fine. Somehow your cmath is failing to define isnan. At least in my version, the definitions in __gnu_cxx (but not the #undef!) are conditioned on #if _GLIBCPP_USE_C99 Googling with that macro and isnan shows that a lot of other people have been having similar problems. Another attempt at a solution is at http://tolstoy.newcastle.edu.au/~rking/R/devel/05/01/1861.html Another possibly relevant page is http://lists.apple.com/archives/Xcode-users/2005/Feb/msg00238.html Apparently, the upshot is that isnan is a C99 feature and C++ does not incorporate C99. Perhaps the feature has been added anyway in some version of gcc 3.3 between yours and mine. -- Jouni
Referring to this:
>/ #include <math.h>
/32a34,37
>/ extern "C" {
/>/ int isnan(double);
/>/ }
/Jouni K Seppanen wrote:
>I suppose that would work, but then you will take a slight performance
>hit when calling isnan. It's probably not too bad; depends on how
>often it gets called.
>
>
The code that makes use of isnan is not called enough to be worried
about a minor speed hit.
>Apparently, the upshot is that isnan is a C99 feature and C++ does not
>incorporate C99.
>
So, does that mean the above should work on most C++ compilers? (Do
they implement C99 mode when in extern "C" mode?) If so, I'm all for
that approach as abandoning the isnan64 macro I borrowed from numarray.
I'd rather take the minor speed hit than have all that intricate C
coding currently in the MPL_isnan.h file.
Andrew Straw <str...@as...> writes:
> extern "C" {
> int isnan(double);
> }
>
>>Apparently, the upshot is that isnan is a C99 feature and C++ does not
>>incorporate C99.
>>
> So, does that mean the above should work on most C++ compilers? (Do
> they implement C99 mode when in extern "C" mode?)
What extern "C" does is it disables the C++ name-mangling so you can
refer to C functions. The presence of isnan is a header/library issue,
and apparently the cmath header file in some systems makes sure to
hide isnan. It seems that C99 defines an isnan _macro_, and the above
is assuming that an isnan _function_ exists in the library. The isnan
manual page on OS X states:
| HISTORY
| 3BSD introduced isinf() and isnan() functions, which accepted double
| arguments; these have been superseded by the macros described above.
I don't know how widespread these functions are. GNU libc and OS X
have them, and all the world's either Linux or a Mac, right? :-)
I think we could use the system's isnan macro in a fairly clean way by
performing the following dance (untested, and I don't have an OS X
10.3 system to test on):
#include <math.h>
template<typename T> int mpl_isnan(T arg) { return isnan(arg); }
#include <cmath>
Is it possible in distutils to do autoconf-style compilation tests at
configuration time?
--
Jouni
Tom Loredo <lo...@as...> writes: > I'll try reinstalling the latest TeTeX; if anyone else has had such > problems, I'd be grateful to know how you fixed them. FWIW, I've had no problems with Gerben Wierda's i-Installer version of TeX described at <http://ii2.sourceforge.net/tex-index.html>. I found the installer program somewhat idiosyncratic, but once you figure that out, you get a really nice TeX installation. -- Jouni
Jouni K Seppanen <jk...@ik...> writes:
> #include <math.h>
> template<typename T> int mpl_isnan(T arg) { return isnan(arg); }
> #include <cmath>
Nah, that also effectively assumes the GNU libraries. Here's a better
idea:
#include <math.h>
int mpl_isnan_f(float f) { return isnan(f); }
int mpl_isnan_d(double f) { return isnan(f); }
int mpl_isnan_ld(long double f) { return isnan(f); }
Compile this as C(99), not C++, and put
extern "C" {
int mpl_isnan_f(float);
int mpl_isnan_d(double);
int mpl_isnan_ld(long double);
}
in the C++ file.
--
Jouni
Tom Loredo <lo...@as...> writes: > I've verified that the new "using std::isnan;" line is in _transforms.cpp > and is copied to _na_transforms.cpp; it just doesn't seem to satisfy > the compiler [gcc 3.3 20030304 (Apple Computer, Inc. build 1671) on 10.3.9]. > I'm not a c++ programmer, and I'm stumped as to what further to try. > Jouni, did this indeed solve your build problems completely? Anyone > have any other suggestions? Yes, this solved my build problems, and the resulting library seems to work. I also tried building with gcc 3.3 (gcc version 3.3 20030304 (Apple Computer, Inc. build 1809)). Just to be sure, did you delete the "build" directory before trying again? There could have been something left over that is causing the error. -- Jouni