FreeBSD, clang, libc++, inkscape 0.48.x rev9969: calling a private constructor of class (iterator)

> Building Inkscape rev 9969 ends (…)

Please try building a current checkout from the latest release branch lp:inkscape/0.48.x - changes to allow building with clang have recently backported from trunk to the stable release branch (note: there is no new bug-fix release available yet which includes these backported fixes).

See also:
- Bug #1194129 “backport fixes for clang compiler errors to the 0.48.x branch”
  <https://bugs.launchpad.net/inkscape/+bug/1194129>

~suv wrote:
>> Building Inkscape rev 9969 ends (…)
>
> Please try building a current checkout from the latest release branch lp:inkscape/0.48.x (…)

Sorry, my mistake - r9969 is already the latest revision (status of 2013-09-28)

I think that the error occures not because clang is used, but because libc++ is used (current FreeBSD has swithed to it from libstdc++ recently).

Just curious - have you tried to compile latest trunk, too?

As far as I'm aware none of the active developers compiles inkscape with such a build environment - any possibly fixes might take a while… (patches are welcome ;-) )

I just set up a vm with clang 3.3 and libc++ and I can confirm that compilation fails with the current trunk (r12677).
I got it working, but I have to rethink one line once more.
Actually, I'm not sure whether libstdc++ or libc++ is right here. libstdc++ makes some iterator constructors public, which looks rather dangerous to me. This is probably some extension, Visual c++ won't compile this either.

Please try applying this patch. Note that this is a quick fix and some of this code really needs to be rewritten...

Hi Marcus,
and thanks for the patch. However seems that trunk diversed too much (test against inkscape 0.48.x rev9969):
-----
% patch -Cp0 < clang.patch | grep fail
Hunk #2 failed at 145.
Hunk #17 failed at 416.
2 out of 22 hunks failed while patching src/io/uristream.cpp
Hunk #3 failed at 108.
1 out of 4 hunks failed while patching src/io/uristream.h
Hunk #11 failed at 227.
1 out of 11 hunks failed while patching src/io/xsltstream.cpp
Hunk #3 failed at 109.
1 out of 3 hunks failed while patching src/io/xsltstream.h
Hunk #1 failed at 24.
1 out of 1 hunks failed while patching src/sp-item-rm-unsatisfied-cns.cpp
Hunk #1 failed at 16.
1 out of 2 hunks failed while patching src/ui/tool/node.h
-----

I'll try to test trunk.

A try to build trunk:
-----
[...]
In file included from selection-chemistry.cpp:103:
In file included from ./ui/tool/multi-path-manipulator.h:16:
./ui/tool/node.h:43:30: error: class template partial specialization of 'hash' must originally be declared in namespace '__1'
template <typename N> struct hash< Inkscape::UI::NodeIterator<N> >;
                             ^
/usr/include/c++/v1/memory:3129:29: note: explicitly specialized declaration is here
template <class _Tp> struct hash;
                            ^
-----

Could you try adding "-std=c++11" to your CXXFLAGS?

Hm, with this flag configure script seems to pick up the boost lib. The relevant part of configure.log is attached. Not sure if I should wait for the build result against the boost lib. ;-)

