Inkscape fails to build with gcc 4.6

[Alex Valavanis]

Inkscape failed to build on i386 and amd64 in a recent rebuild test of Ubuntu packages with gcc 4.6. The package version in question was inkscape_0.48.0-1ubuntu2. The buildlogs can be found at:

i386: http://launchpadlibrarian.net/62122074/buildlog_ubuntu-natty-i386.inkscape_0.48.0-1ubuntu2_FAILEDTOBUILD.txt.gz
amd64: http://launchpadlibrarian.net/62133948/buildlog_ubuntu-natty-amd64.inkscape_0.48.0-1ubuntu2_FAILEDTOBUILD.txt.gz

The error message is:

/usr/include/sigc++-2.0/sigc++/signal.h:38:11: error: 'ptrdiff_t' does not name a type

I believe this can be fixed by including a #include <cstddef> in connector-context.h (and wherever necessary). Please see the following page for more details: https://wiki.ubuntu.com/GCC4.6

[Lubomir Rintel (lkundrak)]

A fix available in Fedora GIT:
http://pkgs.fedoraproject.org/gitweb/?p=inkscape.git;a=blob_plain;f=inkscape-0.48.0-gcc46.patch;hb=HEAD

[Alex Valavanis (valavanisalex)]

Thanks very much for the patch! I have attached it to this report. Can someone please review it, and consider applying?

[theAdib (theadib)]

I tested the patch under win32 and Ubuntu 10.04. Works.

I attach the diff before pushing.

the Adib

[su_v (suv-lp)]

Inkscape 048+devel r10071 fails to build on OS X 10.5.8 (i386):

  CXX inkscape-version.o
  AR libinkversion.a
  CXX main.o
  CXXLD inkscape
ld: unknown option: --export-dynamic
collect2: ld returned 1 exit status
make[3]: *** [inkscape] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

LeWitt:~ suv$ g++-4.2 --version
i686-apple-darwin9-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577)
LeWitt:~ suv$ which ld
/usr/bin/ld
LeWitt:~ suv$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1

[theAdib (theadib)]

attached a patch for the makefile system to check for macosx and use different link options.

actually I think we should not test for MACOSX or not but for GNU linker or not. I think your linker is not a gnu linker.
But that should give the same results on macosx.

please test and report.

Adib.

[su_v (suv-lp)]

Patch tested with r10074 (not a full rebuild) and fix confirmed (linking is done without failure) on OS X 10.5.8 (i386) with

 $ g++-4.2 --version
 i686-apple-darwin9-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577)

Maybe the test should go along with the other compiler and linker tests in configure.ac (line 43-166)? Among those, there already seems to exist a test for GNU ld, at least according to the output of configure (log attached):

 checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.2.1/ld) is GNU ld... no

which possibly could be reused for the linker flags in 'src/Makefile.am'?

[Jon A. Cruz (jon-joncruz)]

Tweaking things to not look for the platform but to instead test the linker support.

[su_v (suv-lp)]

> Tweaking things to not look for the platform but to instead test the linker support.

That's not what was committed in r10078 as far as I can tell - it just renames the variable which checks the platform. What if GCC 4.6 is used on Mac OS X?

See also: <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/36020>

[Alex Valavanis (valavanisalex)]

A slightly different patch for this issue was submitted in duplicate bug #754870. Please take a look if you feel that it will be useful.

[Emil Karlson (jekarlson)]

So did anyone even bother to think about the reality that --export-dynamic has been _ignored_ in the past and there have been no consequences.

I just included it in my patch with the comment, because I assume you know what you are doing and eg. it might have been there for some other silly compilers.

from http://gcc.gnu.org/gcc-4.6/changes.html

"GCC now has stricter checks for invalid command-line options. In particular, when gcc was called to link object files rather than compile source code, it would previously accept and ignore all options starting with --, including linker options such as --as-needed and --export-dynamic, although such options would result in errors if any source code was compiled. Such options, if unknown to the compiler, are now rejected in all cases; if the intent was to pass them to the linker, options such as -Wl,--as-needed should be used."

[su_v (suv-lp)]

> So did anyone even bother to think about the reality that
> --export-dynamic has been _ignored_ in the past and there
> have been no consequences.

This issue at hand was that some (non-GNU) linkers don't understand the option if passed with '-Wl,--export-dynamic' (as it is now in current trunk [1]) -- the question whether the linker option is required at all was raised in the linked mailing list thread [2], unfortunately no one commented there.

[1] <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/Makefile.am#L215>
[2] <http://article.gmane.org/gmane.comp.graphics.inkscape.devel/36032>

[Alex Valavanis (valavanisalex)]

I tried backporting the upstream patch to the Ubuntu package (inkscape_0.48.1-2ubuntu2) but the build still fails with the following error. I guess it might be a good idea to add #include <cstddef> to 2geom/utils.h

In file included from 2geom/utils.cpp:33:0:
./2geom/utils.h:83:40: error: ‘size_t’ was not declared in this scope
./2geom/utils.h:83:40: note: suggested alternatives:
/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h:155:26: note: ‘std::size_t’
/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h:155:26: note: ‘std::size_t’
./2geom/utils.h:83:46: error: template argument 1 is invalid
./2geom/utils.h:83:46: error: template argument 2 is invalid
./2geom/utils.h:83:53: error: ‘size_t’ has not been declared
2geom/utils.cpp:40:40: error: ‘size_t’ was not declared in this scope
2geom/utils.cpp:40:40: note: suggested alternatives:
/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h:155:26: note: ‘std::size_t’
/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h:155:26: note: ‘std::size_t’
2geom/utils.cpp:40:46: error: template argument 1 is invalid
2geom/utils.cpp:40:46: error: template argument 2 is invalid
2geom/utils.cpp:40:53: error: ‘size_t’ has not been declared
2geom/utils.cpp: In function ‘void Geom::binomial_coefficients(int&, int)’:
2geom/utils.cpp:42:5: error: ‘size_t’ was not declared in this scope
2geom/utils.cpp:42:5: note: suggested alternatives:
/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h:155:26: note: ‘std::size_t’
/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h:155:26: note: ‘std::size_t’
2geom/utils.cpp:42:12: error: expected ‘;’ before ‘s’
2geom/utils.cpp:43:8: error: request for member ‘clear’ in ‘bc’, which is of non-class type ‘int’
2geom/utils.cpp:44:8: error: request for member ‘resize’ in ‘bc’, which is of non-class type ‘int’
2geom/utils.cpp:44:15: error: ‘s’ was not declared in this scope
2geom/utils.cpp:45:9: error: invalid types ‘int[int]’ for array subscript
2geom/utils.cpp:46:12: error: expected ‘;’ before ‘k’
2geom/utils.cpp:47:17: error: expected ‘;’ before ‘i’
2geom/utils.cpp:47:24: error: ‘i’ was not declared in this scope
2geom/utils.cpp:49:9: error: ‘k’ was not declared in this scope
2geom/utils.cpp:54:21: error: expected ‘;’ before ‘j’
2geom/utils.cpp:54:28: error: ‘j’ was not declared in this scope
2geom/utils.cpp:60:17: error: expected ‘;’ before ‘i’
2geom/utils.cpp:60:24: error: ‘i’ was not declared in this scope

[Alex Valavanis (valavanisalex)]

Adding debdiff for Ubuntu changes

[Alex Valavanis (valavanisalex)]

Local build succeeded. Please consider sponsoring the upload for Ubuntu Oneiric

[Alex Valavanis (valavanisalex)]

@upstream - I'm not sure why the patch in trunk doesn't include a #include <cstddef> in 2geom/utils.h. Am I missing something here? I could not get the Ubuntu package to build without adding this to your patch.

[Dave Walker (davewalker)]

inkscape (0.48.1-2ubuntu3) oneiric; urgency=low

  * debian/patches/04-fix-gcc4.6-ftbfs.dpatch: Fix build failure with gcc 4.6
    - Backport upstream patch (lp:inkscape:r10071)
    - Add <cstddef> inclusion to src/2geom/utils.h
 -- Alex Valavanis <email address hidden> Sun, 01 May 2011 01:08:10 +0100

[su_v (suv-lp)]

Alex Valavanis wrote
> I'm not sure why the patch in trunk doesn't
> include a #include <cstddef> in 2geom/utils.h.

