Inkscape won't compile against libsigc++ >= 2.5.1 due to missing "-std=c++11".

Bug #1488079 reported by Shlomi Fish on 2015-08-24
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Inkscape
High
Krzysztof Kosinski
Gentoo Linux
Fix Released
Medium

Bug Description

The recent libsigc++-2.5.1 refuses to compile without -std=c++11 and it affects inkscape too:

shlomif@telaviv1:~$ g++ `pkg-config --cflags sigc++-2.0` sigcpp_test.cpp
In file included from /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:7:0,
                 from /usr/include/sigc++-2.0/sigc++/functors/slot.h:7,
                 from /usr/include/sigc++-2.0/sigc++/signal_base.h:27,
                 from /usr/include/sigc++-2.0/sigc++/signal.h:8,
                 from sigcpp_test.cpp:14:
/usr/include/sigc++-2.0/sigc++/functors/functor_trait.h:91:36: error: ‘decltype’ has not been declared
   static int check(X_functor* obj, decltype(&X_functor::operator()) p = nullptr
                                    ^
/usr/include/sigc++-2.0/sigc++/functors/functor_trait.h:91:46: error: expected ‘)’
   static int check(X_functor* obj, decltype(&X_functor::operator()) p = nullptr
                                              ^
/usr/include/sigc++-2.0/sigc++/functors/functor_trait.h:91:46: error: expected ‘)’
/usr/include/sigc++-2.0/sigc++/functors/functor_trait.h:91:46: error: expected initializer
/usr/include/sigc++-2.0/sigc++/functors/functor_trait.h:96:44: error: ‘nullptr’ was not declared in this scope
     = sizeof(check(static_cast<T_functor*>(nullptr))) == sizeof(int)
                                            ^
/usr/include/sigc++-2.0/sigc++/functors/functor_trait.h:134:64: error: ‘&’ cannot appear in a constant-expression
   typedef typename functor_trait<decltype(&T_functor::operator()), false, false
                                                                ^
/usr/include/sigc++-2.0/sigc++/functors/functor_trait.h:134:65: error: a function call cannot appear in a constant-expression
   typedef typename functor_trait<decltype(&T_functor::operator()), false, false
                                                                 ^
/usr/include/sigc++-2.0/sigc++/functors/functor_trait.h:134:80: error: template argument 1 is invalid
 ypename functor_trait<decltype(&T_functor::operator()), false, false>::result_t
                                                                     ^
shlomif@telaviv1:~$ g++ -std=c++11 `pkg-config --cflags sigc++-2.0` sigcpp_test.cpp
shlomif@telaviv1:~$ cat sigcpp_test.cpp
/*
 * Building this using:

 g++ `pkg-config --cflags sigc++-2.0` sigcpp_test.cpp

 Results in an error.
 * */
#include <stddef.h>
#include <string>
#if 0
#include <sigc++/sigc++.h>
#else
#include <sigc++/signal.h>
#endif

int main()
{
    return 0;
}

=====================

The attached tentative patch fixes this problem.

Shlomi Fish (shlomif-gmail) wrote :
su_v (suv-lp) on 2015-08-24
tags: added: build cmake
Changed in inkscape:
importance: Undecided → High
Alex Valavanis (valavanisalex) wrote :

Wow... this is actually a much bigger issue, because we deliberately haven't yet used any C++11 features directly in Inkscape.

We could, as you suggest, only enforce C++11 builds for people with new versions of libsigc++, but it makes me pretty nervous having to support two different C++ standards.

A proper fix would enforce C++11 builds for everyone, but this is problematic, because AFAIK older OS X releases don't provide compiler support for C++11.

I think this needs further discussion! :/

su_v (suv-lp) wrote :
su_v (suv-lp) wrote :

On 2015-08-24 15:10 (+0200), Alex Valavanis wrote:
> A proper fix would enforce C++11 builds for everyone, but this is
> problematic, because AFAIK older OS X releases don't provide
> compiler support for C++11.

1) Just adding the compile flag '-std=c++11' won't break trunk builds on OS X 10.7 - as long as Inkscape doesn't actually _use_ c++11 features.

Updating to future stable releases of the C++ libs (glibmm, libsigc++, atkmm, pangomm, cairomm) though won't work on OS X 10.7.5 with the system tool-chain (and AFAICT won't really be an option anyway even if a full tool-chain with C++11 would be compiled from source, because the next stable release of glib2 (2.46) will only support OS X 10.9 and later).

