|
From: Quentin S. <qsp...@ie...> - 2005-11-03 19:36:53
|
I tried compiling the cvs version of octave-forge with the cvs version of octave, and two functions failed to compile: 1. main/fixed/fixedNDArray.cc fixedNDArray.o fixedNDArray.cc:407:59: error: macro "MX_ND_REDUCTION" passed 5 arguments, but takes just 3 fixedNDArray.cc:421:61: error: macro "MX_ND_REDUCTION" passed 5 arguments, but takes just 3 fixedNDArray.cc:436:61: error: macro "MX_ND_REDUCTION" passed 5 arguments, but takes just 3 This appears to be caused by recent changes to octave. I don't know enough about this code to debug it, but from looking at it, it appears that this macro has changed periodically in the past and there is already some cruft in the code to handle different cases. To whoever fixes this I suggest removing the old stuff since we are trying to clean up before octave 3.0. 2. main/image/pngread.cc /usr/include/pngconf.h:307: error: expected constructor, destructor, or type conversion before ‘.’ token /usr/include/pngconf.h:308: error: ‘__dont__’ does not name a type pngread.cc: In function ‘canvas* load_canvas(char*)’: pngread.cc:156: warning: ignoring return value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result I'm not sure what's causing this. I'm using Fedora Core 4, with libpng-1.2.8-2 installed, and the compiler is gcc 4.0.1. I have a related question to this. I see that octave-forge now has the option of using ImageMagick++, but I didn't follow the earlier discussion about this closely. Is this intended to provide new features that are unavailable in libjpg and libpng, or does it provide an alternate way of getting the same features? This will influence whether I add ImageMagick-c++-devel as a build dependency for the Fedora Extras octave-forge package. -Quentin |
|
From: Dmitri A. S. <das...@gm...> - 2005-11-03 22:03:41
|
On 11/3/05, Quentin Spencer <qsp...@ie...> wrote:
> 2. main/image/pngread.cc
>
> /usr/include/pngconf.h:307: error: expected constructor, destructor, or
> type conversion before '.' token
> /usr/include/pngconf.h:308: error: '__dont__' does not name a type
> pngread.cc: In function 'canvas* load_canvas(char*)':
> pngread.cc:156: warning: ignoring return value of 'size_t fread(void*,
> size_t, size_t, FILE*)', declared with attribute warn_unused_result
>
> I'm not sure what's causing this. I'm using Fedora Core 4, with
> libpng-1.2.8-2 installed, and the compiler is gcc 4.0.1.
This is libpng doing. If you look at pngconf.h it has the following:
#ifdef PNG_SETJMP_SUPPORTED
/* This is an attempt to force a single setjmp behaviour on Linux. If
* the X config stuff didn't define _BSD_SOURCE we wouldn't need this.
*/
# ifdef __linux__
# ifdef _BSD_SOURCE
# define PNG_SAVE_BSD_SOURCE
# undef _BSD_SOURCE
# endif
# ifdef _SETJMP_H
/* If you encounter a compiler error here, see the explanation
* near the end of INSTALL.
*/
__png.h__ already includes setjmp.h;
__dont__ include it again.;
# endif
# endif /* __linux__ */
I do not know who this problem should be handled...
> -Quentin
>
Sincerely,
Dmitri.
--
|
|
From: David B. <Dav...@mo...> - 2005-11-04 09:02:15
|
Quentin Spencer wrote: > I tried compiling the cvs version of octave-forge with the cvs version > of octave, and two functions failed to compile: > > 1. main/fixed/fixedNDArray.cc > > fixedNDArray.o > fixedNDArray.cc:407:59: error: macro "MX_ND_REDUCTION" passed 5 > arguments, but takes just 3 > fixedNDArray.cc:421:61: error: macro "MX_ND_REDUCTION" passed 5 > arguments, but takes just 3 > fixedNDArray.cc:436:61: error: macro "MX_ND_REDUCTION" passed 5 > arguments, but takes just 3 > > This appears to be caused by recent changes to octave. I don't know > enough about this code to debug it, but from looking at it, it appears > that this macro has changed periodically in the past and there is > already some cruft in the code to handle different cases. To whoever > fixes this I suggest removing the old stuff since we are trying to > clean up before octave 3.0. Grrr, that ones mine. It seems to me that a new 2.1.x release of octave-forge is a reasonable goal as the code in octave-forge is still compatible with 2.1.x. So I'd like to keep a 2.1.71 (or 2.1.72 if it comes out) and 2.9.4 (when it comes out) compatible version of the this change for now. I'd suggest an octave-forge release soon after the next 2.9 and perhaps 2.1 release. There doesn't seem all that much point to me in completely decrufting octave-forge at this point as when Soren's package management code is include in octave, then the whole paradigm of octave-forge will change and that is the best point to do the decrufting at the time of that transition... Regards David -- David Bateman Dav...@mo... Motorola Labs - Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: David B. <Dav...@mo...> - 2005-11-04 09:59:27
Attachments:
patch
|
Quentin Spencer wrote: > I tried compiling the cvs version of octave-forge with the cvs version > of octave, and two functions failed to compile: > > 1. main/fixed/fixedNDArray.cc > > fixedNDArray.o > fixedNDArray.cc:407:59: error: macro "MX_ND_REDUCTION" passed 5 > arguments, but takes just 3 > fixedNDArray.cc:421:61: error: macro "MX_ND_REDUCTION" passed 5 > arguments, but takes just 3 > fixedNDArray.cc:436:61: error: macro "MX_ND_REDUCTION" passed 5 > arguments, but takes just 3 > > This appears to be caused by recent changes to octave. I don't know > enough about this code to debug it, but from looking at it, it appears > that this macro has changed periodically in the past and there is > already some cruft in the code to handle different cases. To whoever > fixes this I suggest removing the old stuff since we are trying to > clean up before octave 3.0. > Try the attached patch, that I'll commit soon. Yes it adds more cruft, but we'll get rid of that soon, as I said.. D. -- David Bateman Dav...@mo... Motorola Labs - Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |