Compile error on Windows with vs2022 and vs2019 when compiling against osqp master branch (future osqp v1)

[YongcanZhou]

install with osqp(master) and osqp-eigen(master)
but when "make" step, we meet this error

It seems the problem is here three lines of code
https://github.com/robotology/osqp-eigen/blob/a752c5e6353cae6176578488a1fa641d3b9cf0b9/include/OsqpEigen/Compat.hpp#L21C1-L21C1

csc_spalloc and csc_spfree with error LNK2019: unresolved external symbol

H:\Project\QP\osqp-eigen-master\out\build\x64-Debug\Data.cpp.obj : error LNK2019: unresolved external symbol csc_spfree，function "public: void __cdecl OsqpEigen::Data::clearHessianMatrix(void)" (?clearHessianMatrix@Data@OsqpEigen@@QEAAXXZ)
H:\Project\QP\osqp-eigen-master\out\build\x64-Debug\Solver.cpp.obj : error LNK2019: unresolved external symbol csc_spalloc，"bool __cdecl OsqpEigen::SparseMatrixHelper::createOsqpSparseMatrix<class Eigen::SparseMatrix<double,0,int> >(class Eigen::SparseCompressedBase<class Eigen::SparseMatrix<double,0,int> > const &,struct OSQPCscMatrix * &)" (??$createOsqpSparseMatrix@V?$SparseMatrix@N$0A@H@Eigen@@@SparseMatrixHelper@OsqpEigen@@YA_NAEBV?$SparseCompressedBase@V?$SparseMatrix@N$0A@H@Eigen@@@eigen@@AEAPEAUOSQPCscMatrix@@@z)
H:\Project\QP\osqp-eigen-master\out\build\x64-Debug\bin\OsqpEigend.dll : fatal error LNK1120: 2 个unresolved external symbol
ninja: build stopped: subcommand failed.

[traversaro]

Thanks for reporting the problem! The code for compatibility with osqp v1 (i.e. osqp master) is quite new (it was added in #145), hopefully we are able to solve this problem before the osqp v1 first official release. In the meantime, a workaround is either to use osqp v0.6.3 or (but this is just a guess) compile osqp and osqp-eigen as static libraries.

[traversaro]

fyi @gergondet

[traversaro]

Note that a possible solution is just to include a local copy of the csc_spalloc function (this would help also for #142, fyi @Levi-Armstrong).

Probably it is als a good idea to ask upstream how an OSQP sparse matrix is supposed to be created, if csc_spalloc is now private. From https://github.com/osqp/osqp/blob/1ac3fab74ddeebb0a24b8b7f96e1e539423d4a6a/docs/examples/update-vectors.rst#L198, it seems that the idea is to use the csc_set_data function.

[GLIMMER9911]

Thanks for reporting the problem! The code for compatibility with osqp v1 (i.e. osqp master) is quite new (it was added in #145), hopefully we are able to solve this problem before the osqp v1 first official release. In the meantime, a workaround is either to use osqp v0.6.3 or (but this is just a guess) compile osqp and osqp-eigen as static libraries.

Thank you very much for your response! I followed your instructions to use osqp v0.6.3. However, unfortunately, I encountered the same issue as you did before when installing v0.6.3. I'm not sure how to resolve this problem.

Failed with: ninja: error: build.ninja:320: multiple rules generate out/osqp.lib

If you could help me with this question, I would be extremely grateful.

[traversaro]

Thanks for reporting the problem! The code for compatibility with osqp v1 (i.e. osqp master) is quite new (it was added in #145), hopefully we are able to solve this problem before the osqp v1 first official release. In the meantime, a workaround is either to use osqp v0.6.3 or (but this is just a guess) compile osqp and osqp-eigen as static libraries.

Thank you very much for your response! I followed your instructions to use osqp v0.6.3. However, unfortunately, I encountered the same issue as you did before when installing v0.6.3. I'm not sure how to resolve this problem.

Failed with: ninja: error: build.ninja:320: multiple rules generate out/osqp.lib

If you could help me with this question, I would be extremely grateful.

See osqp/osqp#309 for a related issue. A simple workaround is to use another CMake generator, like NMake Makefiles or Visual Studio 16 2019/Visual Studio 17 2022

[gergondet]

Sorry about that. I went with the simplest solution I could think of at the time and since the symbol is available on Linux even when the API is hidden but that's definitely not a clean solution and it breaks on Windows since the symbol is not available.

it seems that the idea is to use the csc_set_data function.

I think this leaves you responsible for allocating the p/i/x data so probably something like csc_spalloc is still needed inside osqp-eigen, if that's ok license-wise maybe just copying and renaming (to avoid symbol collisions) the internal function is ok?

[traversaro]

Sorry about that.

No problem!

if that's ok license-wise maybe just copying and renaming (to avoid symbol collisions) the internal function is ok?

I did not tought of the license, indeed having just a chunk of Apache-2.0 code in a BSD license is not ideal, even if doable. Let's open an issue upstream to discuss this with osqp mantainers.

[traversaro]

I renamed this issue to clarify what is tracking.