!lheuhImcToQZYTQTuI:nixos.org

Nix on macOS

1081 Members
“There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org164 Servers

Load older messages


SenderMessageTime
4 Jul 2025
@megmug:matrix.orgmegmugI can definitely provide that if its of any use08:15:15
@weethet:catgirl.cloudWeetHetI'm not gonna debug C++ linking for you08:15:34
@megmug:matrix.orgmegmugMeaning, it is not possible to "fix" or circumvent using the nix shell?08:15:48
@weethet:catgirl.cloudWeetHetIt's not a nix issue08:15:55
@weethet:catgirl.cloudWeetHetIt's an issue with how your project is built08:16:10
@weethet:catgirl.cloudWeetHetOr written idk08:16:14
@megmug:matrix.orgmegmugunderstandable08:16:23
@weethet:catgirl.cloudWeetHetIt just so happens to work out on linux08:16:25
@weethet:catgirl.cloudWeetHetThat's my best guess08:17:40
@megmug:matrix.orgmegmugOkay, thank you for having a look at it08:18:10
@weethet:catgirl.cloudWeetHet You can go over the .o files using nm and look for the mangled REPLDriver<CloudClient>::add_action 08:18:34
@k900:0upti.meK900My guess would be that it's instantiated in a .cpp file instead of a header08:19:17
@k900:0upti.meK900So it's not linked correctly08:19:22
@weethet:catgirl.cloudWeetHetYep, probably that08:19:34
@k900:0upti.meK900And Clang is just stricter about this than GCC08:19:47
@megmug:matrix.orgmegmugYeah, we have a header and a corresponding .cxx file that implements it08:20:04
@megmug:matrix.orgmegmugI 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 compatible08:22:10
@k900:0upti.meK900GCC on OSX is not really a good idea AFAIK08:22:57
@k900:0upti.meK900Though I'm far from an OSX expert08:23:02
@k900:0upti.meK900You might want to try building with clang on Linux actually08:23:19
@k900:0upti.meK900Just to see if the issue reproduces08:23:24
@megmug:matrix.orgmegmugthis i should try yes08:24:05
@weethet:catgirl.cloudWeetHet

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:catgirl.cloudWeetHetRight?08:24:40
@weethet:catgirl.cloudWeetHet *

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:catgirl.cloudWeetHetWell, building it fails08:25:02
@weethet:catgirl.cloudWeetHet
$ 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:catgirl.cloudWeetHetI'm 99% sure you have the same issue08:25:47
@megmug:matrix.orgmegmugOk, but why does it work so flawlessly on x86 linux then?08:26:54
@weethet:catgirl.cloudWeetHetIdk C++ stuff08:27:06

Show newer messages


Back to Room ListRoom Version: 6