Compile Problems (OS X 10.3)
I am having a few issues compiling Inkscape. My intent is to implement Flash export functionality.
I set up a custom Fink environment just for Inkscape.
When I compile the version from the svn I get:
gradient-drag.cpp: In member function `void GrDragger::updateTip()': gradient-drag.cpp:662: error: `ngettext' undeclared (first use this function) gradient-drag.cpp:662: error: (Each undeclared identifier is reported only once for each function it appears in.)
I've tried this using both gettext-dev and gettext3-dev
i gettext 0.10.40-24 Message localization support i gettext-bin 0.14.2-13 GNU Internationalization utilities i gettext-tools 0.14.2-13 GNU Internationalization utilities (Development Tools) i libgettext3-dev 0.14.2-13 GNU Internationalization utilities (Development Files) i libgettext3-shlibs 0.14.2-13 GNU Internationalization utils (shared libs)
I've also installed a stand-alone installation of gettext 0.14.5
---
Inkscape .43 tarball:
I figured i'd take a stab at the .43 release to see if by chance something got mucked up on the SVN server. Configure runs happily, when I try compiling I get this:
object-edit.cpp: In function `void sp_spiral_outer_set(SPItem*, const NR::Point&, const NR::Point&, unsigned int)': object-edit.cpp:941: error: `isfinite' undeclared in namespace `std'
Anyone have any ideas? The ngettext test passes just fine in the configure script.
Thanks,
Brian
On 04/05/06, Brian <diskofish@...127...> wrote:
I am having a few issues compiling Inkscape. My intent is to implement Flash export functionality.
I set up a custom Fink environment just for Inkscape.
When I compile the version from the svn I get:
gradient-drag.cpp: In member function `void GrDragger::updateTip()': gradient-drag.cpp:662: error: `ngettext' undeclared (first use this function) gradient-drag.cpp:662: error: (Each undeclared identifier is reported only once for each function it appears in.)
I think that ngettext is a macro and you need an include that most people do not. I might have a patch for this, in which case I will post it here. (I try to be careful with platform specific includes!).
I've tried this using both gettext-dev and gettext3-dev
i gettext 0.10.40-24 Message localization support i gettext-bin 0.14.2-13 GNU Internationalization utilities i gettext-tools 0.14.2-13 GNU Internationalization utilities (Development Tools) i libgettext3-dev 0.14.2-13 GNU Internationalization utilities (Development Files) i libgettext3-shlibs 0.14.2-13 GNU Internationalization utils (shared libs)
This is a fink problem, and is reasonably well known.
I've also installed a stand-alone installation of gettext 0.14.5
It is curious that the recommended versions and procedures do not work in Panther. This smells like an Inksacpe bug, and I will look into it, but I don't guarantee to commit a patch, in case of breaking someone else's build.
Inkscape .43 tarball:
I figured i'd take a stab at the .43 release to see if by chance something got mucked up on the SVN server. Configure runs happily, when I try compiling I get this:
object-edit.cpp: In function `void sp_spiral_outer_set(SPItem*, const NR::Point&, const NR::Point&, unsigned int)': object-edit.cpp:941: error: `isfinite' undeclared in namespace `std'
Anyone have any ideas? The ngettext test passes just fine in the configure script.
The isfinite problem is a C++ issue, and I have a patch for that which is too ugly to be seen in public. Give me a day or two and I will submit something, but again, it might need to be reviewed.
Ben.
Ben Fowler wrote:
object-edit.cpp: In function `void sp_spiral_outer_set(SPItem*, const NR::Point&, const NR::Point&, unsigned int)': object-edit.cpp:941: error: `isfinite' undeclared in namespace `std'
The isfinite problem is a C++ issue, and I have a patch for that which is too ugly to be seen in public. Give me a day or two and I will submit something, but again, it might need to be reviewed.
Ben.
If you look in src/isnan.h, you can see how we have looked at this in the past, and have tried to supply definitions for various architectures. If you can find a better definition for isFinite() for osx, that would be great.
bob
On 05/05/06, Bob Jamison <rwjj@...127...> wrote:
Ben Fowler wrote:
object-edit.cpp: In function `void sp_spiral_outer_set(SPItem*, const NR::Point&, const NR::Point&, unsigned int)': object-edit.cpp:941: error: `isfinite' undeclared in namespace `std'
[ snip ]
If you look in src/isnan.h, you can see how we have looked at this in the past, and have tried to supply definitions for various architectures. If you can find a better definition for isFinite() for osx, that would be great.
That is just what I did. I really do want to check my work again before publishing it, but I will submit a patch in the next day or two. I know that it is needed for Jaguar, but I thought that the existing isnan.h worked O.K. for Panther.
IIRC, the namespace std message means that we are choosing the (default) linux implementation, which will not work on Darwin. My guess is that the OP has somehow obtained a situation where the macro that we test is not being set ...
Ben
#if defined(__isnan) # define isNaN(_a) (__isnan(_a)) /* MacOSX/Darwin definition < 10.4 */
This never gets executed by the preprocessor. Was the intent to look for something that was defined in one of the OS X libraries or that someone manually would #define __isnan?
Also, there were a few more areas where I simply included missing header files. Is this something I should submit a patch for?
Brian
Bob Jamison wrote:
If you look in src/isnan.h, you can see how we have looked at this in the past, and have tried to supply definitions for various architectures. If you can find a better definition for isFinite() for osx, that would be great.
bob
Is this two comments, or just one?
I am actually just starting work on this, so if you have patches, then you are a bit ahead of me.
On 06/05/06, Brian <diskofish@...127...> wrote:
#if defined(__isnan) # define isNaN(_a) (__isnan(_a)) /* MacOSX/Darwin definition < 10.4 */
This never gets executed by the preprocessor. Was the intent to look for something that was defined in one of the OS X libraries or that someone manually would #define __isnan?
Yes. __isnan should be defined in all versions of Darwin (well, at least since Mac OS X 10.2). Look in /usr//include/architecture/ppc/math.h (or the header for your architecture).
Also, there were a few more areas where I simply included missing header files. Is this something I should submit a patch for?
Yes. I have been wary of making patches affecting headers so as not to undo Ralf's good work, and a more important point is that not all platforms need quite the same includes. I suspect that you needed to include <libintl.h> in a few places.
If somebody else sees your work and can verify that it doesn't cause problems on other platforms, then it can perhaps go straight in.
Ben
Bob Jamison wrote:
If you look in src/isnan.h, you can see how we have looked at this in the past, and have tried to supply definitions for various architectures. If you can find a better definition for isFinite() for osx, that would be great.
On 06/05/06, Ben Fowler <ben.the.mole@...400...> wrote:
On 06/05/06, Brian <diskofish@...127...> wrote:
#if defined(__isnan) # define isNaN(_a) (__isnan(_a)) /* MacOSX/Darwin definition < 10.4 */
This never gets executed by the preprocessor. Was the intent to look for something that was defined in one of the OS X libraries or that someone manually would #define __isnan?
Yes. __isnan should be defined in all versions of Darwin (well, at least since Mac OS X 10.2). Look in /usr//include/architecture/ppc/math.h (or the header for your architecture).
FWIW, I have used this pre-processor verbiage
#elif defined( __MATH__ ) && defined(NAN)
to pickup Darwin.
I'll submit a patch tomorrow.
Ben
Hi,
This might just be a brain-fade issue, but it seems I'm having problems making a uniform scale change with the verly latest build out of SVN.
Symptom:
draw a rectangle hold ctrl and resize the rectangle using the mouse over a corner handle.
the rectangle can be resized to any shape, not just a size in the same proportions as the original.
Doesn't happen on an older version 0.42. I restarted the latest SVN, but the problem was still there.
Thanks.
participants (4)
-
Andrew Wilson -
Ben Fowler -
Bob Jamison -
Brian