cmake issues with Ubuntu 14.04 lts

Bug #1640899 reported by David Mathog
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Invalid
Undecided
Unassigned

Bug Description

cmake issues have been seen with two different systems running Ubuntu 14.04 lts, both 32 bits. However, they are not the same issues!
System "A" was installed with the earliest 14.04 lts.
System "B" was installed with 14.04.5 lts.

Both have been brought up to date as much as possible with:

apt-get update
apt-get dist-upgrade

System "A" was also updated to use kernel 4.2.0-42-generic, to see if that brought in
any other packages, which was not the case.

then

# system A, with bzr update the source in /usr/local/src/inkscape_trunk
mkdir /usr/local/src/inkscape_trunk/build
cd /usr/local/src/inkscape_trunk/build

# system B, with bzr install source in /usr/local/src/inkscape
mkdir /usr/local/src/inkscape/build
cd /usr/local/src/inkscape/build

#on both A and B

cmake ..
make

One might have thought these systems would behave the same - they do not. Problems:

1. On "A". The first time cmake is run it sets

PACKAGE_LOCALE_DIR /share/locale

but it it is run again right after that it sets instead:

PACKAGE_LOCALE_DIR /usr/local/share/locale

The first is clearly wrong as there is no such directory on the system.

2. On "A" during the make it stops at:
src/CMakeFiles/inkscape_base.dir/ui/widget/dock.cpp.o
In file included from /usr/include/glib-2.0/gobject/gobject.h:24:0,
                 from /usr/include/glib-2.0/gobject/gbinding.h:29,
                 from /usr/include/glib-2.0/glib-object.h:23,
                 from /usr/include/glibmm-2.4/glibmm/class.h:25,
                 from /usr/include/glibmm-2.4/glibmm/objectbase.h:23,
                 from /usr/include/glibmm-2.4/glibmm/object.h:29,
                 from /usr/include/pangomm-1.4/pangomm/context.h:32,
                 from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
                 from /usr/include/gtkmm-3.0/gtkmm/container.h:29,
                 from /usr/include/gtkmm-3.0/gtkmm/box.h:28,
                 from
/usr/local/src/inkscape_trunk/src/ui/widget/dock.h:15,
                 from
/usr/local/src/inkscape_trunk/src/ui/widget/dock.cpp:13:
/usr/local/src/inkscape_trunk/src/ui/widget/dock.cpp: In constructor
‘Inkscape::UI::Widget::Dock::Dock(Gtk::Orientation)’:
/usr/local/src/inkscape_trunk/src/ui/widget/dock.cpp:55:70: error:
cannot convert ‘GdlDock* {aka _GdlDock*}’ to ‘GObject* {aka _GObject*}’
for argument ‘1’ to ‘GtkWidget* gdl_dock_bar_new(GObject*)’
       _gdl_dock_bar(GDL_DOCK_BAR(gdl_dock_bar_new(GDL_DOCK(_gdl_dock)))),

The reason it does this is that libgdl on this system is 3.8.1, but the code in dock.cpp
has:
#if WITH_GDL_3_6
      _gdl_dock_bar(GDL_DOCK_BAR(gdl_dock_bar_new(G_OBJECT(_gdl_dock)))),
#else
      _gdl_dock_bar(GDL_DOCK_BAR(gdl_dock_bar_new(GDL_DOCK(_gdl_dock)))),
#endif

Adding -DWITH_GDL_3_6 (manually) to the command line compiles this module. When cmake runs it logs:

   Using GDL 3.6 or higher

but for some reason on this system it is not setting the definition for the compilation of the module.

3. On "A" at the final link to build the inkscape application it fails with:

[ 97%] [ 97%] Building CXX object
src/CMakeFiles/inkview.dir/inkview.cpp.o
Building CXX object src/CMakeFiles/inkscape.dir/main.cpp.o
Linking CXX executable ../bin/inkview
../lib/libinkscape_base.so: undefined reference to `_cmsChannelsOf'
../lib/libinkscape_base.so: undefined reference to `cmsTakeProductDesc'
../lib/libinkscape_base.so: undefined reference to `cmsTakeProductName'
../lib/libinkscape_base.so: undefined reference to `cmsErrorAction'
../lib/libinkscape_base.so: undefined reference to `cmsSetErrorHandler'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/inkview] Error 1
make[1]: *** [src/CMakeFiles/inkview.dir/all] Error 2

The system has both liblcm1 and liblcms2-2. There is a -llcms2 in the
link command, changing it to -llcms in that command lets the link
complete. The cmake log file has:

-- Found LCMS2: /usr/lib/i386-linux-gnu/liblcms2.so
ENABLE_LCMS: ON

So cmake seem to be confused on this system as to which lcms it is using.

4. On "B" in make following cmake:

CMake Error at /usr/local/src/inkscape/CMakeScripts/inkscape-version.cmake:25
(string):
  string does not recognize sub-command CONCAT

because cmake is 2.8.12 but the CONCAT requires 3.x, according to:

https://github.com/stepmania/stepmania/issues/549

Problem 4 is well before problems 2 and 3 would have been observed, so 2 and 3 might show up there if make ever got that far.

Problems 1-4 have been discussed with Marc Jeanmougin who is running a very similar Ubuntu system
in a virtual machine and does not see any of these issues.

Software versions on A:

apt-cache show libgtkmm-3.0-dev | grep Version
Version: 3.10.1-0ubuntu2
apt-cache show libglibmm-2.4-dev | grep Version
Version: 2.39.93-0ubuntu1
apt-cache show libglib2.0-dev | grep Version
Version: 2.40.0-2
apt-cache show libgdl-3-dev | grep Version
Version: 3.8.1-2ubuntu1
% cmake --version
cmake version 2.8.12.2
% bash --version
GNU bash, version 4.3.11(1)-release (i686-pc-linux-gnu)

MJ reported the same versions on his system (other than bash, which I forgot
to ask him about).

Revision history for this message
David Mathog (mathog) wrote :

On system "A" the attached file is the output from

cmake ..

when run in freshly created and empty build subdirectory.

Revision history for this message
David Mathog (mathog) wrote :

The attached file is the output of

cmake ..

when it is run a 2nd time in the build subdirectory, immediately following the first run.

Among other changes

PACKAGE_LOCALE_DIR /share/locale

in the first (/share is not a real directory) becomes

PACKAGE_LOCALE_DIR /usr/local/share/locale

(which is a real directory)

Revision history for this message
David Mathog (mathog) wrote :

The attached CMakeCache.txt is the result after the 2nd cmake in the build subdirectory.

Revision history for this message
David Mathog (mathog) wrote :

inkscape-version.cmake from system A, this one does not cause any issues. Will post the one from system B later today, when I can access it.

su_v (suv-lp)
tags: added: build cmake
Revision history for this message
David Mathog (mathog) wrote :

Compile command which fails for dock.cpp on system A (lacks -DWITH_GDL_3_6)

cd /usr/local/src/inkscape_trunk/build/src && /usr/bin/c++ -DHAVE_CAIRO_PDF=1 -DHAVE_CONFIG_H -DHAVE_POTRACE -DHAVE_TR1_UNORDERED_SET -DLPE_ENABLE_TEST_EFFECTS -DORBIT2=1 -DWITH_CSSBLEND -DWITH_CSSCOMPOSITE -DWITH_LPETOOL -DWITH_MESH -DWITH_SVG2 -D_FORTIFY_SOURCE=2 -Dinkscape_base_EXPORTS -fopenmp -pthread -std=c++11 -O3 -DNDEBUG -fPIC -I/usr/local/src/inkscape_trunk/build/src -I/usr/local/src/inkscape_trunk/src -I/usr/local/src/inkscape_trunk -I/usr/local/src/inkscape_trunk/build/include -isystem /usr/include/harfbuzz -isystem /usr/include/pango-1.0 -isystem /usr/include/cairo -isystem /usr/include/glib-2.0 -isystem /usr/lib/i386-linux-gnu/glib-2.0/include -isystem /usr/include/pixman-1 -isystem /usr/include/freetype2 -isystem /usr/include/libpng12 -isystem /usr/include/gnome-vfs-2.0 -isystem /usr/include/gc -isystem /usr/include/poppler -isystem /usr/include/gtkmm-3.0 -isystem /usr/lib/i386-linux-gnu/gtkmm-3.0/include -isystem /usr/include/atkmm-1.6 -isystem /usr/include/giomm-2.4 -isystem /usr/lib/i386-linux-gnu/giomm-2.4/include -isystem /usr/include/pangomm-1.4 -isystem /usr/lib/i386-linux-gnu/pangomm-1.4/include -isystem /usr/include/gtk-3.0 -isystem /usr/include/cairomm-1.0 -isystem /usr/lib/i386-linux-gnu/cairomm-1.0/include -isystem /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/gtk-3.0/unix-print -isystem /usr/include/gdkmm-3.0 -isystem /usr/lib/i386-linux-gnu/gdkmm-3.0/include -isystem /usr/include/atk-1.0 -isystem /usr/include/glibmm-2.4 -isystem /usr/lib/i386-linux-gnu/glibmm-2.4/include -isystem /usr/include/sigc++-2.0 -isystem /usr/lib/i386-linux-gnu/sigc++-2.0/include -isystem /usr/include/at-spi2-atk/2.0 -isystem /usr/include/gio-unix-2.0 -isystem /usr/include/libgdl-3.0 -isystem /usr/include/libxml2 -pthread -fPIC -o CMakeFiles/inkscape_base.dir/ui/widget/dock.cpp.o -c /usr/local/src/inkscape_trunk/src/ui/widget/dock.cpp

Revision history for this message
David Mathog (mathog) wrote :

Link command which fails for inkscape on system A (has -llcms2, works with -lcms)

cd /usr/local/src/inkscape_trunk/build/src && /usr/bin/cmake -E cmake_link_script CMakeFiles/inkscape.dir/link.txt --verbose=1
/usr/bin/c++ -fopenmp -pthread -std=c++11 -O3 -DNDEBUG CMakeFiles/inkscape.dir/main.cpp.o -o ../bin/inkscape -rdynamic ../lib/libinkscape_base.so ../lib/libnrtype_LIB.a ../lib/libcroco_LIB.a ../lib/libavoid_LIB.a ../lib/libcola_LIB.a ../lib/libvpsc_LIB.a ../lib/liblivarot_LIB.a ../lib/libuemf_LIB.a ../lib/lib2geom_LIB.a ../lib/libdepixelize_LIB.a ../lib/libutil_LIB.a ../lib/libgc_LIB.a -pthread -Wl,--export-dynamic -lharfbuzz -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lfontconfig -lfreetype -lgthread-2.0 -lgsl -lgslcblas -lm -lgmodule-2.0 -lglib-2.0 -lharfbuzz -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lfontconfig -lfreetype -lgthread-2.0 -lgsl -lgslcblas -lm -lgmodule-2.0 -lglib-2.0 -lX11 -lgnomevfs-2 -llcms2 -lc -lgc -lpoppler -lpoppler-glib -lcairo -lwpg-0.2 -lwpd-0.9 -lwpd-stream-0.9 -ljpeg -lpng -lpopt -lpotrace -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 -lgdl-3 -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lfreetype -laspell -lxslt -lxml2 -lz -lsigc-2.0 -Wl,-rpath,/usr/local/src/inkscape_trunk/build/lib

First cmake in the build directory emitted:

-- Found LCMS2: /usr/lib/i386-linux-gnu/liblcms2.so
ENABLE_LCMS: ON

Second cmake only emitted:
ENABLE_LCMS: ON

Revision history for this message
David Mathog (mathog) wrote :

on System B (one of my home machines):

1. exactly the same versions as listed in post 1
2. exactly the same inkscape-version.cmake (compared with diff)
3. cmake was run ONCE so it has the bogus /share/locale value, run it again, it now
   has the /usr/local/share/locale value.

ran "make" again, and this time it got past problem 4 from the first post. So in summary, that is a glitch when cmake is run only once on these systems, run it twice and then it works. Unclear if that is a direct result of the /share/locale vs. /usr/local/share/locale values. Does it get to problems 2 and 3? Nope it went boom at a link on one of the libraries. The next "make" bombed at the inkscape-version.cmake again! Aargh!

I'm running this as root, could that be the problem?

As it stands now cmake builds just are not working right on either of these systems. The autogen.sh etc. are no longer in the distribution, so short of a lot of manual intervention (on "A") and who knows what (on "B") I cannot build Inkscape any more on this version of Ubuntu.

Revision history for this message
Mc (mc...) wrote :

I pushed a fix for the CONCAT problem in r15292.

Revision history for this message
David Mathog (mathog) wrote :

I just noticed that CMakeScripts/DefineDependsandFlags.cmake has these lines (in three very
different positions, not clustered as shown here):

         set (HAVE_LIBLCMS2 1)
             set (HAVE_LIBLCMS1 1)
         set (WITH_GDL_3_6 1)

whereas all the other "set" commands have "ON" instead of "1". Both of these sections are broken for me - so a 100% correlation with "1" syntax and a broken build. These were changed
from 1 to "ON" and cmake run again. No joy with "make" though - it still has the same problems with these two on my test system A (as described previously).

That makes sense because grep still cannot find the string "GDL" in Makefile or in the CMakeFiles tree.

Revision history for this message
David Mathog (mathog) wrote :

Tried a few other things. Try this to clear up the GDL issue:

In CMakeScripts/DefineDependsandFlags.cmake changed

    if("${GDL_3_6_FOUND}")
        message("Using GDL 3.6 or higher")
        set (WITH_GDL_3_6 ON)
    endif()

to

    if("${GDL_3_6_FOUND}")
        message("Using GDL 3.6 or higher")
        add_definitions(-DWITH_GDL_3_6)
        set (WITH_GDL_3_6 ON)
    endif()

For liblcms vs liblcms2, on a system which has both, the cmake output says:

-- Found LCMS2: /usr/lib/i386-linux-gnu/liblcms2.so
ENABLE_LCMS: ON

and it dutifully puts on -llcms2 where -llcms is apparently required. CMakeScripts/Modules has both FindLCMS2.cmake and FindLCMS.cmake and CMakeScripts/DefineDependsandFlags.cmake tests for
LCMS2 first and goes with that if it finds it. However, src/color-profile.cpp has a section
like

#if HAVE_LIBLCMS1
#elif HAVE_LIBLCMS2
#endif

and the compile is definitely using the first clause even though Cmake says the 2nd version is found and it takes precedence:

if(ENABLE_LCMS)
    find_package(LCMS2)
    if(LCMS2_FOUND)
 list(APPEND INKSCAPE_INCS_SYS ${LCMS2_INCLUDE_DIRS})
 list(APPEND INKSCAPE_LIBS ${LCMS2_LIBRARIES})
 add_definitions(${LCMS2_DEFINITIONS})
        set (HAVE_LIBLCMS2 ON)
    else()
        find_package(LCMS)
        if(LCMS_FOUND)
            list(APPEND INKSCAPE_INCS_SYS ${LCMS_INCLUDE_DIRS})
            list(APPEND INKSCAPE_LIBS ${LCMS_LIBRARIES})
            add_definitions(${LCMS_DEFINITIONS})
            set (HAVE_LIBLCMS1 ON)
        else()
            set(ENABLE_LCMS OFF)
        endif()
    endif()
endif()

Added these as the 2nd and 3rd lines in the preceding, just in case something earlier
was setting them to default states:

    unset(HAVE_LIBLCMS1)
    unset(HAVE_LIBLCMS2)

cmake ..
make

the dock problem was resolved but the final lcms1 vs. lcms2 link issue is still there.

Revision history for this message
David Mathog (mathog) wrote :

Patch which adds "-DWITH_GDL_3_6" on some compile lines which helps with a build on Ubuntu 14.04 LTS. Committed as revision 15527. This does not resolve the final link issue, where it confuses cms1 and cms2.

Revision history for this message
Qantas94Heavy (qantas94heavy) wrote :

Hi, this seems extremely odd and probably something to do with weird CMake caching issues or problems with your installation. For example the /share/locale thing is determined by CMAKE_INSTALL_PREFIX which should be set by CMake if you have not overridden it -- we don't touch it at all.

As none of us can reproduce these issues unfortunately I'll have to close this issue. Probably best advice would be to check for conflicting installations or libraries in /usr/local as they can affect the system versions.

If you can still reproduce these issues with the latest Inkscape version, please file a bug on our new bug tracker: https://inkscape.org/report. Thank you!

Closed by: https://gitlab.com/Qantas94Heavy

Changed in inkscape:
status: New → Invalid
tbnorth (terry-n-brown)
tags: added: bug-migration
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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