jhu-cisst / cisst

JHU ERC CISST Library
http://github.com/jhu-cisst/cisst/wiki
Other
64 stars 47 forks source link

cisstNumerical Build Fails in Latest Release #84

Open DeveloperPaul123 opened 3 years ago

DeveloperPaul123 commented 3 years ago

I'm using the latest release of cisst (1.1.0) and am currently facing build issues when using cisstNetlib with cisstNumerical. I used the CISSTNETLIB_DOWNLOAD_NOW flag via CMake to install cisstNetLib initially.

It seems that this my be relevant. Has cisstNetLib been compiled with a compiler later than VS2015?

Relevant Version info:

Build error output is below.

0>LINK(0,0): Warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
0>cisstNetlib_blas.lib(xerbla.obj)(0,0): Error LNK2019: unresolved external symbol printf referenced in function xerbla_
0>cisstNetlib_f2c.lib(wrtfmt.obj)(0,0): Error LNK2001: unresolved external symbol __imp_fprintf
0>cisstNetlib_f2c.lib(f77_aloc.obj)(0,0): Error LNK2001: unresolved external symbol __imp_fprintf
0>cisstNetlib_f2c.lib(fmt.obj)(0,0): Error LNK2001: unresolved external symbol __imp_fprintf
0>cisstNetlib_f2c.lib(s_stop.obj)(0,0): Error LNK2001: unresolved external symbol __imp_fprintf
0>cisstNetlib_f2c.lib(err.obj)(0,0): Error LNK2001: unresolved external symbol __imp_fprintf
0>cisstNetlib_f2c.lib(sig_die.obj)(0,0): Error LNK2001: unresolved external symbol __imp_fprintf
0>cisstNetlib_f2c.lib(wrtfmt.obj)(0,0): Error LNK2001: unresolved external symbol __imp___iob_func
0>cisstNetlib_f2c.lib(f77_aloc.obj)(0,0): Error LNK2001: unresolved external symbol __imp___iob_func
0>cisstNetlib_f2c.lib(fmt.obj)(0,0): Error LNK2001: unresolved external symbol __imp___iob_func
0>cisstNetlib_f2c.lib(s_stop.obj)(0,0): Error LNK2001: unresolved external symbol __imp___iob_func
0>cisstNetlib_f2c.lib(err.obj)(0,0): Error LNK2001: unresolved external symbol __imp___iob_func
0>cisstNetlib_f2c.lib(sig_die.obj)(0,0): Error LNK2001: unresolved external symbol __imp___iob_func
0>cisstNetlib_f2c.lib(open.obj)(0,0): Error LNK2019: unresolved external symbol __imp_sprintf referenced in function f_open
0>cisstNetlib_f2c.lib(wref.obj)(0,0): Error LNK2001: unresolved external symbol __imp_sprintf
0>cisstNetlib_f2c.lib(endfile.obj)(0,0): Error LNK2001: unresolved external symbol __imp_sprintf
0>D:\Tools\cisst-1.1.0\build\lib\Debug\cisstNumerical.dll(0,0): Error LNK1120 fatal: 4 unresolved externals
0>------- Finished building project: cisstNumerical. Succeeded: False. Errors: 17. Warnings: 1
pkazanzides commented 3 years ago

I am using it with VS 2017, but I did not select the "Download Now" CMake option. I instead downloaded it separately (the source is also on GitHub/jhu-cisst) and built it from source using VS2017. Then, in cisst I used the CISSTNETLIB_USE_LOCAL_INSTALL CMake option.

DeveloperPaul123 commented 3 years ago

Thanks @pkazanzides I was able to get it to work by building cisstNetLib myself.

pkazanzides commented 3 years ago

There may also be an "external projects" option for building cisstNumerical within cisst. I'll leave it for @adeguet1 to answer.

adeguet1 commented 3 years ago

We haven't implemented an "external project" way to build cisstNetlib. I'm not a big fan of CMake external projects so I tend to avoid them if a better "packaging" system exists (e.g. ROS/catkin) but I see the appeal for Mac OS or Windows. If I can implement the build using CMake external project, any objection to also remove the "download cisstNetlib now" option since it's a bit challenging to keep up with binary distributions.

pkazanzides commented 3 years ago

No objection from me.

DeveloperPaul123 commented 3 years ago

We haven't implemented an "external project" way to build cisstNetlib. I'm not a big fan of CMake external projects so I tend to avoid them if a better "packaging" system exists (e.g. ROS/catkin) but I see the appeal for Mac OS or Windows. If I can implement the build using CMake external project, any objection to also remove the "download cisstNetlib now" option since it's a bit challenging to keep up with binary distributions.

I have no objection to using CMake's external project. I've also had good success with CPM.cmake.

If you do go the external project route, would you still have the CISST_HAS_NETLIB option? I guess you would want CISST_USE_EXTERNAL and CISST_HAS_NETLIB to be enabled to build it this way?