Crashes in static constructors

[yurivict]

Program received signal SIGSEGV, Segmentation fault.
0x000000080a833d78 in vtable for __cxxabiv1::__si_class_type_info () from /lib/libcxxrt.so.1
(gdb) bt
#0  0x000000080a833d78 in vtable for __cxxabiv1::__si_class_type_info () at /lib/libcxxrt.so.1
#1  0x0000000804c4af86 in __dynamic_cast () at /usr/local/lib/gcc8/libstdc++.so.6
#2  0x0000000804cc9db0 in bool std::has_facet<std::ctype<char> >(std::locale const&) () at /usr/local/lib/gcc8/libstdc++.so.6
#3  0x0000000804cbd154 in std::basic_ios<char, std::char_traits<char> >::_M_cache_locale(std::locale const&) () at /usr/local/lib/gcc8/libstdc++.so.6
#4  0x0000000804cbd5d0 in std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*) () at /usr/local/lib/gcc8/libstdc++.so.6
#5  0x0000000804c5e953 in std::ios_base::Init::Init() () at /usr/local/lib/gcc8/libstdc++.so.6
#6  0x0000000000436bf5 in __static_initialization_and_destruction_0(int, int) (__initialize_p=1, __priority=65535) at /usr/local/lib/gcc8/include/c++/iostream:74
#7  0x0000000000436c1f in _GLOBAL__sub_I__ZN7ControlC2EP15GladeSearchpath() () at /usr/ports/graphics/xournalpp/work/xournalpp-1.0.7-130-g593280b8/src/control/Control.cpp:3
162
#8  0x00000008008637ab in objlist_call_init (list=<optimized out>, lockstate=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:2657
#9  0x00000008008626ac in _rtld (sp=<optimized out>, exit_proc=0x7fffffffe7e0, objp=0x7fffffffe7e8) at /usr/src/libexec/rtld-elf/rtld.c:770
#10 0x00000008008606f9 in .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:39
#11 0x0000000000000000 in  ()

FreeBSD 11.2, using gcc-8.

[LittleHuba]

Please provide the list of commands you used. And try once more with cleared CMake cache. I've seen in issue #850 that you switched compiler, which can corrupt the CMake cache.

[yurivict]

No cmake cache is preserved. I did a clean rebuild in the port directory.

[LittleHuba]

Thanks for reporting!
I'll set up a VM and try to reproduce your problem. Please do not create further issues concerning the build process on FreeBSD until I get back to you. There are already to many to keep an overview...

[yurivict]

On FreeBSD, in /usr/ports, please extract this shar https://people.freebsd.org/~yuri/xournalpp.shar
Then cd graphics/xournalpp && make should build it.

You can also first run pkg install gcc8 cmake portaudio gdk-pixbuf2 gtk30 libxml2 , this should install all binary dependencies.

Removing USE_GCC and rebuilding would reproduce the other problem that I reported.

[LittleHuba]

I just pushed some fixes for cmake to enable builds on FreeBSD.

Following the build instructions Xournal++ builds without issues.

As an additional pointer: The dependencies listed above are not all required dependencies. Please take a look at the dependencies listed under the previous link.

[yurivict]

Crash with gcc is still there though.

[LittleHuba]

Please use the toolchain we provide in the linked document. With this toolchain it builds just fine.

[yurivict]

@LittleHuba I use the same toolchain as described there. It only mentions cmake in the document, and I use cmake.

[LittleHuba]

I'll take a look at your packaging scripts on saturday. You can build Xournal++ once without the packaging scripts and with the toolchain I linked to make sure there is no issue in your system.
Please also post the output of cmake so I can check it.

[yurivict]

-- The CXX compiler identification is GNU 8.2.0
-- The C compiler identification is GNU 8.2.0
-- Check for working CXX compiler: /usr/local/bin/g++8
-- Check for working CXX compiler: /usr/local/bin/g++8 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/local/bin/gcc8
-- Check for working C compiler: /usr/local/bin/gcc8 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
CMake Warning at cmake/include/Version.cmake:6 (message):
  DEB Generator: Can't find lsb_release in your path.  Setting
  DISTRO_CODENAME to unknown.
Call Stack (most recent call first):
  CMakeLists.txt:17 (include)