Building against boost (with -std=c++11) ended with:
-----
io/inkjar.cpp:119:23: error: no member named 'close' in the global namespace
    if (fd >= 0 && !::close(fd)) {
                    ~~^
io/inkjar.cpp:332:21: error: no member named 'read' in the global namespace; did you mean 'fread'?
    if ((nbytes = ::read(fd, buf, count)) != count) {
                  ~~^~~~
                    fread
/usr/include/stdio.h:246:9: note: 'fread' declared here
size_t fread(void * __restrict, size_t, size_t, FILE * __restrict);
         ^
io/inkjar.cpp:332:40: error: too few arguments to function call, expected 4, have 3
    if ((nbytes = ::read(fd, buf, count)) != count) {
                  ~~~~~~ ^
/usr/include/stdio.h:246:1: note: 'fread' declared here
size_t fread(void * __restrict, size_t, size_t, FILE * __restrict);
^
io/inkjar.cpp:361:22: error: no member named 'read' in the global namespace; did you mean 'fread'?
            if ((nbytes = ::read(fd, in_buffer,
                          ~~^~~~
                            fread
/usr/include/stdio.h:246:9: note: 'fread' declared here
size_t fread(void * __restrict, size_t, size_t, FILE * __restrict);
         ^
io/inkjar.cpp:362:47: error: too few arguments to function call, expected 4, have 3
                                 (leftover_in < RDSZ ? leftover_in : RDSZ)))
                                                                          ^
/usr/include/stdio.h:246:1: note: 'fread' declared here
size_t fread(void * __restrict, size_t, size_t, FILE * __restrict);
^
5 errors generated.
-----

Apply the attached patch (omit the first one) and remove "-ldl" from src/Makefile. Then you should be able to build Inkscape.

Markus, you are totally right -- it works both for FreeBSD 10-amd64 and 10-i386 (build tested).
Big thank you!

Can anyone confirm whether this is fixed for current trunk (rev >= 12847) and lp:inkscape/0.48.x (rev >= 10005) without requiring any local patches?

Building now on BSD-PC 10.0 (64-bit). I'll report back shortly.

I ran a couple of test builds on trunk last night (without specifying CXXFLAGS+="-std=c++11") and there were a few build failures.

One issue seems to be that conditional build terms like this are unreliable:

#if __cplusplus < 201103L
 // Use old C++ features
#else
 // Use C++11 features
#endif

This is because the libc++/clang implementation on BSD-PC 10.0 seems to include some new features by default (e.g., moving hashes to the std namespace instead of std::tr1) but doesn't bump the __cplusplus version key unless you explicitly tell it to use the C++11 standard.

So... as I understand it, "__cplusplus == 201103L" is not a good way of testing that a C++11 feature is present. Instead, we should really implement checks for specific compiler features in autoconf.

OK, as of r13239, I have applied the appropriate patches in trunk. There's one more error relating to the generation of the inkscape.desktop file. I'm really not familiar with intltool etc, so please could someone take a look?

The build simply finishes with the message:

Making all in screens
Making all in symbols
Making all in templates
Making all in tutorials
Making all in ui
Making all in po
make[2]: don't know how to make inkscape.desktop. Stop

Attaching the config log and generated Makefiles (for root and po)

Targeting this to stable release 0.91.

Anyone have any ideas about the intltool build script issue?

@Alex - if I understand correctly, the changes in r13232
- "Fix checking for unordered containers on incomplete C++11 implementations"
  <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13232>
are related to this report (comment #17)?

Could you please take a look at comments #16 and #18 in bug #1244295? It seems that the change indeed [*] breaks building with current clang / libc++ on OS X Mavericks.

[*] I know that the changes in r13232 break building with older clang and libstdc++ on OS X Lion if using CXXFLAGS="-std=c++11", but that's not a recommended configuration anyway, so I had not bothered to report it myself.

> Could you please take a look at comments #16 and #18 in bug #1244295?

Sorry, I meant to refer to comments #16 and #17.

@Alex - any updates on the current status for the targeted milestone?

(Please ignore comment #22-23, they are no longer relevant since the code in question was later removed in r13404)

As for me, inkscape-4.8.5 builds fine:
http://portsmon.freebsd.org/portoverview.py?category=graphics&portname=inkscape

Thanks all for your hard work.

@Boris - thx for the feedback.

Removing 'backport-proposed' tag, since current stable 0.48.5 seems to have all required fixes to support building on FreeBSD.

On 2014-04-07 18:07 (+0100), Alex Valavanis wrote:
> Targeting this to stable release 0.91.
>
> Anyone have any ideas about the intltool build script issue?
>
> ** Changed in: inkscape
> Milestone: None => 0.91

Please update the bug status or the milestone - is there anything needed which needs to go into <lp:inkscape/0.91.x> in time for upcoming release of 0.91?

Due to lack of further feedback, closing as 'Fix released' with milestone 0.48.5 based on the original bug description and the reporter's feedback in comment 25.

Please file separate reports for any remaining (or newly introduced) Issues when compiling current stable Inkscape 0.91 or unstable 0.91+devel with clang and libc++.