So far Inkscape does not require the most latest stable releases of glib/glibmm (configure.ac checks for 2.28) - is this requirement going to change soon due to internal changes in Inkscape?

2) The system tool-chain provided on older versions of Mac OS X (Jon Cruz' 10.6, and LiamW's 10.5 for 32bit packages) likely does not even support adding the compiler flag '-std=c++11' unconditionally. On those systems, a custom tool-chain would have to be compiled from source, and used for inkscape and all dependent C++ packages (the same caveat wrt next major stable glib release applies here too).

Alex Valavanis (valavanisalex) wrote :

OK, thanks for the clarification. I've sent a RFC out on the dev mailing list...

su_v (suv-lp) on 2015-10-26
Changed in inkscape:
milestone: none → 0.92
Alex Valavanis (valavanisalex) wrote :

@~suv: In response to comment #4

We can actually fix this fairly easily by requiring a C++11 compiler if (and only if) the new GNOME libraries are being used. Any system with those should also have a C++11 compiler, I guess. Any attempt to actually use the new C++11 syntax would make the Jenkins/PPA builds unhappy, so this should stop it happening "accidentally". We shouldn't require new GNOME libs, so support for older OS X versions should not be affected for now if we use a conditional C++11 requirement.

I'd suggest targeting the fix for this to 0.91.1 since it will start to cause build problems on new linux releases quite soon.

Changed in inkscape:
status: New → Triaged
milestone: 0.92 → 0.91.1
su_v (suv-lp) wrote :

@Alex - agreed. AFAIU separate tests for:
* sigc++-2.0 >= 2.5.1
* glibmm >= 2.45.31
are likely sufficient to detect the requirement for c++11 in Inkscape's CXXFLAGS.

AFAICT the other C++ bindings depend directly or indirectly on glibmm, and will require c++11 if glibmm does. Older versions than the following releases can't be provided by the system if glibmm was already upgraded:
* atkmm >= 2.23.2
* pangomm >= 2.37.1
* gtkmm3 >= 3.17.41 [1][2]

Cairomm seems to be different: the library itself requires c++11 lately
* cairomm >= 1.11.4
but apparently older versions of cairomm may still work ok with newer C++ bindings:
https://git.gnome.org/browse/pangomm/commit/?id=62ec4693bbf3c16eb1566b2cb499650f996f898f
OTOH current stable gtkmm 3.18 now requires cairomm >= 1.12.0 (or rather gdkmm does):
https://git.gnome.org/browse/gtkmm/commit/?id=ec1cf2cd1a70a1896b3f589ef31d9a375b33c908

--
[1] Legacy gtkmm 2.24 (see branch in git) needs to be built with c++11 if compiled against newer glibmm, but does not require it for itself:
https://git.gnome.org/browse/gtkmm/log/?h=gtkmm-2-24
https://git.gnome.org/browse/gtkmm/commit/?h=gtkmm-2-24&id=5b8f1294844e3639c6be802dda81fa853511bf30
[2] Current stable gtkmm 3.18 has these direct requirements:
* giomm-2.4 >= 2.46.1
* pangomm-1.4 >= 2.38.1
* gtk+-3.0 >= 3.18.0
* cairomm-1.0 >= 1.12.0
* gdk-pixbuf-2.0 >= 2.26.0
* atkmm-1.6 >= 2.24.1
glibmm 2.46.1 (for giomm) adds the direct requirement for
* sigc++-2.0 >= 2.6.0

su_v (suv-lp) on 2015-11-06
tags: added: blocker
su_v (suv-lp) on 2015-11-10
summary: - Inkscape won't compile against libsigc++-2.5.1 due to missing
+ Inkscape won't compile against libsigc++ >= 2.5.1 due to missing
"-std=c++11".
Download full text (4.4 KiB)

'MAKEOPTS=-j1 emerge -v1 inkscape' fails with:

...
e/gnome-vfs-2.0 -I/usr/lib64/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=32 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=32 -fopenmp -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=32 -I/usr/include/ImageMagick-6 -I/usr/include/libvisio-0.1 -I/usr/include/libxml2 -I/usr/include/librevenge-0.0 -I/usr/include/libcdr-0.1 -I/usr/include/librevenge-0.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/poppler -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng16 -DPOTRACE=\"potrace\" -pthread -I/usr/include/gtkspell-2.0 -I/usr/include/gtkmm-2.4 -I/usr/lib64/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/gtk-unix-print-2.0 -I/usr/include/gtk-2.0 -I/usr/include/gdkmm-2.4 -I/usr/lib64/gdkmm-2.4/include -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib64/pangomm-1.4/include -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -pthread -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/libpng16 -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -DG_DISABLE_DEPRECATED -DGLIBMM_DISABLE_DEPRECATED -DGDKMM_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_DEPRECATED -DGTKMM_DISABLE_DEPRECATED -Werror=format-security -Wswitch -Werror=return-type -DGSEAL_ENABLE -DG_DISABLE_SINGLE_INCLUDES -Wall -Wformat -Wformat-security -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -march=amdfam10 -O2 -pipe -fno-strict-aliasing -fopenmp -c -o livarot/PathCutting.o livarot/PathCutting.cpp
In file included from /usr/include/sigc++-2.0/sigc++/signal_base.h:26:0,
                 from /usr/include/sigc++-2.0/sigc++/signal.h:8
                 from /usr/include/sigc++-2.0/sigc++/connection.h:22
                 from ./sp-object.h:51
                 from ./sp-filter.h:18
                 from ./style-internal...

Read more...

Download full text (9.4 KiB)

root@impala:/root(48)# emerge --info '=media-gfx/inkscape-0.91::gentoo'
Portage 2.2.25 (python 2.7.10-final-0, default/linux/amd64/13.0, gcc-4.9.3, glibc-2.22-r1, 4.3.0-gentoo x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-4.3.0-gentoo-x86_64-AMD_Phenom-tm-_II_X4_965_Processor-with-gentoo-2.2
KiB Mem: 8163332 total, 2076140 free
KiB Swap: 50331640 total, 49848688 free
Timestamp of repository gentoo: Fri, 20 Nov 2015 05:30:01 +0000
sh bash 4.3_p42
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash: 4.3_p42::gentoo
dev-java/java-config: 2.2.0::gentoo
dev-lang/perl: 5.22.0::gentoo
dev-lang/python: 2.7.10-r3::gentoo, 3.4.3-r2::gentoo, 3.5.0-r1::gentoo
dev-util/cmake: 3.4.0-r1::gentoo
dev-util/pkgconfig: 0.29::gentoo
sys-apps/baselayout: 2.2::gentoo
sys-apps/openrc: 0.18.3::gentoo
sys-apps/sandbox: 2.9::gentoo
sys-devel/autoconf: 2.13::gentoo, 2.69-r1::gentoo
sys-devel/automake: 1.11.6-r1::gentoo, 1.12.6::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils: 2.25.1-r1::gentoo
sys-devel/gcc: 4.9.3::gentoo
sys-devel/gcc-config: 1.8::gentoo
sys-devel/libtool: 2.4.6-r1::gentoo
sys-devel/make: 4.1-r1::gentoo
sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers)
sys-libs/glibc: 2.22-r1::gentoo
Repositories:

gentoo
    location: /usr/portage_impala
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

x-portage
    location: /usr/local/portage
    masters: gentoo
    priority: 0

g-cpan
    location: /var/lib/cpan
    masters: gentoo
    priority: 1

g-octave
    location: /var/lib/g-octave
    masters: gentoo
    priority: 2

sage-on-gentoo
    location: /var/lib/layman/sage-on-gentoo
    masters: gentoo science
    priority: 50

science
    location: /var/lib/layman/science
    masters: gentoo
    priority: 50

sunrise
    location: /var/lib/layman/sunrise
    masters: gentoo
    priority: 50

x11
    location: /var/lib/layman/x11
    masters: gentoo
    priority: 50

ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA PUEL Intel-SDP dlj-1.1 skype-eula skype-4.0.0.7-copyright googleearth AdobeFlash-11.x cadsoft Oracle-BCLA-JavaSE MakeMKV-EULA NVIDIA-CUDA Nero-AAC-EULA GIMPS"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=amdfam10 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /etc/stunnel/stunnel.conf /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.6/ext-active/ /etc/php/cgi-php5.6/ext-active/ /etc/php/cli-php5.6/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=amdfam10 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-l...

Read more...

Created attachment 417456
build.log.bz2

*** Bug 566310 has been marked as a duplicate of this bug. ***

@maintainer, summary is also in parent bug