-- Found Git: /usr/local/bin/git (found version "2.20.1") 
-- Found PkgConfig: pkgconf (found version "1.5.4") 
-- Performing Test GNUXX11
-- Performing Test GNUXX11 - Success
-- Checking for module 'gtk+-3.0 >= 3.18.9'
--   Found gtk+-3.0 , version 3.22.30
-- Checking for module 'glib-2.0 >= 2.32.0'
--   Found glib-2.0 , version 2.56.3
-- Checking for module 'gthread-2.0 >= 2.4.0'
--   Found gthread-2.0 , version 2.56.3
-- Checking for module 'libxml-2.0 >= 2.0.0'
--   Found libxml-2.0 , version 2.9.8
-- Checking for module 'poppler-glib >= 0.41.0'
--   Found poppler-glib , version 0.72.0
-- Found ZLIB: /usr/lib/libz.so (found version "1.2.11") 
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Found Threads: TRUE  
-- Checking for module 'portaudiocpp >= 12'
--   Found portaudiocpp , version 12
-- Checking for module 'sndfile >= 1.0.25'
--   Found sndfile , version 1.0.28
-- Checking for module 'gtk-mac-integration'
--   Package 'gtk-mac-integration', required by 'virtual:world', not found
-- Found Gettext: /usr/local/bin/xgettext (found version "0.19.8.1") 

Configuration:
	Compiler:                   /usr/local/bin/g++8
	CppUnit enabled:            OFF

-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_CXX_FLAGS_DEBUG
    CMAKE_C_FLAGS_DEBUG
    CMAKE_C_FLAGS_RELEASE
    CMAKE_MODULE_LINKER_FLAGS
    CMAKE_SHARED_LINKER_FLAGS
    CMAKE_VERBOSE_MAKEFILE


-- Build files have been written to: /usr/ports/graphics/xournalpp/work/.build

[yurivict]

So, there are 2 problems:

• gcc-built executable crashes on startup, in static constructors
• clang build fails with undefined symbol when WITH_DEBUG= isn't given

[LittleHuba]

I tried to find the actual problem today but did not get really far.

The things I currently know:

• GCC has a known problem where it does incorrect linking against libstdc++. The only way around that "bug" is providing a certain order of project files to the compiler and linker. I would like to avoid that since any change to the project could silently break that in the future.
• Clang has also some problems with linking but I'm unsure why.

Still the most obvious problem is that your package does not build the same way as our toolchain for some reason. Would you mind pointing out where I can look at the actual commands the package is firing for the build? I'm unfortunately not fluent enough in the packaging system of FreeBSD to find it by myself.

[yurivict]

configure command:

/bin/mkdir -p /usr/ports/graphics/xournalpp/work/.build
cd /usr/ports/graphics/xournalpp/work/.build; /usr/bin/env PKG_CONFIG=pkgconf XDG_DATA_HOME=/usr/ports/graphics/xournalpp/work  XDG_CONFIG_HOME=/usr/ports/graphics/xournalpp/work  HOME=/usr/ports/graphics/xournalpp/work PATH=/usr/ports/graphics/xournalpp/work/.bin:/home/yuri/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin SHELL=/bin/sh CONFIG_SHELL=/bin/sh LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 /usr/local/bin/cmake -DCMAKE_C_COMPILER:STRING="cc"  -DCMAKE_CXX_COMPILER:STRING="c++"  -DCMAKE_C_FLAGS:STRING="-pipe -fno-omit-frame-pointer  -g -fstack-protector -fno-strict-aliasing "  -DCMAKE_C_FLAGS_DEBUG:STRING="-pipe -fno-omit-frame-pointer  -g -fstack-protector -fno-strict-aliasing "  -DCMAKE_C_FLAGS_RELEASE:STRING="-pipe -fno-omit-frame-pointer  -g -fstack-protector -fno-strict-aliasing "  -DCMAKE_CXX_FLAGS:STRING="-pipe -fno-omit-frame-pointer -g -fstack-protector -fno-strict-aliasing -fno-omit-frame-pointer  "  -DCMAKE_CXX_FLAGS_DEBUG:STRING="-pipe -fno-omit-frame-pointer -g -fstack-protector -fno-strict-aliasing -fno-omit-frame-pointer  "  -DCMAKE_CXX_FLAGS_RELEASE:STRING="-pipe -fno-omit-frame-pointer -g -fstack-protector -fno-strict-aliasing -fno-omit-frame-pointer  "  -DCMAKE_EXE_LINKER_FLAGS:STRING=" -fstack-protector "  -DCMAKE_MODULE_LINKER_FLAGS:STRING=" -fstack-protector "  -DCMAKE_SHARED_LINKER_FLAGS:STRING=" -fstack-protector "  -DCMAKE_INSTALL_PREFIX:PATH="/usr/local"  -DCMAKE_BUILD_TYPE:STRING="Debug"  -DTHREADS_HAVE_PTHREAD_ARG:BOOL=YES  -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=YES  -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -GNinja /usr/ports/graphics/xournalpp/work/xournalpp-1.0.7-135-g2f5b575e

