Open raycoe opened 1 year ago
I attempted to rebuild the cxx project within MSVC and get the same errors.
With this project, it looks like that at some stage, cxx-build is building a cxxbridge1.lib that calls functions that cannot be resolved and then produce LNK2019 errors.
Something looks to be missing in the libraries that are generated by cxx-build, it can be in the LIBPATH or some libraries themselves, at least in the Windows environment but can't figure out which ones.
The most amazing when looking for symbol refs on the cxx-generated lib file after having tried many options with cargo-test:
00000000 T cxxbridge1$new_libzos_handler`
00000730 T cxxbridge1$unique_ptr$LibZosHandler$drop`
000006f0 T cxxbridge1$unique_ptr$LibZosHandler$get`
00000640 T cxxbridge1$unique_ptr$LibZosHandler$null`
00000690 T cxxbridge1$unique_ptr$LibZosHandler$raw`
00000710 T cxxbridge1$unique_ptr$LibZosHandler$release`
...
Which is indicating that symbols are defined...
Hi @raycoe,
Did you get a chance to solve the issue on Windows?
I'm facing exactly the same problem with a cross-platform c++ static library, I think cxx is not really meant to work with Windows but nix platforms only...
I don't have Windows, but the problem may be in the whole-archive handling. The compilation warns you that the option is unsupported/unknown. Simply put, the symbols are optimized out if not directly used, unless you force compiling in the whole archive (i.e., the whole static lib). But I may be mistaken.
I'm doubting that LNK1120 fatal errors are due to the warn LNK4044 since the last is simply ignored anyway by CL. But I could give it a try if there is any possibility to manipulate /WHOLEARCHIVE option that is apparently forced by cxx.
Could you perhaps try deleting or renaming the lib.rs file? That might help!
Could you perhaps try deleting or renaming the lib.rs file? That might help!
it's worked!
I'm also on Windows, and trying to get a basic "hello-world" working, and I ran into this issue too. Removing my empty lib.rs solved the problem (thank you @whynothackme )
But it's not clear to me if using lib.rs is a limitation, or if some additional care/configuration is needed when using cxx with a rust library.
I don't know how above suggested solution could work since, except if I missed something, rust requires either a main.rs if app or a lib.rs if lib.
Now that I upgraded to 1.74 cargo environment, it no longer working on MacOS (13.6) either!
Hello @dtolnay,
I'm struggling with this linking problem for days.
To explain a bit the context, I have to use a no-access-to-source cross platform dynamic library we are using for years in C++11. In order to achieve this, I created a simple wrapper class in C++ that aims to be the interop (C++ side) between Rust code and this shared lib.
The code is intended to run on MacOS, Linux and Windows. On MacOS and Linux, I have no issue, all the unit-tests are perfectly running; it is only on Windows that I'm facing unresolved external symbol issues for all exposed methods.
On Windows:
When launching unit-tests:
An this is the build.rs content:
I'm looking for help, so many thanks in advance if someone could tell me what I'm missing.