Bug 273398 - lang/gcc13: statically linking a program with -pthread aborts
Summary: lang/gcc13: statically linking a program with -pthread aborts
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Lorenzo Salvadore
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-28 11:43 UTC by Steffen
Modified: 2023-10-01 21:25 UTC (History)
2 users (show)

See Also:


Attachments
Backtrace of `gcc -static -g3 -pthread main.cpp` (1.15 KB, text/plain)
2023-08-28 12:11 UTC, Steffen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steffen 2023-08-28 11:43:20 UTC
I have created a simple program using two C++ threads:
```
#include <iostream>
#include <mutex>
#include <thread>

int num = 0;
std::mutex mut{};

void func() {
	for (int i = 0; i < 10000; ++i) {
		std::lock_guard lock(mut)
		++num;
	}
}

int main() {
	std::thread thread1 = std::thread(func);
	std::thread thread2 = std::thread(func);

	thread2.join();
	thread1.join();

	printf("%d\n", num);

	return 0;
}
```

Compiling this with `g++13 -static -O3 -pthread main.cpp` and running `./a.out` generates a core dump: 
```
zsh: abort (core dumped)  ./a.out
```

I've tried linking with `-lthr` and `-static-libstdc++` and `-static-libgcc` but those should be implied by `g++ -static` anyways.

I'm working on a project where this issue occures aswell when using the pthread.h header instead of C++ threads.

Clang's static and dynammic output works as expected as well as gcc's dynamic executable.
Comment 1 Steffen 2023-08-28 12:11:08 UTC
Created attachment 244418 [details]
Backtrace of `gcc -static -g3 -pthread main.cpp`
Comment 2 Lorenzo Salvadore freebsd_committer freebsd_triage 2023-09-28 16:05:17 UTC
I should probably deal with this bug since I am now the maintainer of all the GCC ports for supported versions.

Gerald: would you like me to assign this bug to myself? Please mind that I cannot deal with it right now: as you know, I am already busy with a lot of things, GCC default version update included, but I can get to it when the update is finished.

Moreover, would it make more sense if I took maintainership of lang/gcc? Or would you like to keep it?
Comment 3 Gerald Pfeifer freebsd_committer freebsd_triage 2023-09-28 22:27:12 UTC
Yes, agreed, this is actually an issue for the specific lang/gcc* ports,
not lang/gcc as such.

(In terms of maintainership I'm happy to keep lang/gcc.)