Build command:

MAKE_ENV=XDG_DATA_HOME=/usr/ports/graphics/xournalpp/work  XDG_CONFIG_HOME=/usr/ports/graphics/xournalpp/work  HOME=/usr/ports/graphics/xournalpp/work PATH=/usr/ports/graphics/xournalpp/work/.bin:/home/yuri/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin DONTSTRIP=yes NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES DESTDIR=/usr/ports/graphics/xournalpp/work/stage LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 PREFIX=/usr/local  LOCALBASE=/usr/local  CC="cc" CFLAGS="-pipe -fno-omit-frame-pointer  -g -fstack-protector -fno-strict-aliasing "  CPP="cpp" CPPFLAGS="-fno-omit-frame-pointer"  LDFLAGS=" -fstack-protector " LIBS=""  CXX="c++" CXXFLAGS="-pipe -fno-omit-frame-pointer -g -fstack-protector -fno-strict-aliasing -fno-omit-frame-pointer  "  MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install   -m 555"  BSD_INSTALL_LIB="install   -m 0644"  BSD_INSTALL_SCRIPT="install  -m 555"  BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"

MAKE_ARGS=-v

$(MAKE_ENV) gmake $(MAKE_ARGS)

It sets CC=cc, CXX=c++ which are clang60.

I don't understand what do you mean when you say that it doesn't use the recommended toolchain. What should be changed in the above to follow this toolchain?

[LittleHuba]

I currently have no access to the VM so digging into those steps will have to wait.

The one major thing that comes to mind is that you use gmake and not make. Those two programs are not completely compatible. That might be the problem. If not it is most likely some of the arguments you provide. Which one I can't say yet.

I don't understand what do you mean when you say that it doesn't use the recommended toolchain. What should be changed in the above to follow this toolchain?

That is actually a very easy thing to determine. Since building with the commands we list works on FreeBSD our toolchain is doing what it should do. Since your package does not build, the problem is somewhere within your package.

But where exactly that problem is, is the real question...

You should tinker with the arguments of your build steps somewhat. And switch from gmake to make (that is where your toolchain mainly differs from ours). Maybe that will fix it. I'll do some more digging next week if you haven't found the solution until then.

No worries we'll get there!

[yurivict]

GNU make on linux is named ````gmake``` on FreeBSD, this is the same program.

[yurivict]

@LittleHuba For the missing symbol problem with clang, did you build with optimization? The problem only exists when built in Release mode.

[LittleHuba]

I've seen your PR for the missing symbol. Does that fix building in the package? I have some time to help you again following this wednesday.

[LittleHuba]

To reference the PR with this issue: #899

[yurivict]

I've seen your PR for the missing symbol. Does that fix building in the package? I have some time to help you again following this wednesday.

Thank you for your help! The #899 fix didn't solve this problem, unfortunately. It crashed only with the gcc compiler.

[LittleHuba]

You will have to provide an updated port package or otherwise I won't be able to help you. I already invested enough time as it is by setting up the VM and everything. Please use at least release 1.0.8 for the package as only that one includes all the fixes we need.

As for GCC:

GCC has a known problem where it does incorrect linking against libstdc++. The only way around that "bug" is providing a certain order of project files to the compiler and linker. I would like to avoid that since any change to the project could silently break that in the future.

If Clang is working for a build we won't support GCC on FreeBSD.

[yurivict]

To reproduce the problem with gcc, USE_GCC=yes should be added to the Makefile. The port is already updated, as it is.

Based on the way it fails it appears that static constructors order might matter, which might indicate a bug in the project.

[LittleHuba]

If Clang is working for a build we won't support GCC on FreeBSD.

Is it working with Clang?

[yurivict]

Is it working with Clang?

Yes.

[LittleHuba]

Xournal++ builds on Arch just fine using gcc 8.2.1.

Since building with clang works on FreeBSD I won't fix this bug but if you want to dig into the issue you are very welcome. Currently I think this is a problem of the gnu compiler and specific to FreeBSD as others are complaining about that bug as well. And all bugs have in common that it happens in FreeBSD.