You are not logged in.
Hello everyone,
I want to compile a project from source and it seems that I need to install an older version of GCC to do so (GCC 14, as it seems). I am puzzled before the difficulty I encounter : I passed 2 days compiling the AUR packages gcc12, gcc13, and gcc14, with or without clean chroot, and with and without yay, without success (I obtain errors that I don't manage to put clear since this building is very verbose).
My question is : Why is there only gcc15 and gcc16 in Core and Extra ? In my opinion, it would be convenient to install older versions from those sources, especially when the AUR versions mentioned in the wiki have to be compiled from source, which may conduct to the difficulties I mentioned (and they seem common, as can be read in the comments under the AUR pages of the versions 12, 13 and 14).
As a second question : does somebody can advice me in order to install older versions of gcc in ArchLinux without having to compile it ? I considered using apt but did not find official Arch documentation and it seems to be a bad idea. I tried to install a deb file with dpkg but it has dependencies, and again it seems to be a bad idea. Unofficial user repositories seems to be a possibility, but I don't know where to start nor if it is secure.
Thank you very much for your attention and your help !
Last edited by anthony_g-r (2026-06-25 18:55:10)
Offline
gcc15 is still a dependency for eg. notably https://archlinux.org/packages/extra/x86_64/cuda/ - gcc14 isn't required by other packages.
Before it was dropped into the AUR there were https://archive.archlinux.org/packages/g/gcc14/
Given the last version is only 6½ months old it might still work.
Offline
gcc is part of the gnu toolchain and needs to cooperate closely with other parts like binutils and glibc .
Arch devs usually update all 3 together ...
Getting older gcc versions to work with latest binutils and glibc is hard and often near-impossible .
The only reason older versions of gcc (also applies to llvm/clang) are sometimes kept in repos is because other repo applications don't build with latest version.
both dotnet and cuda are notorious for lagging behind with supporting latest versions.
In case you need an older version of gcc, the best approach is to try to get it to build with latest released version.
Newer gcc versions often promote warnings to errors, but that can typically be workedaround.
Also upstream may already have a fix to build with newer versions that can be used to patch the sourcecode.
There are a few other options but they are not alwaus usable.
Is the project you want to compile published somewhere ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
gcc15 is still a dependency for eg. notably https://archlinux.org/packages/extra/x86_64/cuda/ - gcc14 isn't required by other packages.
Before it was dropped into the AUR there were https://archive.archlinux.org/packages/g/gcc14/
Given the last version is only 6½ months old it might still work.
Thank you for your answer, but unless I miss some point, gcc14 may be useful by itself. The exchange with Lone_Wolf might lead to something I just did not understand.
Offline
gcc is part of the gnu toolchain and needs to cooperate closely with other parts like binutils and glibc .
Arch devs usually update all 3 together ...Getting older gcc versions to work with latest binutils and glibc is hard and often near-impossible .
The only reason older versions of gcc (also applies to llvm/clang) are sometimes kept in repos is because other repo applications don't build with latest version.
both dotnet and cuda are notorious for lagging behind with supporting latest versions.In case you need an older version of gcc, the best approach is to try to get it to build with latest released version.
Newer gcc versions often promote warnings to errors, but that can typically be workedaround.Also upstream may already have a fix to build with newer versions that can be used to patch the sourcecode.
There are a few other options but they are not alwaus usable.
Is the project you want to compile published somewhere ?
Thank you very much for your answer. Do you mean that I may find a way to compile my source with the latest version of gcc with some trick ? The project I am interested in is AzerothCore, and gcc14 is in the Requirements. As I mentioned, it did not compile with gcc 16, and I think I know why : it seems that a function, which is used somewhere, was removed from newest versions of libstdc++. I could tell you more, but it is not an Arch-related problem so I won't unless you ask
.
A fix will be published indeed, but I don't know when
And I wanted to try to investigate this project know :B
Offline
There already is an out of date PKGBUILD for azerothcore. Please do post the compilation failure with the current gcc or clang.
Offline
There already is an out of date PKGBUILD for azerothcore. Please do post the compilation failure with the current gcc or clang.
For sure ! I follow the Instructions of the official wiki, the clang compiler being replaced by gcc (and g++). CMake does its job, then I run make and obtain this error :
error: ‘__throw_bad_alloc’ is not a member of ‘std’; did you mean ‘__throw_bad_cast’?
70 | std::__throw_bad_alloc();
| ^~~~~~~~~~~~~~~~~
| __throw_bad_cast
make[2]: *** [deps/jemalloc/CMakeFiles/jemalloc.dir/build.make:275: deps/jemalloc/CMakeFiles/jemalloc.dir/src/jemalloc_cpp.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....There is a related pull mentioned by a member of the AzerothCore Discord, which makes the problem clear in my view.
Of course, I tried clang too, with the same result (it use the same libstd as I understood).
Offline
loqs wrote:There already is an out of date PKGBUILD for azerothcore. Please do post the compilation failure with the current gcc or clang.
For sure ! I follow the Instructions of the official wiki, the clang compiler being replaced by gcc (and g++). CMake does its job, then I run make and obtain this error :
error: ‘__throw_bad_alloc’ is not a member of ‘std’; did you mean ‘__throw_bad_cast’? 70 | std::__throw_bad_alloc(); | ^~~~~~~~~~~~~~~~~ | __throw_bad_cast make[2]: *** [deps/jemalloc/CMakeFiles/jemalloc.dir/build.make:275: deps/jemalloc/CMakeFiles/jemalloc.dir/src/jemalloc_cpp.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs....There is a related pull mentioned by a member of the AzerothCore Discord, which makes the problem clear in my view.
Of course, I tried clang too, with the same result (it use the same libstd as I understood).
It appears either https://github.com/azerothcore/azerothc … pull/25913 or https://github.com/jemalloc/jemalloc/co … 17a47da3ea will address the issue.
Offline
anthony_g-r wrote:loqs wrote:There already is an out of date PKGBUILD for azerothcore. Please do post the compilation failure with the current gcc or clang.
For sure ! I follow the Instructions of the official wiki, the clang compiler being replaced by gcc (and g++). CMake does its job, then I run make and obtain this error :
error: ‘__throw_bad_alloc’ is not a member of ‘std’; did you mean ‘__throw_bad_cast’? 70 | std::__throw_bad_alloc(); | ^~~~~~~~~~~~~~~~~ | __throw_bad_cast make[2]: *** [deps/jemalloc/CMakeFiles/jemalloc.dir/build.make:275: deps/jemalloc/CMakeFiles/jemalloc.dir/src/jemalloc_cpp.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs....There is a related pull mentioned by a member of the AzerothCore Discord, which makes the problem clear in my view.
Of course, I tried clang too, with the same result (it use the same libstd as I understood).
It appears either https://github.com/azerothcore/azerothc … pull/25913 or https://github.com/jemalloc/jemalloc/co … 17a47da3ea will address the issue.
Thank you for the links, good to see that the problem is adressed. I guess the wiser act is to wait...
Anyway, does somebody see a way to compile it with the current version of gcc ? Like linking to an old std lib ?
Offline
Apply the following against current git HEAD:
diff --git a/deps/jemalloc/include/jemalloc/internal/safety_check.h b/deps/jemalloc/include/jemalloc/internal/safety_check.h
index 53339ac12f..ec4b33699b 100644
--- a/deps/jemalloc/include/jemalloc/internal/safety_check.h
+++ b/deps/jemalloc/include/jemalloc/internal/safety_check.h
@@ -3,7 +3,7 @@
void safety_check_fail(const char *format, ...);
/* Can set to NULL for a default. */
-void safety_check_set_abort(void (*abort_fn)());
+void safety_check_set_abort(void (*abort_fn)(const char *));
JEMALLOC_ALWAYS_INLINE void
safety_check_set_redzone(void *ptr, size_t usize, size_t bumped_usize) {
diff --git a/deps/jemalloc/jemalloc_internal_defs.h.in.cmake b/deps/jemalloc/jemalloc_internal_defs.h.in.cmake
index 28f7e9386f..a07ac0b054 100644
--- a/deps/jemalloc/jemalloc_internal_defs.h.in.cmake
+++ b/deps/jemalloc/jemalloc_internal_defs.h.in.cmake
@@ -367,4 +367,7 @@
/* sizeof(void *) == 2^LG_SIZEOF_PTR. */
#define LG_SIZEOF_PTR @JEM_SIZEDEF@
+/* Are C++ exceptions enabled? */
+#define JEMALLOC_HAVE_CXX_EXCEPTIONS
+
#endif /* JEMALLOC_INTERNAL_DEFS_H_ */
diff --git a/deps/jemalloc/src/jemalloc_cpp.cpp b/deps/jemalloc/src/jemalloc_cpp.cpp
index da0441a7c9..2caaf7c6e2 100644
--- a/deps/jemalloc/src/jemalloc_cpp.cpp
+++ b/deps/jemalloc/src/jemalloc_cpp.cpp
@@ -1,4 +1,4 @@
-#include <mutex>
+#include <exception>
#include <new>
#define JEMALLOC_CPP_CPP_
@@ -45,29 +45,30 @@ handleOOM(std::size_t size, bool nothrow) {
void *ptr = nullptr;
while (ptr == nullptr) {
- std::new_handler handler;
- // GCC-4.8 and clang 4.0 do not have std::get_new_handler.
- {
- static std::mutex mtx;
- std::lock_guard<std::mutex> lock(mtx);
-
- handler = std::set_new_handler(nullptr);
- std::set_new_handler(handler);
- }
+ std::new_handler handler = std::get_new_handler();
if (handler == nullptr)
break;
+#ifdef JEMALLOC_HAVE_CXX_EXCEPTIONS
try {
handler();
} catch (const std::bad_alloc &) {
break;
}
+#else
+ handler();
+#endif
ptr = je_malloc(size);
}
- if (ptr == nullptr && !nothrow)
- std::__throw_bad_alloc();
+ if (ptr == nullptr && !nothrow) {
+#ifdef JEMALLOC_HAVE_CXX_EXCEPTIONS
+ throw std::bad_alloc();
+#else
+ std::terminate();
+#endif
+ }
return ptr;
}
That should address the jemalloc issues it includes the relevant changes from the commit I linked before plus the relevant change from https://github.com/jemalloc/jemalloc/co … 34f067e5e4 for a missing argument.
Offline
Apply the following against current git HEAD:
diff --git a/deps/jemalloc/include/jemalloc/internal/safety_check.h b/deps/jemalloc/include/jemalloc/internal/safety_check.h index 53339ac12f..ec4b33699b 100644 --- a/deps/jemalloc/include/jemalloc/internal/safety_check.h +++ b/deps/jemalloc/include/jemalloc/internal/safety_check.h @@ -3,7 +3,7 @@ void safety_check_fail(const char *format, ...); /* Can set to NULL for a default. */ -void safety_check_set_abort(void (*abort_fn)()); +void safety_check_set_abort(void (*abort_fn)(const char *)); JEMALLOC_ALWAYS_INLINE void safety_check_set_redzone(void *ptr, size_t usize, size_t bumped_usize) { diff --git a/deps/jemalloc/jemalloc_internal_defs.h.in.cmake b/deps/jemalloc/jemalloc_internal_defs.h.in.cmake index 28f7e9386f..a07ac0b054 100644 --- a/deps/jemalloc/jemalloc_internal_defs.h.in.cmake +++ b/deps/jemalloc/jemalloc_internal_defs.h.in.cmake @@ -367,4 +367,7 @@ /* sizeof(void *) == 2^LG_SIZEOF_PTR. */ #define LG_SIZEOF_PTR @JEM_SIZEDEF@ +/* Are C++ exceptions enabled? */ +#define JEMALLOC_HAVE_CXX_EXCEPTIONS + #endif /* JEMALLOC_INTERNAL_DEFS_H_ */ diff --git a/deps/jemalloc/src/jemalloc_cpp.cpp b/deps/jemalloc/src/jemalloc_cpp.cpp index da0441a7c9..2caaf7c6e2 100644 --- a/deps/jemalloc/src/jemalloc_cpp.cpp +++ b/deps/jemalloc/src/jemalloc_cpp.cpp @@ -1,4 +1,4 @@ -#include <mutex> +#include <exception> #include <new> #define JEMALLOC_CPP_CPP_ @@ -45,29 +45,30 @@ handleOOM(std::size_t size, bool nothrow) { void *ptr = nullptr; while (ptr == nullptr) { - std::new_handler handler; - // GCC-4.8 and clang 4.0 do not have std::get_new_handler. - { - static std::mutex mtx; - std::lock_guard<std::mutex> lock(mtx); - - handler = std::set_new_handler(nullptr); - std::set_new_handler(handler); - } + std::new_handler handler = std::get_new_handler(); if (handler == nullptr) break; +#ifdef JEMALLOC_HAVE_CXX_EXCEPTIONS try { handler(); } catch (const std::bad_alloc &) { break; } +#else + handler(); +#endif ptr = je_malloc(size); } - if (ptr == nullptr && !nothrow) - std::__throw_bad_alloc(); + if (ptr == nullptr && !nothrow) { +#ifdef JEMALLOC_HAVE_CXX_EXCEPTIONS + throw std::bad_alloc(); +#else + std::terminate(); +#endif + } return ptr; }That should address the jemalloc issues it includes the relevant changes from the commit I linked before plus the relevant change from https://github.com/jemalloc/jemalloc/co … 34f067e5e4 for a missing argument.
Okay, I applied the whole pull request on azerothcore and it compiled ! Thank you very much, I will mark the subject as solved (EDIT : Sorry but I did not find how to edit the title...) !
Best
Last edited by anthony_g-r (2026-06-22 05:59:01)
Offline
(EDIT : Sorry but I did not find how to edit the title...) !
Just use the `Edit` button on your original post and add `[Solved]` to the title.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline