LibreCAD on FreeBSD

Hello!
My system is FreeBSD 13.1
LibreCAD version is 2.2.0.r4, installed via pkg install librecad

When selecting Tools > Line > Orthogonal it's impossible to select base entity.
The same goes for Tools > Line > Relative angle.
The same version of LibreCAD does not have this problem on linux.

I just tested this with a FreeBSD VM and can confirm this behavior.

As it was already a pain for me to get a FreeBSD with GUI and LibreCAD running, I won't set this VM up for development. I have no experience with FreeBSD.

Selecting basically works, even Orthogonal worked for me on arcs, but not for lines.
I have no idea yet what can cause this behavior.

Best is to report this issue on FreeBSD. The package maintainer is welcome to get in touch with me to get behind this issue.
I would try another Qt version first or compiler version.
Are there any patches applied to the source code?

Hi, I'm the package maintainer for LibreCAD on FreeBSD (jhale@freebsd.org).

I bisected the source code and traced the problem to d0a0ef2.

FreeBSD uses Clang to build packages on mainstream platforms (amd64/i386). The code compiles without local patches, but looking at the build logs, I'm seeing warnings like this:

In file included from actions/rs_actiondrawcircletan2.cpp:26:
actions/rs_actiondrawcircletan2.h:82:53: warning: array backing local initializer list 'enTypeList' will be destroyed at the end of the full-expression [-Wdangling]
    const EntityTypeList enTypeList = EntityTypeList{RS2::EntityLine, RS2::EntityArc, RS2::EntityCircle};

Reverting eb2e146 and d0a0ef2 fixes the problem.

Many thanks @jhale!

Your efforts with bisecting lead to the right place.
This issue is because of a strange clang interpretation of C++ language.
The referenced commits were C++11 refactoring. The Visual Studio Error C2797 was caused by a VS regression which was solved in later VS 2013.
But even the d0a0ef2 code, which is valid for GCC and VS 2015, does not work with Clang.

So I challenged to set up my FreeBSD VM to debug this and I found a solution.
I created issue #1568 to document this.
The fix will be pushed later today.

I assume, that this will be one of the last commits before I tag finally 2.2.0 official release.
So you can fix this with an update soon.

Looks good to me. Thanks!

I think this issue is now fixed in the master branch by one of my recent coding style review fixes.

The root cause was due to wrong usage of initializer lists: copying an initializer list may cause undefined behaviors, because the list range is copied without a copy of the list data. This is not due to a defect of compilers.