Failure when compiling with static libs

[efifogel]

Issue Details

Every program that uses CGAL and is linked with static lib creashes

Source Code

Below is a simple test case and a small script that compiles and links the program with static libraries.
The script, naturally, must be edited. One can also use the attached CMakeLists.txt.
It fails on version 5.4 but works properly on version 5.3.
More precisely, it fails on commit:
5072518, Thu Jul 29 14:31:10 2021 +0200
but works fine with the one before that, namely:
bdba6ee

I get:
[ola] test > ./mytest
s: 4 4 1 5
r1: 3 2 3 3
before 0
xp: 3 4.33333
terminate called after throwing an instance of 'std::system_error'
what(): Unknown error -1
Aborted (core dumped)

When the program is compiled with shared libraries it works fine.

Environment

• Operating system: Ubuntu 20.04
• Compiler: g++ 9.4.0
• Release or debug mode:
• Specific flags used (if any):
• CGAL version: started somewhere between 5.3 and 5.4
• Boost version: irrelevant, but 1.79
• Other libraries versions if used (Eigen, TBB, etc.): it is probably irrelevant, cmake (3.25.1), boost (1.79), gmp (6.2.0), and mpfr (4.0.2)

CMakeLists.txt

#include <CGAL/Exact_predicates_exact_constructions_kernel.h>
int main() {
  using Kernel = CGAL::Exact_predicates_exact_constructions_kernel;
  using Pt = Kernel::Point_2;

  Kernel kernel;
  const auto ctr_ray = kernel.construct_ray_2_object();
  const auto ctr_seg = kernel.construct_segment_2_object();
  const auto intersect = kernel.intersect_2_object();

  auto s = ctr_seg(Pt(4,4), Pt(1,5));
  auto r1 = ctr_ray(Pt(3,2), Pt(3,3));

  const auto eq = kernel.equal_2_object();
  std::cout << "s: " << s << std::endl;
  std::cout << "r1: " << r1 << std::endl;
  auto res = intersect(s, r1);
  if (! res) {
    std::cout << "No intersection\n";
    return -1;
  }
  const Pt* xp = boost::get<Pt>(&*res);
  if (! xp) {
    std::cout << "No point intersection\n";
    return -1;
  }
  std::cout << "before 0\n";
  std::cout << "xp: " << *xp << std::endl;
  auto rc = eq(*xp, *xp);
  std::cout << "rc: " << rc << std::endl;
  std::cout << "after 1\n";
  return 1;
}

g++ mytest.cpp -o mytest \
-static-libgcc -static-libstdc++ -static \
-DCGAL_USE_GMPXX=1 \
-isystem /home/efif/trees/cgal/cgal_dev/Installation/include \
-isystem /home/efif/trees/cgal/cgal_dev/STL_Extension/include \
-isystem /home/efif/trees/cgal/cgal_dev/Interval_support/include \
-isystem /home/efif/trees/cgal/cgal_dev/Stream_support/include \
-isystem /home/efif/trees/cgal/cgal_dev/Profiling_tools/include \
-isystem /home/efif/trees/cgal/cgal_dev/Cartesian_kernel/include \
-isystem /home/efif/trees/cgal/cgal_dev/Homogeneous_kernel/include \
-isystem /home/efif/trees/cgal/cgal_dev/Arithmetic_kernel/include \
-isystem /home/efif/trees/cgal/cgal_dev/Filtered_kernel/include \
-isystem /home/efif/trees/cgal/cgal_dev/Kernel_23/include \
-isystem /home/efif/trees/cgal/cgal_dev/Number_types/include \
-isystem /home/efif/trees/cgal/cgal_dev/Modular_arithmetic/include \
-isystem /home/efif/trees/cgal/cgal_dev/Algebraic_foundations/include \
-isystem /home/efif/trees/cgal/cgal_dev/Distance_2/include \
-isystem /home/efif/trees/cgal/cgal_dev/Distance_3/include \
-isystem /home/efif/trees/cgal/cgal_dev/Intersections_2/include \
-isystem /home/efif/trees/cgal/cgal_dev/Intersections_3/include \
-isystem /home/efif/trees/cgal/cgal_dev/Arrangement_on_surface_2/include \
-isystem /home/efif/trees/cgal/cgal_dev/Kernel_d/include \
/usr/lib/x86_64-linux-gnu/libgmpxx.a \
/usr/lib/x86_64-linux-gnu/libmpfr.a \
/usr/lib/x86_64-linux-gnu/libgmp.a

[afabri]

How can a change in .github/workflows/build_doc.yml make a difference for a test program?

[efifogel]

1. Many other files changed as well. Do this: git diff --name-only bdba6ee 5072518 2. Now, I've tested it on a different machine, and I get the exact same error with the exact same revisions.

…

____ _ ____ _ /_____/_) o /__________ __ // (____ ( ( ( (_/ (_/-(-'_(/ _/