You can see for example what Fedora did:
http://pkgs.fedoraproject.org/cgit/inkscape.git/tree/inkscape.spec
# Build in C++11 mode as glibmm headers use C++11 features. This can be dropped
# when GCC in Fedora switches to C++11 by default (with GCC 6, most likely).
export CXXFLAGS="%{optflags} -std=c++11"

*** Bug 566350 has been marked as a duplicate of this bug. ***

Jorgicio had a workaround in bug 566350 comment 4 ( https://bugs.gentoo.org/show_bug.cgi?id=566350#c4 ).

Even simpler fix:

--- inkscape-0.91.ebuild
+++ inkscape-0.91.ebuild
@@ -115,7 +115,7 @@

 src_configure() {
  # aliasing unsafe wrt #310393
- append-flags -fno-strict-aliasing
+ append-flags -fno-strict-aliasing -std=gnu++11

  econf \
   $(use_enable static-libs static) \

(In reply to Ted Tanberry from comment #7)

Works, thanks!

It works for me too.

Thanks!

For those, like me, not adept at ebuild patching, I found this worked for me:

# change to patch directory
      cd /usr/portage/media-gfx/inkscape/

# create file my.patch with the patch

# show that I got the patch right
      cat my.patch
--- inkscape-0.91.ebuild
+++ inkscape-0.91.ebuild
@@ -115,7 +115,7 @@

 src_configure() {
  # aliasing unsafe wrt #310393
- append-flags -fno-strict-aliasing
+ append-flags -fno-strict-aliasing -std=gnu++11

  econf \
   $(use_enable static-libs static) \

# apply the patch
       patch < my.patch

# run emerge, tell it to ignore digest verification errors
       emerge --digest =media-gfx/inkscape-0.91

(In reply to Gary E. Miller from comment #10)
> For those, like me, not adept at ebuild patching, I found this worked for me:

Easier solution:

# mkdir -p /etc/portage/env/media-gfx
# echo 'CXXFLAGS="${CXXFLAGS} -std=gnu++11"' \
  > /etc/portage/env/media-gfx/inkscape-0.91

*** Bug 566698 has been marked as a duplicate of this bug. ***

I have the same problem on ~amd64.

Martin's workaround worked for me.

(In reply to Martin von Gagern from comment #11)

Works for me on ~amd64

(In reply to Martin von Gagern from comment #11)
> (In reply to Gary E. Miller from comment #10)
> > For those, like me, not adept at ebuild patching, I found this worked for me:
>
> Easier solution:
>
> # mkdir -p /etc/portage/env/media-gfx
> # echo 'CXXFLAGS="${CXXFLAGS} -std=gnu++11"' \
> > /etc/portage/env/media-gfx/inkscape-0.91

Worked like a charm.

(In reply to Ted Tanberry from comment #7)
> Even simpler fix:
>
> --- inkscape-0.91.ebuild
> +++ inkscape-0.91.ebuild
> @@ -115,7 +115,7 @@
>
> src_configure() {
> # aliasing unsafe wrt #310393
> - append-flags -fno-strict-aliasing
> + append-flags -fno-strict-aliasing -std=gnu++11
>
> econf \
> $(use_enable static-libs static) \

Works here too.

(In reply to Vincent Le Ligeour from comment #15)
> (In reply to Martin von Gagern from comment #11)
>
> Works for me on ~amd64

Also works here, also ~amd64.

Shouldn't the ebuild be modified to include the -std in some way? I realize it could be a hard choice between c++11 or gnu++11, but (if possible) the ebuild could warn if no "env" is found for setting an appropriate std, and force the user to make the choice, rather than failing with a 10000+ line error log.

the fix works for inkscape-9999 too

Works also for me on ~amd64.

Would be great to see it in the tree asap.

Many thanks to all.

(In reply to Bernardo Costa from comment #18)
> I realize it could be a hard choice between c++11 or gnu++11

If the current build system does not specify a -std, then you must go with -std=gnu++11 because -std=c++11 would disable certain options that GCC enables by default. (G++'s default is -std=gnu++03.)

(In reply to Bernardo Costa from comment #18)
> (In reply to Vincent Le Ligeour from comment #15)
> > (In reply to Martin von Gagern from comment #11)
> >
> > Works for me on ~amd64
>
> Also works here, also ~amd64.
>
> Shouldn't the ebuild be modified to include the -std in some way? I realize
> it could be a hard choice between c++11 or gnu++11, but (if possible) the
> ebuild could warn if no "env" is found for setting an appropriate std, and
> force the user to make the choice, rather than failing with a 10000+ line
> error log.

No, it is the build system's task to request a compiler with {c,gnu}++11 features and enable them by adding the appropriate -std= flags. The user should not be required to include -std= in their global CXXFLAGS, which might wreck havoc with packages implicitly relying on being compiled in C++98 mode.

> (In reply to Bernardo Costa from comment #18)
>> Shouldn't the ebuild be modified to include the -std in some way?

Yes it should. At least until this can get addressed in a better way. People having to reconfigure things locally along the lines of comment #11 is hardly appropriate since people should be able to simply emerge a package, without jumping through hoops if it can be avoided.

(In reply to Ted Tanberry from comment #22)
> No, it is the build system's task to request a compiler with {c,gnu}++11
> features and enable them by adding the appropriate -std= flags.

Ultimately you are right, ultimately the ebuilds should only have to call configure and make, anything special which is not due to some Gentoo-specific quirk should be reported and handled upstream.

There already is a bug report for this one here upstream:
https://bugs.launchpad.net/inkscape/+bug/1488079
Someone might want to add this to the see-also field. And those with Launchpad accounts may want to report that they are affected by this, to add heat to the issue. Quoting from that bug report:

> Wow... this is actually a much bigger issue, because we deliberately
> haven't yet used any C++11 features directly in Inkscape.

So the problem is not just of inkscape's making, but depends on the ecosystem in which inkscape is being built. Handling such issues in the ebuild makes a lot of sense, although it would still be even better if the inkscape devs got some magic in there to set the right flags automatically. They are working on it.

> The user
> should not be required to include -std= in their global CXXFLAGS, which
> might wreck havoc with packages implicitly relying on being compiled in
> C++98 mode.

Neither the approach suggested in comment #11 and confirmed by several people, nor the Gentoo maintainers adding the flag to this ebuild, would in any way that I can see affect the global (i.e. system-wide, set in make.conf) CXXFLAGS. So I'm not sure what you are getting at here.

Changed in gentoo:
importance: Unknown → Medium
su_v (suv-lp) wrote :

On 2015-08-24 15:36 (+0100), ~suv wrote:
> On 2015-08-24 15:10 (+0200), Alex Valavanis wrote:
>> A proper fix would enforce C++11 builds for everyone, but this is
>> problematic, because AFAIK older OS X releases don't provide
>> compiler support for C++11.
>
> 1) Just adding the compile flag '-std=c++11' won't break trunk builds on
> OS X 10.7 - as long as Inkscape doesn't actually _use_ c++11 features.

Just a FYI: above statement is no longer true after the changes in rev 14475 - without reverting that commit, current Inkscape trunk (tested with r14506) no longer compiles with '-std=c++11' on the mentioned system.

I'm on it. Testing a fix now.

i don't see the ebuild anywhere after syncing, i still get the same errors because no media-gfx/inkscape/inkscape-0.91-r1.ebuild insight on server even it was uploaded on

author Michał Górny <email address hidden> 2015-12-06 20:19:08 (GMT)
committer Michał Górny <email address hidden> 2015-12-06 21:55:14 (GMT

we have now 8.12.2015...

I would check again:

Installed versions: 0.91-r1^t{tbz2}(20:44:11 07-12-15)(cdr dbus exif gnome jpeg lcms nls openmp spell -dia -imagemagick -inkjar -postscript -static-libs -visio -wpg PYTHON_TARGETS="python2_7")

i still have this problem and there is no inkscape-0.91-r1.ebuild in tree here, syncing dont help :((

Changed in gentoo:
status: Unknown → Fix Released
Alex Valavanis (valavanisalex) wrote :

Ubuntu builds in Xenial now seem to have patched the GNOME libraries' pkg-config files so that C++11 builds are specified automatically. An undesirable side-effect of this in Inkscape is that the -std=c++11 flag is appended to the INKSCAPE_CFLAGS variable, which is used for both C and C++ files. This causes a C compiler warning when we build our embedded C libraries (libcroco etc).

I'm working on a patch that separates out the C++-specific compiler flags.

Alex Valavanis (valavanisalex) wrote :

Fix for the above warnings applied in lp:inkscape r14542

su_v (suv-lp) wrote :

On 2015-12-26 21:21 (+0100), Alex Valavanis wrote:
> Fix for the above warnings applied in lp:inkscape r14542

@Alex - AFAICT rev 14542 broke builds with newer glib/glibmm (see e.g. Ubuntu build bots for Inkscape trunk PPA). Attached diff attempts to fix the failing test for glibmm/threads.h (tested successfully with r14542 GTK2 on OS X 10.7.5).

Alex Valavanis (valavanisalex) wrote :

Oops... Looking into it now. The patch isn't ideal, because it adds the GTKMM compiler flags to CPPFLAGS (i.e., applies to both C++ and C builds), so it would restore the C compiler warnings that I've tried to suppress. I suspect I've made a typo somewhere in my original commit.

su_v (suv-lp) wrote :

On 2015-12-27 10:53 (+0100), Alex Valavanis wrote:
> The patch isn't ideal, because it adds the GTKMM compiler flags to
> CPPFLAGS

Maybe I completely misunderstood that part of configure.ac: aren't the original CPPFLAGS restored unconditionally on line 1120 again? The diff only attempts to fix the check (test compilation) for the specific glibmm header (line 1119) which after r14542 fails with this error:

> conftest.cpp:117:10: fatal error: 'glibmm/threads.h' file not found
> #include <glibmm/threads.h>
> ^
> 1 warning and 1 error generated.

The header file is present (installed by glibmm), but after r14542 the '-I' flags for the conftest seem to be not ok (they now only have the flags for Gtk+, not for any C++ bindings).

Otherwise (if the cflags for gtkmm can't be included for a conftest compilation), that check should probably be removed from configure.ac altogether (line 1116-1120), along with the remaining use cases of HAVE_GLIBMM_THREADS_H (there are still those in src/widgets/sp-color-selector.{cpp,h} right now)?

Alex Valavanis (valavanisalex) wrote :

Around line 1120, the CPPFLAGS are temporarily saved prior to checking for the existence of glibmm/threads.h and then restored afterwards. However, the CXXFLAGS (i.e., C++ only) are still kept as a separate variable.

Actually, the threads.h issue is not really handled correctly in configure.ac so this entire chunk can be removed, as you suggest. Instead, the issue should be fixed by ensuring that headers are included in files in the correct order. I'll have a sweep through later

Alex Valavanis (valavanisalex) wrote :

Remaining superfluous threads.h checks removed in r14550

I have tried Martin's solution but without success

(In reply to Loop from comment #29)
> I have tried Martin's solution but without success

Have you tried Gary's solution in Comment 10?

Bryce Harrington (bryce) wrote :

We'll need to have cmake logic added for this, in addition to the autoconf logic.

The autoconf changes will need to be applied for both the 0.92 and 0.91.1 branches; the cmake changes only need to be on trunk, I don't think cmake is going to work on the 0.91.1 branch anyway.

For 0.93 and forward, we'll be dropping autoconf and making C++11 a hard requirement, so the optional checks in the cmake logic can be changed to requirements, and the autoconf logic will all just go away.

Krzysztof Kosinski (tweenk) wrote :

Can someone with an affected system try this patch?

Tavmjong Bah (tavmjong-free) wrote :

Patch in #49 works for me (Fedora 23 which requires C++11).

Krzysztof Kosinski (tweenk) wrote :

Fixed in r14656.

Changed in inkscape:
status: Triaged → Fix Committed
Changed in inkscape:
assignee: nobody → Krzysztof Kosinski (tweenk)
Shlomi Fish (shlomif-gmail) wrote :

This is a patch to more properly fix the build with CMake in:

------------------------------------------------------------
revno: 14668
committer: bryce <email address hidden>
branch nick: inkscape
timestamp: Thu 2016-02-25 10:48:51 -0800
message:
  inkview: Drop use of obsolete getopt

  This lets us drop getopt as a cmake requirement.

  Patch from rindolf, thanks!
  http://www.shlomifish.org/Files/files/code/inkscape-cmake-get-rid-of-getopt-check-2.diff
------------------------------------------------------------

It adds the -std=c++11 flag conditionally if the build fails without it.

I hereby disclaim all explicit or implicit ownership of my changes, and place them under the X11 licence / the public domain (CC Zero) / GPLv1-and-above / any other licence. That put aside crediting me (= http://www.shlomifish.org/ ) will be appreciated but not necessary.

Shlomi Fish (shlomif-gmail) wrote :

here is a new patch with bryce's comments about #if 0 applied.

ScislaC (scislac) on 2016-05-06
tags: removed: blocker
jazzynico (jazzynico) on 2017-01-28
Changed in inkscape:
milestone: 0.91.1 → 0.92
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.