This actually has nothing to do with Cython, sorry I implied that with my debugging above. I actually can’t even import the DLL in pure C++ unless it is in a system path like /usr/local/lib just calling your C++ DLL with my C++. This leads me to ask the question “what is going on in that DLL?” because it’s unusual that this wouldn’t work in the simplest Bazel compilation example. Sorry I led us down the Cython discussion above, but that appears to be unrelated to the issue. The problem is something to do with how you load your DLL at runtime and how that file is located when it is included in a Bazel build. Here’s the simplest example that will compile (may have a typo or two), but will fail at runtime due to “dyld: Library not loaded: libokFrontPanel.dylib … image not found”. Can you share details on how you actually load the DLL? It’s possible this is a Bazel issue but I think that’s unlikely since it was an issue in 2017 and was apparently fixed (https://github.com/bazelbuild/bazel/issues/3450).
// file: third_party/opalkelly/BUILD
cc_library(
name = "okfrontpanel",
srcs = ["libokFrontPanel.dylib"], # or ".so" if on linux
hdrs = ["okFrontPanel.h"],
copts = [
"-DokNO_MANAGER",
# "-DokNO_DELAY_LOAD_FRONTPANEL", # necessary?
],
)
// file: client/BUILD
cc_library(
name = "spi",
srcs = ["Spi.cpp"],
hdrs = ["Spi.h"],
deps = ["//third_party/opalkelly:okfrontpanel"],
)
cc_binary(
name = "main",
srcs = ["main.cpp"],
deps = [":spi"],
)
// file: client/Spi.h
#include "third_party/opalkelly/okFrontPanel.h"
class Spi : {
public:
Spi();
private:
OpalKellyLegacy::okCFrontPanel ok_;
}
// file:: client/Spi.cpp
#include "client/Spi.h"
Spi::Spi {
int device_count = ok_.GetDeviceCount();
}
int main() {
Spi x;
return 0;
}
