Hey,
So, I really think that we should entertain the idea of merging the cairo branch into trunk. The plan has been for us to not release 0.49 until it is ready, so the couple outstanding bugs in cairo shouldn't be a huge deterrent. We could also set up a PPA to produce the trunk builds of cairo & pixman so that fixed libs are easily installable in the meantime (at least for people using debian-based systems). I was talking to John Cliff and he put forth a very good point which is that we really need to get as much testing as possible on it prior to a release.
Before it gets asked, yes Jon, color management is broken in it atm. The likelihood of it getting fixed in a branch as opposed to trunk is next to non-existent though...
So, would people be okay with a little breakage of existing functionality to get more testing of a cairofied Inkscape? bulia, I included you in the to line here to help gauge the acceptability of this proposal.
Cheers, Josh
On Mar 15, 2011, at 12:30 PM, Josh Andler wrote:
Hey,
So, I really think that we should entertain the idea of merging the cairo branch into trunk. The plan has been for us to not release 0.49 until it is ready, so the couple outstanding bugs in cairo shouldn't be a huge deterrent. We could also set up a PPA to produce the trunk builds of cairo & pixman so that fixed libs are easily installable in the meantime (at least for people using debian-based systems). I was talking to John Cliff and he put forth a very good point which is that we really need to get as much testing as possible on it prior to a release.
Before it gets asked, yes Jon, color management is broken in it atm. The likelihood of it getting fixed in a branch as opposed to trunk is next to non-existent though...
To me this is very, very bad.
That is, the requirement and our existing implementation were clearly spelled out before the project was started. Since the project had completed there has been ample time to get this at least looked at. Since it had not been, it is a clear indication of the lack of intent and possibly some critical implementation design flaw.
It is also very bad that all attempts to engage in any discussion on this point have been flatly ignored. :-(
So, would people be okay with a little breakage of existing functionality to get more testing of a cairofied Inkscape? bulia, I included you in the to line here to help gauge the acceptability of this proposal.
Unfortunately one of the distros we are waiting on is MacPorts. So if we bring that into trunk now, I'll be completely blocked from further work. (Ubuntu upgrade trashed my main linux dev box, and I have to go in low-level and try to recover and repartition the hard drive)
*However* given that in the past we've found ways to get code mainlined and at the same time maintain compatibility, I believe there is a chance we can do so with the Ciaro branch. *If* anyone could look at the code with that in mind, that could remove the main hurdle.
-----Original Message----- From: Jon Cruz [mailto:jon@...18...] Sent: dinsdag 15 maart 2011 21:26
On Mar 15, 2011, at 12:30 PM, Josh Andler wrote:
Hey,
So, I really think that we should entertain the idea of
merging the cairo branch into trunk. The plan has been for us to not release 0.49 until it is ready, so the couple outstanding bugs in cairo shouldn't be a huge deterrent. We could also set up a PPA to produce the trunk builds of cairo & pixman so that fixed libs are easily installable in the meantime (at least for people using debian-based systems). I was talking to John Cliff and he put forth a very good point which is that we really need to get as much testing as possible on it prior to a release.
Before it gets asked, yes Jon, color management is broken
in it atm. The likelihood of it getting fixed in a branch as opposed to trunk is next to non-existent though...
To me this is very, very bad.
That is, the requirement and our existing implementation were clearly spelled out before the project was started. Since the project had completed there has been ample time to get this at least looked at. Since it had not been, it is a clear indication of the lack of intent and possibly some critical implementation design flaw.
It is also very bad that all attempts to engage in any discussion on this point have been flatly ignored. :-(
So, would people be okay with a little breakage of existing
functionality to get more testing of a cairofied Inkscape? bulia, I included you in the to line here to help gauge the acceptability of this proposal.
Unfortunately one of the distros we are waiting on is MacPorts. So if we bring that into trunk now, I'll be completely blocked from further work. (Ubuntu upgrade trashed my main linux dev box, and I have to go in low-level and try to recover and repartition the hard drive)
*However* given that in the past we've found ways to get code mainlined and at the same time maintain compatibility, I believe there is a chance we can do so with the Ciaro branch. *If* anyone could look at the code with that in mind, that could remove the main hurdle.
I am in favor, and hope this way more people will be engaged in the effort. I do not like looking at other people's branches, so for me this would be first exposure to it, and perhaps I can help here and there. I think it would make life much easier on Krzysztof too, when he no longer has to tweak other people's stuff from trunk to his branch.
If it stays with breaking part of functionality (is it only color management, or more?), then I'm ok with it. If it breaks builds and if there is no easy way to get the required libs, then I am not. (since Krzysztof updates the windows devlibs, I am sure this will be OK on my side)
Cheers, Johan
On Tue, Mar 15, 2011 at 2:50 PM, Johan Engelen <jbc.engelen@...2592...>wrote:
-----Original Message----- From: Jon Cruz [mailto:jon@...18...] Sent: dinsdag 15 maart 2011 21:26
On Mar 15, 2011, at 12:30 PM, Josh Andler wrote:
Hey,
So, I really think that we should entertain the idea of
merging the cairo branch into trunk. The plan has been for us to not release 0.49 until it is ready, so the couple outstanding bugs in cairo shouldn't be a huge deterrent. We could also set up a PPA to produce the trunk builds of cairo & pixman so that fixed libs are easily installable in the meantime (at least for people using debian-based systems). I was talking to John Cliff and he put forth a very good point which is that we really need to get as much testing as possible on it prior to a release.
Before it gets asked, yes Jon, color management is broken
in it atm. The likelihood of it getting fixed in a branch as opposed to trunk is next to non-existent though...
To me this is very, very bad.
That is, the requirement and our existing implementation were clearly spelled out before the project was started. Since the project had completed there has been ample time to get this at least looked at. Since it had not been, it is a clear indication of the lack of intent and possibly some critical implementation design flaw.
It is also very bad that all attempts to engage in any discussion on this point have been flatly ignored. :-(
So, would people be okay with a little breakage of existing
functionality to get more testing of a cairofied Inkscape? bulia, I included you in the to line here to help gauge the acceptability of this proposal.
Unfortunately one of the distros we are waiting on is MacPorts. So if we bring that into trunk now, I'll be completely blocked from further work. (Ubuntu upgrade trashed my main linux dev box, and I have to go in low-level and try to recover and repartition the hard drive)
*However* given that in the past we've found ways to get code mainlined and at the same time maintain compatibility, I believe there is a chance we can do so with the Ciaro branch. *If* anyone could look at the code with that in mind, that could remove the main hurdle.
I am in favor, and hope this way more people will be engaged in the effort. I do not like looking at other people's branches, so for me this would be first exposure to it, and perhaps I can help here and there. I think it would make life much easier on Krzysztof too, when he no longer has to tweak other people's stuff from trunk to his branch.
If it stays with breaking part of functionality (is it only color management, or more?), then I'm ok with it. If it breaks builds and if there is no easy way to get the required libs, then I am not. (since Krzysztof updates the windows devlibs, I am sure this will be OK on my side)
Yes, AFAIK the color management is the only thing that would be broken right away other than a known cairo bug (which is fixed in cairo trunk) that affects rendering of gradients when at high zoom levels. Having more eyes on the code and also having more people stress testing can be a huge win.
I haven't tried building it on win32 yet, but know that KK has a windows install that I imagine he tested against. I will try building it on win32 later today and will report back. The other thing is we could really use someone giving a build a shot on OSX as well (this I can't do).
Cheers, Josh
On 15/3/11 23:27, Josh Andler wrote:
On Tue, Mar 15, 2011 at 2:50 PM, Johan Engelen <jbc.engelen@...2592...>wrote:
-----Original Message----- From: Jon Cruz [mailto:jon@...18...] Sent: dinsdag 15 maart 2011 21:26
On Mar 15, 2011, at 12:30 PM, Josh Andler wrote:
Hey,
So, I really think that we should entertain the idea of merging the cairo branch into trunk. The plan has been for us to not release 0.49 until it is ready, so the couple outstanding bugs in cairo shouldn't be a huge deterrent. We could also set up a PPA to produce the trunk builds of cairo & pixman so that fixed libs are easily installable in the meantime (at least for people using debian-based systems). I was talking to John Cliff and he put forth a very good point which is that we really need to get as much testing as possible on it prior to a release.
Before it gets asked, yes Jon, color management is broken in it atm. The likelihood of it getting fixed in a branch as opposed to trunk is next to non-existent though...
To me this is very, very bad.
That is, the requirement and our existing implementation were clearly spelled out before the project was started. Since the project had completed there has been ample time to get this at least looked at. Since it had not been, it is a clear indication of the lack of intent and possibly some critical implementation design flaw.
It is also very bad that all attempts to engage in any discussion on this point have been flatly ignored. :-(
So, would people be okay with a little breakage of existing functionality to get more testing of a cairofied Inkscape? bulia, I included you in the to line here to help gauge the acceptability of this proposal.
Unfortunately one of the distros we are waiting on is MacPorts. So if we bring that into trunk now, I'll be completely blocked from further work. (Ubuntu upgrade trashed my main linux dev box, and I have to go in low-level and try to recover and repartition the hard drive)
*However* given that in the past we've found ways to get code mainlined and at the same time maintain compatibility, I believe there is a chance we can do so with the Ciaro branch. *If* anyone could look at the code with that in mind, that could remove the main hurdle.
I am in favor, and hope this way more people will be engaged in the effort. I do not like looking at other people's branches, so for me this would be first exposure to it, and perhaps I can help here and there. I think it would make life much easier on Krzysztof too, when he no longer has to tweak other people's stuff from trunk to his branch.
If it stays with breaking part of functionality (is it only color management, or more?), then I'm ok with it. If it breaks builds and if there is no easy way to get the required libs, then I am not. (since Krzysztof updates the windows devlibs, I am sure this will be OK on my side)
Yes, AFAIK the color management is the only thing that would be broken right away other than a known cairo bug (which is fixed in cairo trunk) that affects rendering of gradients when at high zoom levels. Having more eyes on the code and also having more people stress testing can be a huge win.
I haven't tried building it on win32 yet, but know that KK has a windows install that I imagine he tested against. I will try building it on win32 later today and will report back. The other thing is we could really use someone giving a build a shot on OSX as well (this I can't do).
Testing gsoc-cairo branch on OS X 10.5.8 (GCC 4.2.1, cairo 1.10.2): fails in 'display/nr-filter-colormatrix.o':
CXX display/nr-filter-colormatrix.o In file included from ./display/nr-filter-colormatrix.h:17, from display/nr-filter-colormatrix.cpp:17: ./display/nr-filter-primitive.h:49: warning: unused parameter ‘slot’ ./display/nr-filter-primitive.h:49: warning: unused parameter ‘units’ display/nr-filter-colormatrix.cpp: In constructor ‘Inkscape::Filters::ColorMatrixHueRotate::ColorMatrixHueRotate(double)’: display/nr-filter-colormatrix.cpp:107: error: ‘sincos’ was not declared in this scope make[3]: *** [display/nr-filter-colormatrix.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
real 14m14.732s user 11m14.652s sys 1m58.929s
Can test with cairo-devel 1.11.2 (this time with Gtk+/Quartz based dependencies - without X11, including cairo, poppler, pango and gtk+) tomorrow.
~suv
On 15/3/11 23:27, Josh Andler wrote:
I haven't tried building it on win32 yet, but know that KK has a windows install that I imagine he tested against. I will try building it on win32 later today and will report back. The other thing is we could really use someone giving a build a shot on OSX as well (this I can't do).
I tried building on win7 32-bit in a VM with current win32 devlibs and current cairo branch. Looks like there was a NR-related piece that was overlooked in win32 specific code.
src/extension/internal/win32.cpp: In member function 'virtual unsigned int Inkscape::Extension::Internal::PrintWin32::finish(Inkscape::Extension::Print*)': src/extension/internal/win32.cpp:316:20: error: aggregate 'NRPixBlock pb' has incomplete type and cannot be defined src/extension/internal/win32.cpp:334:40: error: 'NR_PIXBLOCK_MODE_R8G8B8A8N' was not declared in this scope src/extension/internal/win32.cpp:334:145: error: 'nr_pixblock_setup_extern' was not declared in this scope src/extension/internal/win32.cpp:364:33: error: 'nr_pixblock_release' was not declared in this scope
Cheers, Josh
P.S. Krzysztof, if you could pull the branch up-to-date with current trunk so we can be sure that win32 and mac os will compile with the "merged" results (and if you see if the fixes are obvious for the errors suv & I are getting... since those will be needed for the "other" OSes to compile anyway, that would rock!).
On 16/3/11 00:23, ~suv wrote:
Testing gsoc-cairo branch on OS X 10.5.8 (GCC 4.2.1, cairo 1.10.2): fails in 'display/nr-filter-colormatrix.o':
CXX display/nr-filter-colormatrix.o In file included from ./display/nr-filter-colormatrix.h:17, from display/nr-filter-colormatrix.cpp:17: ./display/nr-filter-primitive.h:49: warning: unused parameter ‘slot’ ./display/nr-filter-primitive.h:49: warning: unused parameter ‘units’ display/nr-filter-colormatrix.cpp: In constructor ‘Inkscape::Filters::ColorMatrixHueRotate::ColorMatrixHueRotate(double)’: display/nr-filter-colormatrix.cpp:107: error: ‘sincos’ was not declared in this scope make[3]: *** [display/nr-filter-colormatrix.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
real 14m14.732s user 11m14.652s sys 1m58.929s
Can test with cairo-devel 1.11.2 (this time with Gtk+/Quartz based dependencies - without X11, including cairo, poppler, pango and gtk+) tomorrow.
Same failure (r9580) on OS X 10.5.8 (i386) with a) GCC 4.2.1 (Apple), cairo-devel 1.11.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+no_x11+quartz b) GCC 4.4.5 (MacPorts), cairo 1.10.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+x11
~suv
On 28/3/11 14:31, ~suv wrote:
On 16/3/11 00:23, ~suv wrote:
Testing gsoc-cairo branch on OS X 10.5.8 (GCC 4.2.1, cairo 1.10.2): fails in 'display/nr-filter-colormatrix.o':
CXX display/nr-filter-colormatrix.o In file included from ./display/nr-filter-colormatrix.h:17, from display/nr-filter-colormatrix.cpp:17: ./display/nr-filter-primitive.h:49: warning: unused parameter ‘slot’ ./display/nr-filter-primitive.h:49: warning: unused parameter ‘units’ display/nr-filter-colormatrix.cpp: In constructor ‘Inkscape::Filters::ColorMatrixHueRotate::ColorMatrixHueRotate(double)’: display/nr-filter-colormatrix.cpp:107: error: ‘sincos’ was not declared in this scope make[3]: *** [display/nr-filter-colormatrix.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
real 14m14.732s user 11m14.652s sys 1m58.929s
Can test with cairo-devel 1.11.2 (this time with Gtk+/Quartz based dependencies - without X11, including cairo, poppler, pango and gtk+) tomorrow.
Same failure (r9580) on OS X 10.5.8 (i386) with a) GCC 4.2.1 (Apple), cairo-devel 1.11.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+no_x11+quartz b) GCC 4.4.5 (MacPorts), cairo 1.10.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+x11
same failure with: c) GCC 4.5.2 (MacPorts), cairo 1.10.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+x11
CXX display/nr-filter-colormatrix.o display/nr-filter-colormatrix.cpp: In constructor 'Inkscape::Filters::ColorMatrixHueRotate::ColorMatrixHueRotate(double)': display/nr-filter-colormatrix.cpp:107:48: error: 'sincos' was not declared in this scope make[3]: *** [display/nr-filter-colormatrix.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
@Krzysztof - any hints what is causes the failure here, and what options/flags I could test? Attaching the output from configure, using the newly compiled GCC 4.5.2 (set via $CC and $CXX, inserted in 'packaging/macosx/osx-build.sh', line 173).
~suv
Done! Please run './configure' now. LeWitt:macosx suv$ ./osx-build-LeWitt.sh c checking build system type... i386-apple-darwin9.8.0 checking host system type... i386-apple-darwin9.8.0 checking for a BSD-compatible install... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/ginstall -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gmkdir -p checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking how to create a pax tar archive... gnutar checking for style of include used by make... GNU checking whether the C++ compiler works... yes checking for C++ compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 accepts -g... yes checking dependency style of /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5... gcc3 checking for library containing strerror... none required checking whether we are using the GNU C++ compiler... (cached) yes checking whether /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 accepts -g... (cached) yes checking dependency style of /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5... (cached) gcc3 checking for gcc... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 checking whether we are using the GNU C compiler... yes checking whether /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 accepts -g... yes checking for /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 option to accept ISO C89... none needed checking dependency style of /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5... gcc3 checking dependency style of /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5... gcc3 checking for ranlib... ranlib checking whether NLS is requested... yes checking for intltool >= 0.22... 0.40.6 found checking for intltool-update... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/intltool-update checking for intltool-merge... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/intltool-merge checking for intltool-extract... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/intltool-extract checking for xgettext... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/xgettext checking for msgmerge... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/msgmerge checking for msgfmt... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/msgfmt checking for gmsgfmt... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/msgfmt checking for perl... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/perl checking for perl >= 5.8.1... 5.12.3 checking for XML::Parser... ok checking how to print strings... printf checking for a sed that does not truncate output... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gsed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -p checking the name lister (/usr/bin/nm -p) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 196608 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert i386-apple-darwin9.8.0 file names to i386-apple-darwin9.8.0 format... func_convert_file_noop checking how to convert i386-apple-darwin9.8.0 file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... no checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... no checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -p output from /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking for dsymutil... dsymutil checking for nmedit... nmedit checking for lipo... lipo checking for otool... otool checking for otool64... no checking for -single_module linker flag... yes checking for -exported_symbols_list linker flag... yes checking for -force_load linker flag... no checking how to run the C preprocessor... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 supports -fno-rtti -fno-exceptions... no checking for /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 option to produce PIC... -fno-common -DPIC checking if /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 PIC flag -fno-common -DPIC works... yes checking if /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 static flag -static works... no checking if /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 supports -c -o file.o... yes checking if /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 supports -c -o file.o... (cached) yes checking whether the /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin9.8.0 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking how to run the C++ preprocessor... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 -E checking for ld used by /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 linker (/usr/bin/ld) supports shared libraries... yes checking for /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 option to produce PIC... -fno-common -DPIC checking if /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 PIC flag -fno-common -DPIC works... yes checking if /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 static flag -static works... no checking if /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 supports -c -o file.o... yes checking if /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 supports -c -o file.o... (cached) yes checking whether the /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin9.8.0 dyld checking how to hardcode library paths into programs... immediate checking for ANSI C header files... (cached) yes checking for BZR snapshot build... no checking for gcc... (cached) /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 checking whether we are using the GNU C compiler... (cached) yes checking whether /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 accepts -g... (cached) yes checking for /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 option to accept ISO C89... (cached) none needed checking dependency style of /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5... (cached) gcc3 checking whether /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/gcc-mp-4.5 and cc understand -c and -o together... yes checking compiler support for -Werror=format-security... yes checking compiler support for -Wno-pointer-sign... yes checking linker tolerates -z relro... no checking GNU compiler version... 4.5.2 checking TR1 unordered_set usability... ok checking boost/unordered_set.hpp usability... yes checking boost/unordered_set.hpp presence... yes checking for boost/unordered_set.hpp... yes checking ext/hash_set usability... yes checking ext/hash_set presence... yes checking for ext/hash_set... yes checking for overzealous strict aliasing warnings... no checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for ngettext in libc... no checking for bindtextdomain in -lintl... yes checking for ngettext in -lintl... yes checking for dgettext in -lintl... yes checking for bind_textdomain_codeset... yes checking for msgfmt... (cached) /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/msgfmt checking for dcgettext... yes checking if msgfmt accepts -c... yes checking for gmsgfmt... (cached) /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/msgfmt checking for xgettext... (cached) /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/xgettext checking for catalogs to be installed... am ar az be bg bn br ca ca@...1971... cs da de dz el en_AU en_CA en_GB en_US@...1443... eo es_MX es et eu fa fi fr ga gl he hr hu hy id it ja km ko lt mk mn nb ne nl nn pa pl pt_BR pt ro ru rw sk sl sq sr@...1894... sr sv te_IN th tr uk vi zh_CN zh_TW checking for pkg-config... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/pkg-config checking for msgfmt... (cached) /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/msgfmt checking for gmsgfmt... (cached) /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/msgfmt checking for OpenMP flag of C++ compiler... -fopenmp checking omp.h usability... yes checking omp.h presence... yes checking for omp.h... yes checking for png_read_info in -lpng... yes checking png.h usability... yes checking png.h presence... yes checking for png.h... yes checking for shl_load in -ldld... no checking for dlopen... yes checking gc.h usability... yes checking gc.h presence... yes checking for gc.h... yes checking for GC_init in -lgc... yes checking libgc version 6.4+... 7.1.255 yes checking sys/filio.h usability... yes checking sys/filio.h presence... yes checking for sys/filio.h... yes checking malloc.h usability... no checking malloc.h presence... no checking for malloc.h... no checking for mallinfo... no checking for freetype-config... /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/freetype-config checking for Win32 platform... no checking for Solaris platform... no checking pkg-config is at least version 0.9.0... yes checking for XFT... yes checking for PANGOFT2... yes checking for GNOME_VFS... yes checking whether byte ordering is bigendian... no checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for Perl development environment... skipped checking for Python development environment... skipped checking for LCMS... yes checking for POPPLER... yes checking for POPPLER_GLIB... yes checking for CAIRO_SVG... yes checking for POPPLER_CAIRO... yes checking for POPPLER_GFXFONT... yes checking for new color space API in Poppler... yes checking whether Poppler's GfxPatch no longer uses GfxColor... yes checking for LIBWPG... yes checking for IMAGEMAGICK... yes checking for CAIRO_USER_FONTS... yes checking for INKSCAPE... yes checking for Mac OS X Carbon support... yes checking boost/concept_check.hpp usability... yes checking boost/concept_check.hpp presence... yes checking for boost/concept_check.hpp... yes checking for CAIRO_PDF... yes checking popt.h usability... yes checking popt.h presence... yes checking for popt.h... yes checking for new_aspell_config in -laspell... yes checking aspell.h usability... yes checking aspell.h presence... yes checking for aspell.h... yes checking for bind_textdomain_codeset... (cached) yes checking for gtk_window_set_default_icon_from_file... yes checking for gtk_window_fullscreen... yes checking whether binary relocation support should be enabled... no checking for pow... yes checking for sqrt... yes checking for floor... yes checking for gettimeofday... yes checking for memmove... yes checking for memset... yes checking for mkdir... yes checking for strncasecmp... yes checking for strpbrk... yes checking for strrchr... yes checking for strspn... yes checking for strstr... yes checking for strtoul... yes checking for fpsetmask... no checking for ecvt... yes checking ieeefp.h usability... no checking ieeefp.h presence... no checking for ieeefp.h... no checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for libintl.h... (cached) yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking whether lstat correctly handles trailing slash... no checking whether stat accepts an empty string... no checking for strftime... yes checking for working strtod... yes checking whether stat file-mode macros are broken... no checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for mode_t... yes checking return type of signal handlers... void configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating src/check-header-compile config.status: creating src/bind/makefile config.status: creating src/debug/makefile config.status: creating src/dialogs/makefile config.status: creating src/display/makefile config.status: creating src/dom/makefile config.status: creating src/extension/implementation/makefile config.status: creating src/extension/internal/makefile config.status: creating src/extension/makefile config.status: creating src/extension/script/makefile config.status: creating src/extension/dbus/wrapper/inkdbus.pc config.status: creating src/filters/makefile config.status: creating src/helper/makefile config.status: creating src/io/makefile config.status: creating src/libcroco/makefile config.status: creating src/libgdl/makefile config.status: creating src/libnr/makefile config.status: creating src/libnrtype/makefile config.status: creating src/libavoid/makefile config.status: creating src/livarot/makefile config.status: creating src/live_effects/makefile config.status: creating src/live_effects/parameter/makefile config.status: creating src/pedro/makefile config.status: creating src/jabber_whiteboard/makefile config.status: creating src/svg/makefile config.status: creating src/trace/makefile config.status: creating src/ui/cache/makefile config.status: creating src/ui/dialog/makefile config.status: creating src/ui/makefile config.status: creating src/ui/view/makefile config.status: creating src/ui/widget/makefile config.status: creating src/util/makefile config.status: creating src/widgets/makefile config.status: creating src/xml/makefile config.status: creating src/2geom/makefile config.status: creating doc/Makefile config.status: creating po/Makefile.in config.status: creating share/Makefile config.status: creating share/clipart/Makefile config.status: creating share/examples/Makefile config.status: creating share/extensions/Makefile config.status: creating share/extensions/alphabet_soup/Makefile config.status: creating share/extensions/Barcode/Makefile config.status: creating share/extensions/Poly3DObjects/Makefile config.status: creating share/extensions/test/Makefile config.status: creating share/extensions/xaml2svg/Makefile config.status: creating share/filters/Makefile config.status: creating share/fonts/Makefile config.status: creating share/gradients/Makefile config.status: creating share/icons/Makefile config.status: creating share/icons/application/Makefile config.status: creating share/icons/application/16x16/Makefile config.status: creating share/icons/application/22x22/Makefile config.status: creating share/icons/application/24x24/Makefile config.status: creating share/icons/application/32x32/Makefile config.status: creating share/icons/application/48x48/Makefile config.status: creating share/icons/application/256x256/Makefile config.status: creating share/keys/Makefile config.status: creating share/markers/Makefile config.status: creating share/palettes/Makefile config.status: creating share/patterns/Makefile config.status: creating share/screens/Makefile config.status: creating share/templates/Makefile config.status: creating share/tutorials/Makefile config.status: creating share/ui/Makefile config.status: creating packaging/autopackage/default.apspec config.status: creating inkscape.spec config.status: creating Info.plist config.status: creating inkview.1 config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands config.status: executing default-1 commands config.status: executing po/stamp-it commands
Configuration:
Source code location: . Destination path prefix: /Volumes/green/mp-inkscape/src/inkscape-cairo/packaging/macosx/../../Build Compiler: /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/bin/g++-mp-4.5 CPPFLAGS: -Werror=format-security -Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2 -I/Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include CXXFLAGS: -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O3 -Wall -fopenmp CFLAGS: -Wno-pointer-sign -g -O3 -Wall LDFLAGS: -L/Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/lib
Use Xft font database: yes Use gnome-vfs: yes Use openoffice files: yes Use relocation support: no Internal Python: skipped Internal Perl: skipped Enable LittleCms: yes Enable DBUS: no Enable Poppler-Cairo: yes ImageMagick Magick++: yes Libwpg: yes Doing Local Install: no
LeWitt:macosx suv$
On 28/3/11 18:31, ~suv wrote:
On 28/3/11 14:31, ~suv wrote:
On 16/3/11 00:23, ~suv wrote:
Testing gsoc-cairo branch on OS X 10.5.8 (GCC 4.2.1, cairo 1.10.2): fails in 'display/nr-filter-colormatrix.o':
Same failure (r9580) on OS X 10.5.8 (i386) with a) GCC 4.2.1 (Apple), cairo-devel 1.11.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+no_x11+quartz b) GCC 4.4.5 (MacPorts), cairo 1.10.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+x11
same failure with: c) GCC 4.5.2 (MacPorts), cairo 1.10.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+x11
Last note from me to this thread - after rebuilding current trunk with GCC 4.5.2, Inkscape crashes whenever a tool is used (the backtraces differ). Further investigating this is far over my head - - possibly the mix of different compilers [1] fails, possibly just the compiler flags in osx-build.sh need to be modified, I don't know...
After this test it seems to me that a fix for the cairo branch that works with GCC 4.2.1 (which is currently used to build the official packages for OS X) would be best, as much as I understand that some would prefer if a newer compiler would be used on Mac OS X, too.
~suv
[1] all dependencies have been built with GCC 4.0.1 - I can't influence this because MacPorts always uses the default system compiler provided by Apple, except for some ports specially configured to use a newer GCC version.
De : ~suv <suv-sf@...58...>
Same failure (r9580) on OS X 10.5.8 (i386) with a) GCC 4.2.1 (Apple), cairo-devel 1.11.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+no_x11+quartz b) GCC 4.4.5 (MacPorts), cairo 1.10.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+x11
same failure with: c) GCC 4.5.2 (MacPorts), cairo 1.10.2, glib2 @2.28.4_0, gtk2 @2.24.3_0+x11
Just compiled it on Ubuntu 10.10, gcc 4.4.4-14ubuntu5, cairo 1.10.0-1ubuntu3, glib2 .2.26.1-0ubuntu1, gtk2 2.22.0-0ubuntu1. No problem, no crash when using it.
Regards. -- Nicolas
W dniu 28 marca 2011 18:31 użytkownik ~suv <suv-sf@...58...> napisał:
@Krzysztof - any hints what is causes the failure here, and what options/flags I could test? Attaching the output from configure, using the newly compiled GCC 4.5.2 (set via $CC and $CXX, inserted in 'packaging/macosx/osx-build.sh', line 173).
Looks like the OSX and Windows math libraries do not have sincos(). I checked the manual and it's a GNU extension. I'll have to add a configure check and fall back to regular sin and cos if the function is not present.
Regards, Krzysztof
participants (6)
-
Johan Engelen
-
Jon Cruz
-
Josh Andler
-
Krzysztof Kosiński
-
Nicolas Dufour
-
~suv