On Mon, 16 Jan 2023 at 16:46, Andreas Fabri ***@***.***> wrote: How can a change in .github/workflows/build_doc.yml make a difference for a test program? — Reply to this email directly, view it on GitHub <#7192 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVBNOETUF47PFTSQEV6YE3WSVNNPANCNFSM6AAAAAAT4DFR5I> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[GilesBathgate]

@efifogel You seem to be comparing across different branches:

have you tried using git-bisect to narrow down the breaking commit?

[lrineau]

@efifogel

Since #5402, merged in CGAL-5.4, CGAL::Epeck is thread-safe, unless you define the macro CGAL_HAS_NO_THREADS. On Unix, that means that CGAL now requires the pthread library.

• In your CMakeLists, add:

  target_link_libraries(mytest PRIVATE CGAL::CGAL)

  so that the correct flags are added.
• In the standalone command-line that uses g++ directly, add -pthread at the end of the command line.

Unfortunately, with static linking (a configuration that is not officially supported by the CGAL project), you are bitten by another bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590

So, you need to define:

• either CGAL_HAS_NO_THREADS
• or _GLIBCXX_GTHREAD_USE_WEAK to 0.

I have check with the following CMakeLists.txt:

cmake_minimum_required(VERSION 3.16)
project(MYTEST VERSION "1.0.0" LANGUAGES CXX)

set(CMAKE_BUILD_TYPE "Debug")
set(CGAL_DO_NOT_WARN_ABOUT_CMAKE_BUILD_TYPE ON)

set(CMAKE_POSITION_INDEPENDENT_CODE OFF)
set(CMAKE_EXE_LINKER_FLAGS "-D_GLIBCXX_GTHREAD_USE_WEAK=0 -static -static-libgcc -static-libstdc++")
set(CMAKE_CXX_FLAGS "-D_GLIBCXX_GTHREAD_USE_WEAK=0 -static -static-libgcc -static-libstdc++")
set(CMAKE_FIND_LIBRARY_SUFFIXES .a)

find_package(CGAL)
include(${CGAL_USE_FILE})
add_executable(mytest mytest.cpp)
target_link_libraries(mytest PRIVATE CGAL::CGAL)

[efifogel]

No, I haven't. I only know that when I use the earlier commit tit works and when I use the one that follows it doesn't, and it consistently happens, even on two completely different machines ____ _ ____ _ /_____/_) o /__________ __ // (____ ( ( ( (_/ (_/-(-'_(/ _/

…

On Mon, 23 Jan 2023 at 12:05, Giles Bathgate ***@***.***> wrote: @efifogel <https://github.com/efifogel> You seem to be comparing across different branches: [image: image] <https://user-images.githubusercontent.com/444143/214012773-8d19b8b3-ccea-4d0a-ba39-b257356869d8.png> have you tried using git-bisect to narrow down the breaking commit? — Reply to this email directly, view it on GitHub <#7192 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVBNOHRDAXUN7BS7G6LS2TWTZJXJANCNFSM6AAAAAAT4DFR5I> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lrineau]

Note about Git history

More precisely, it fails on commit:
5072518, Thu Jul 29 14:31:10 2021 +0200
but works fine with the one before that, namely:
bdba6ee

The graph of Git commits it not linear: it is a tree. If you sort the commit by commit dates, then 5072518 is just after bdba6ee.

[lrineau@fernand]~/Git/cgal% git log --pretty='%h | %cd | %s' cgal/master
[...]
5072518a3d1 | Thu Jul 29 14:31:10 2021 +0200 | add a force-build command to overwrite a round
bdba6eedfea | Thu Jul 29 14:24:54 2021 +0200 | Fix accidentally calling API-only tests
[...]

But, in the Git tree, the commit just before 5072518 can be designed by the shortcut 5072518^, and that is 8743865.

[lrineau@fernand]~/Git/cgal% git log -n1 '5072518^'
commit 8743865c5258e392b30df5e30dcda96a40c5c0d1
Author: Maxime Gimeno <maxime.gimeno@gmail.com>
Date:   Thu Jul 29 14:03:04 2021 +0200

    add error messages for other exit 1 cases

If you want to see everything that happened between bdba6ee and 5072518, then use the command:

% git log --graph --decorate bdba6ee..5072518

and if you search for #5402, you will see the commit that merged PR #5402.

The answer

In my opinion my answer at comment #7192 (comment) should give you the reasoning about the issue, and a possible workaround.

[efifogel]

I've verified that adding
-DCGAL_HAS_NO_THREADS=1
to the command line fixes the problem
(Adding '-pthread' does not and has no effect.)

BW, statically linking apps is useful!
I had to run my program on some node on which I had limited permissions.
The only alternative was using docker (actually 'udocker', cause I did not have the permission to run docker) and this approach comes with a large cost of overhead in space and maintenance time.