| 4 Jul 2025 |
 K900 | And Clang is just stricter about this than GCC | 08:19:47 |
 megmug | Yeah, we have a header and a corresponding .cxx file that implements it | 08:20:04 |
| megmug | I tried switching it to gcc on MacOS via the CC and CXX env variables but that made things even worse. To my current understanding, because everything else is built with clang and the resulting binaries will not be compatible | 08:22:10 |
| K900 | GCC on OSX is not really a good idea AFAIK | 08:22:57 |
| K900 | Though I'm far from an OSX expert | 08:23:02 |
| K900 | You might want to try building with clang on Linux actually | 08:23:19 |
| K900 | Just to see if the issue reproduces | 08:23:24 |
| megmug | this i should try yes | 08:24:05 |
 WeetHet | Imagine that you have
header.h:
#ifndef HEADER_H
#define HEADER_H
template <typename T> class Test {
T x;
public:
static Test mkTest(T x);
};
#endif
impl.cpp:
#include "header.h"
template <typename T> Test<T> Test<T>::mkTest(T x) { return Test{x}; }
main.cpp:
#include "header.h"
int main() { Test<int> t = Test<int>::mkTest(3); }
| 08:24:34 |
| WeetHet | Right? | 08:24:40 |
| WeetHet | * Imagine that you have
header.h:
#ifndef HEADER_H
#define HEADER_H
template <typename T> class Test {
T x;
public:
static Test mkTest(T x);
};
#endif
impl.cpp:
#include "header.h"
template <typename T> Test<T> Test<T>::mkTest(T x) { return Test{x}; }
main.cpp:
#include "header.h"
int main() { Test<int> t = Test<int>::mkTest(3); }
| 08:24:47 |
| WeetHet | Well, building it fails | 08:25:02 |
| WeetHet | $ g++ main.cpp impl.cpp -o main
Undefined symbols for architecture arm64:
"Test<int>::mkTest(int)", referenced from:
_main in main-880b44.o
ld: symbol(s) not found for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
| 08:25:17 |
| WeetHet | I'm 99% sure you have the same issue | 08:25:47 |
| megmug | Ok, but why does it work so flawlessly on x86 linux then? | 08:26:54 |
| WeetHet | Idk C++ stuff | 08:27:06 |
| WeetHet | Luck | 08:27:08 |
| megmug | (or, gcc) | 08:27:13 |
| megmug | NVM, you were compiling with gcc | 08:27:25 |
| megmug | No, you weren't. | 08:27:39 |
| WeetHet | It's macOS "gcc" | 08:27:43 |
| WeetHet | $ g++ --version
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
| 08:28:03 |
| megmug | Aha | 08:28:22 |
| megmug | You were spot on. The build fails using clang on Linux x86, too. | 08:37:38 |
| K900 | I assume you'll just have to fix the library then | 08:39:41 |
| megmug | Hm, is it possible to switch the MacOS build to gcc instead? Even if it takes forever to compile everything from scratch? | 08:41:31 |
| megmug | I guess the last time i tried i did it wrong because the macos build failed with a ton of linker errors, but thats understandable since it tried to use precompiled by gcc libraries | 08:43:17 |
| WeetHet | Why would you want to build wrong code | 08:46:34 |
| WeetHet | That's absolutely not the right way to do things | 08:46:52 |
| WeetHet | What if gcc changes it linking behaviour in the next release | 08:47:32 |
