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

[Boris Samorodov]

Current FreeBSD 10.x for i386 and amd64 uses clang and libc++.
-----
% uname -a
FreeBSD BB049.int.wart.ru 10.0-ALPHA3 FreeBSD 10.0-ALPHA3 #72 r255901: Fri Sep 27 03:26:08 SAMT 2013 <email address hidden>:/usr/obj/usr/src/sys/BB64X amd64

% clang -v
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: x86_64-unknown-freebsd10.0
Thread model: posix
-----

Building Inkscape rev 9969 ends with:
-----
===> Building for inkscape-0.48.5
gmake[2]: Вход в каталог `/usr/ports/graphics/inkscape/work/inkscape-0.48.5'
gmake all-recursive
gmake[3]: Вход в каталог `/usr/ports/graphics/inkscape/work/inkscape-0.48.5'
Making all in src
gmake[4]: Вход в каталог `/usr/ports/graphics/inkscape/work/inkscape-0.48.5/src'
  CXX arc-context.o
  CXX attributes.o
  CXX axis-manip.o
  CXX box3d-context.o
  CXX box3d.o
  CXX box3d-side.o
In file included from arc-context.cpp:25:
In file included from ./display/sp-canvas.h:40:
In file included from ./libnr/nr-rect-l.h:6:
In file included from ./libnr/nr-rect.h:28:
In file included from ./2geom/rect.h:40:
In file included from ./2geom/d2.h:40:
In file included from ./2geom/concepts.h:35:
./2geom/sbasis.h:90:92: error: calling a private constructor of class 'std::__1::__wrap_iter<Geom::Linear *>'
    void insert(Linear* before, const Linear* src_begin, const Linear* src_end) { d.insert(std::vector<Linear>::iterator(before), src_begin, src_end);}
                                                                                           ^
/usr/include/c++/v1/iterator:1195:31: note: declared private here
    _LIBCPP_INLINE_VISIBILITY __wrap_iter(iterator_type __x) _NOEXCEPT : __i(__x) {}
-----

[su_v (suv-lp)]

> 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>

[su_v (suv-lp)]

~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)

[Boris Samorodov (bsam)]

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).

[su_v (suv-lp)]

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 ;-) )

[Markus Engel (engelmarkus)]

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.

[Markus Engel (engelmarkus)]

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

[Boris Samorodov (bsam)]

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.

[Boris Samorodov (bsam)]

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;
                            ^
-----

[Markus Engel (engelmarkus)]

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

[Boris Samorodov (bsam)]

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. ;-)

[Boris Samorodov (bsam)]

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.
-----

[Markus Engel (engelmarkus)]

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

[Boris Samorodov (bsam)]

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

[su_v (suv-lp)]

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?

[Alex Valavanis (valavanisalex)]

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

[Alex Valavanis (valavanisalex)]

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.

[Alex Valavanis (valavanisalex)]

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)

[Alex Valavanis (valavanisalex)]

Targeting this to stable release 0.91.

Anyone have any ideas about the intltool build script issue?

[su_v (suv-lp)]

@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.

[su_v (suv-lp)]

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

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

[su_v (suv-lp)]

@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)

[Boris Samorodov (bsam)]

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.

[su_v (suv-lp)]

@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.

[su_v (suv-lp)]

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?

[su_v (suv-lp)]

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++.