search

conda-forge / gsl-feedstock

A conda-smithy repository for gsl.
BSD 3-Clause "New" or "Revised" License
6 stars 18 forks source link

Windows: link error for gsl_rng_* constants #15

Closed jeromekelleher closed 7 years ago

jeromekelleher commented 7 years ago

I get the following error when compiling a Python module against GSL on windows:

: error LNK2001: unresolved external symbol gsl_rng_default
build\lib.win-amd64-3.5\_msprime.cp35-win_amd64.pyd : fatal error LNK1120: 1 unresolved externals

This comes from the line

self->rng = gsl_rng_alloc(gsl_rng_default);

in my code. If I comment this line out, the compilation works fine (in particular, there doesn't seem to be any issues with linking against other GSL functions). This seems to be an issue with all the constants defined in rng/gsl_rng.h.

@shadowwalkersb --- I think you hit a bunch of these 'unresolved externals' issues when doing the initial PR. How did you fix them?

shadowwalkersb commented 7 years ago

You may need to compile with GSL_DLL macro set.

shadowwalkersb commented 7 years ago

See, also http://stackoverflow.com/questions/16742405/gsl-rng-default-unresolved-external-error.

jeromekelleher commented 7 years ago

Thanks for your help @shadowwalkersb, this does seem to be the same problem. However, setting the GSL_DLL (-DGSL_DLL) macro doesn't seem to make any difference for me. In case this is important, I'm compiling a Python extension module, and have used the define_macros option in setup.py. It seems to be adding the required value to the compiler command lines.

I'm not sure what effect setting this macro could have though. I searched through anaconda\Library\include\gsl and there is no mention of GSL_DLL in there...

shadowwalkersb commented 7 years ago

I am not familiar with extension compilations. Is there a linking step after the compilation? The macro, probably, needs to be defined for linking, too. The symbols should be resolved during linking. I would, also, make sure that you are linking against gsl library. I had the exact same error in a project. The error was gone after adding add_definitions(-DGSL_DLL) to the project's CMakeLists.txt.

jeromekelleher commented 7 years ago

There is a compile step and a linking step. I've tried adding -DGSL_DLL to the both steps, but the compiler emits a warning saying it's ignored for the linking step. I've pasted a full dump of my compile here, if this is of any use. This is one of the compile commands:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -DH5_NO_DEPRECATED_SYMBOLS -DMSP_LIBRARY_VERSION_STR=\"0.4.1.dev244+ng73f46b2.d20170222\" -DGSL_DLL -UNDEBUG [lots more stuff]

This is the link command that fails:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:C:\jk-work\anaconda\Library\lib /LIBPATH:C:\jk-work\anaconda\libs /LIBPATH:C:\jk-work\anaconda\PCbuild\amd64 "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64" "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB\amd64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\ucrt\x64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\um\x64" "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB" "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\ucrt\x86" "/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x86" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\um\x86" gsl.lib gslcblas.lib hdf5.lib /EXPORT:PyInit__msprime build\temp.win-amd64-3.5\Release\_msprimemodule.obj build\temp.win-amd64-3.5\Release\lib/msprime.obj build\temp.win-amd64-3.5\Release\lib/fenwick.obj build\temp.win-amd64-3.5\Release\lib/avl.obj build\temp.win-amd64-3.5\Release\lib/tree_sequence.obj build\temp.win-amd64-3.5\Release\lib/object_heap.obj build\temp.win-amd64-3.5\Release\lib/newick.obj build\temp.win-amd64-3.5\Release\lib/hapgen.obj build\temp.win-amd64-3.5\Release\lib/recomb_map.obj build\temp.win-amd64-3.5\Release\lib/mutgen.obj build\temp.win-amd64-3.5\Release\lib/vargen.obj build\temp.win-amd64-3.5\Release\lib/vcf.obj build\temp.win-amd64-3.5\Release\lib/ld.obj build\temp.win-amd64-3.5\Release\lib/table.obj /OUT:build\lib.win-amd64-3.5\_msprime.cp35-win_amd64.pyd /IMPLIB:build\temp.win-amd64-3.5\Release\_msprime.cp35-win_amd64.lib -DGSL_DLL
LINK : warning LNK4044: unrecognized option '/DGSL_DLL'; ignored
   Creating library build\temp.win-amd64-3.5\Release\_msprime.cp35-win_amd64.lib and object build\temp.win-amd64-3.5\Release\_msprime.cp35-win_amd64.exp
_msprimemodule.obj : error LNK2001: unresolved external symbol gsl_rng_default
build\lib.win-amd64-3.5\_msprime.cp35-win_amd64.pyd : fatal error LNK1120: 1 unresolved externals

Note the "unrecognized option '/DGSL_DLL'; ignored" bit here.

It's hard to know what CMake is doing differently here. Would you mind taking a quick look at your compile logs and seeing where CMake added the GSL_DLLs? Thanks for your help.

shadowwalkersb commented 7 years ago

I don't have the logs with cmake debug output enabled. I'd have to run locally or submit a new build with cmake debug output enabled. Can't promise to do anything soon. Any chance you can build on Appveyor? In the meantime, maybe someone from conda-forge can offer help? @ocefpaf ?

jeromekelleher commented 7 years ago

Thanks for your help @shadowwalkersb, it's much appreciated. I'll try this on AppVeyor over the next few days and see if it makes any difference. Any ideas from anyone else would also be much appreciated!

ocefpaf commented 7 years ago

I am away for a few weeks (moving to another city) I'll take a look once I'm settled.

On Feb 22, 2017 4:39 PM, "shadow_walker" notifications@github.com wrote:

I don't have the logs with cmake debug output enabled. I'd have to run locally or submit a new build with cmake debug output enabled. Can't promise to do anything soon. Any chance you can build on Appveyor? In the meantime, maybe someone from conda-forge can offer help? @ocefpaf https://github.com/ocefpaf ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/conda-forge/gsl-feedstock/issues/15#issuecomment-281778732, or mute the thread https://github.com/notifications/unsubscribe-auth/AA6BL_NKbv0BjwjBBu-HeRzQY4lsMqrJks5rfI7agaJpZM4MIn0X .

shadowwalkersb commented 7 years ago

@jeromekelleher , I didn't mean that it would make any difference. I just thought it might be easier to debug on Appveyor. @ocefpaf , have fun! 🚚

shadowwalkersb commented 7 years ago

@jeromekelleher , looking at your log, I think gsl.lib is not properly linked against. If you pass it simply as gsl.lib, you need to pass it the directory that it can be found in, too. Or, you can simply pass the absolute path of gsl.lib. GSL_DLL needs to be passed during compilation and not during linking. But, the linker already ignores it, so I hope your problem will be solved when you link properly against gsl.lib.

jeromekelleher commented 7 years ago

@shadowwalkersb, thanks I'll try this out later, and get it up and running on AppVeyor.

Good luck with the city move @ocefpaf!

jeromekelleher commented 7 years ago

Just a quick update here. I've tried putting in the full file path for gsl.lib @shadowwalkersb, and it made no difference (it would be surprising if this works, since it all compiles and links fine if I comment out the line referring to gsl_rng_default). I'm working on getting it all up on AppVeyor, but it'll take a bit of time.

I looked in the include dirs again, and it does look like defining GSL_DLL at compile time should work. It's a weird one...

jeromekelleher commented 7 years ago

It turns out this is solved by defining WIN32 at compile time. I guess this is defined during a CMake build, but isn't for a Pyhon setuptools build. So, both GSL_DLL and WIN32 must be defined for linking to succeed.

Thanks again for the help!

photon-schiesser commented 6 years ago

@jeromekelleher Could you help me understand why this occurs? With #define WIN32 at the top of my c++ file, I was finally able to compile. Defining only GSL_DLL was not sufficient.

I was going mad because it was working in VS 2017 (which had WIN32 already defined as a preprocessor but I didn't know that!), but it wasn't working when compiling with the command line tools for VS.

Very glad I found your comment.

jeromekelleher commented 6 years ago

Sorry @ScheissSchiesser, I have absolutely now idea how or why this works! I'm very much an outsider when it comes to windows and only know barely enough to get my software to work on it.