@theAdib . any reason you left out the changes for 'to 2geom/utils.h' in your commit (r10071) [1]? It is part of the patch you based your changes on (see comment #2).

[1] <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10071>

Reopening, and subscribing theAdib.

[theAdib (theadib)]

this missing fraction was not intentional. commited as attached. My bad.

[su_v (suv-lp)]

> commited as attached
Inkscape trunk: r10196

Remaining issue (linker option '--export-dynamic' needed or not) still open:
see comment #10 (refers to bug #754870) and <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/36020>

[Alex Valavanis (valavanisalex)]

This was backported to inkscape 0.48.2: r9786
http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_48_BRANCH/revision/9786

[su_v (suv-lp)]

> status: Incomplete → Fix Committed

I'm not sure it is ok to close this report yet: IMHO the question whether the linker flag '--export-dynamic' is needed at all in current Inkscape versions (stable and development) hasn't been addressed so far:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/36020/focus=36358>

[Alex Valavanis (valavanisalex)]

Oops - I forgot about that. Sorry! However, isn't this really a separate issue? The GCC 4.6 build failure (the original purpose of the report) is fixed in trunk and 0.48.2.

Perhaps it would be a good idea to create a follow-up report to deal with the --export-dynamic issue. As far as I can tell, it should be fine to just drop the -Wl,--export-dynamic option because it has been ignored by GCC up until now without any consequences. It seems that the reason for the flag has been lost somewhere in the depths of time... unless anyone has any suggestions for why the flag is needed, maybe we should just try removing it in trunk and keeping our eyes open for any consequences.

[su_v (suv-lp)]

> However, isn't this really a separate issue?

Not sure - isn't it no longer ignored now (on linux&win) with the committed changes for GCC 4.6?
(AFAIU the new '-Wl,--export-dynamic' option explicitly passes it on to the GNU linker, whereas it was silently dropped prior to the changes)

[Alex Valavanis (valavanisalex)]

> AFAIU the new '-Wl,--export-dynamic' option explicitly passes it on to the GNU linker, whereas it was silently dropped prior to the changes

Yes, that's how I understood it too. However, there were still two issues here: the missing <cstddef> headers, and the invalid GCC flag. We have fixed the first one, and found a (dodgy?) workaround for the second. I'm happy enough to reopen this, but just though it would be neater to split off a follow-up report to deal with the --export-dynamic issue.

[su_v (suv-lp)]

> the missing <cstddef> headers (…)

inkscape trunk r10196,
inkscape 0.48.x r9786,
upstream lib2geom r1999
<http://bazaar.launchpad.net/~lib2geom-hackers/lib2geom/trunk/revision/1999>

> (…) and the invalid GCC flag.

> just though it would be neater to split off a
> follow-up report to deal with the --export-dynamic issue.

Agreed - are you willing to file it? ;)

[Alex Valavanis (valavanisalex)]

> are you willing to file it? ;)

Done: bug #808338 <--export-dynamic linker flag may be unnecessary>

[su_v (suv-lp)]

Just for the record (I am aware that the report was closed as 'Fix Released')

~suv wrote in comment #8
>> Tweaking things to not look for the platform but to instead test the linker support.
>
> That's not what was committed in r10078 as far as I can tell - it just renames
> the variable which checks the platform. What if GCC 4.6 is used on Mac OS X?

Changes in r10078:
<https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10078>

Indeed Inkscape 0.48.2 (tarball) and 0.48.x (branch) fails to build with GCC 4.6.2 on OS X 10.7.2 Lion
(current trunk r10927 builds ok with GCC 4.6.2 (fix from bug #808338), and all versions build without failure with using Apple's GCC 4.2.1 or llvm-gcc.-4.2):

  CXXLD inkscape
g++-mp-4.6: error: unrecognized option '--export-dynamic'
make[2]: *** [inkscape] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

This would matter if we want to be able to support building Mac OS X packages of 0.48.x with OpenMP support (not possible when using Apple's old GCC version).

[su_v (suv-lp)]

Inkscape 0.48.2 (tarball) and 0.48.x (r9860) builds on OS X 10.7.2 Lion with attached patch applied to the sources - I haven't had the chance yet to verify the changes with Apple's GCC 4.2.1 nor with llvm-gcc-4.2. The patch seems save though:
1) AFAIU the older GCC version simply dropped the flag (before the changes for this bug) and it was not passed on to linker anyway.
2) Current trunk - which no longer uses the linker flag at all (bug #808338) - builds without issues using Apple's GCC 4.2.1 or llvm-gcc-4.2 as well as with GCC 4.6.2 [1].

The patch is based on the changes in trunk for bug #808338
<https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10437.1.2>

[1] The newer GCC version is installed via MacPorts, and also used to externally build and install all C++ interfaces Inkscape links to: libsigc++, glibmm, cairomm, pangomm, atkmm, gtkmm. Otherwise, using GCC 4.6 for Inkscape alone (for OpenMP support) results in unstable builds, similar to this topic described in the FAQ:
<http://wiki.inkscape.org/wiki/index.php/FAQ#On_Linux.2C_Inkscape_crashes_with_.22invalid_pointer.22_message>

[su_v (suv-lp)]

Correction:
- Inkscape 0.48.2 (tarball) and 0.48.x (r9860) builds on OS X 10.7.2 Lion with attached patch applied to the sources
+Inkscape 0.48.2 (tarball) and 0.48.x (r9860) builds with GCC 4.6.2 on OS X 10.7.2 Lion with attached patch applied to the sources