compiling/linking problems in Windows VS15 -> unresolved external symbol get_network_output_layer_gpu

[toddberreth]

Perhaps there is a problem with the pre-compiled darknet.lib and darknetd.lib, and the renamed function get_network_output_layer_gpu( network net, int i ) -> get_network_output_gpu_layer( network net, int i )?

I'm not able to finish linking with the pre-compiled library vs\x86 in Visual Studio 15, it throws the error

LNK2001 unresolved external symbol get_network_output_layer_gpu

[genekogan]

this was fixed in commit https://github.com/mrzl/ofxDarknet/commit/8ba7ade7709560667501c5492a16f823235955ae. it should be * get_network_output_layer_gpu in the header. do you have an old version of the library? try updating/cloning again.

[gurmeetsidhu]

BUMP Same issue... have the right commit as I have * get_network_output_layer_gpu. But its weird I don't see "network_kernels.cu" in my external dependencies or included files and I don't really know how to add it I feel the issue stems from here because this is where it would be defined?

[gurmeetsidhu]

Yea I found manually adding *.cu files resolves this linking issue. But currently dealing with further issues. Will notify if this issue is resolved ...

[gurmeetsidhu]

All right so I got it working but the fix is kind of sketch for the top fix ^^ . I just deleted the definition in the header file and everything works but I'm pretty sure that ain't the way to go

If anyone has a better way to solve this let me know.

[brinoausrino]

I got the same linker issue while compiling. @gurmeetsidhu what did you actually delete? The definition of * get_network_output_layer_gpu? @genekogan what would be the right way to fix it?

[gurmeetsidhu]

No, add all .cu files from the /libs/darknet/include and that should link the get_network_output_layer_gpu to its definition in the corresponding .cu file.

But the following error that I get (image I shared), if you do get that it's because of a duplicate definition which may have been a fault of my own. But if you do run into it then apply my hacky fix with discretion.

But in one of the other issues I learned that there is a memory leak leads to yolo not outputting bounding boxes and it bogs down. @mrzl is currently working on patching that. So in the meantime I'm actually using a darknet windows port to run yolo right now.

[genekogan]

those of you having this problem are all on windows right? you can see the fixes we made in https://github.com/mrzl/ofxDarknet/commit/8ba7ade7709560667501c5492a16f823235955ae. perhaps you have old version of the libraries compiled? can you try rebuilding the dll?

[Bendegreef]

I'm having the same issue as @gurmeetsidhu. How did you manually added the *.cu files? And in what header file did you delete the definition?

Thanks!

[timonsku]

Having the same issue here on 2 different Windows 10 machines, using the latest version from git and oF 0.9.8. Seems like those commits didn't fix the issue or the updated lib wasnt pushed to git?

I also had to change the type of numLayerTypes to const int because VS was throwing an error that the array wasn't evaluating to a const and that "array type int* [numLayerTypes] is not assignable".

Adding network_kernel.cu to the project resolves the issue but when I run the yolo2 example it crashes at Layer 24 with an "Assertion Failed! .. File:feoferr.cpp Line: 17 .. Expression public_stream != nullptr".

[naus3a]

Just for the record: I'm on VS15 + OF 9.8 + 22736989844d1c6866aae8af0628376e92df7f73 and I'm experiencing the exact same issues reported by other people:

• trying to compile a freshly downloaded example throws the "unresolved external symbol" error referenced by the this issue

• including .cu files, like @gurmeetsidhu suggests, fixes the 1st problem but throws the "already defined .obj" error

• commenting out the function definitions in deconvolutional_layer.h I can compile the software, but it crashes at Layer 24, just like @PTS93 says, but it seems to be a missing weight file.

I'll try to recompile the darknet library, as suggested by @genekogan and will report if it fixes the problem.

[vinjn]

@naus3a Does it fix?

[naus3a]

@vinjn it's working, but only with the hackish approach described above

[lab101]

Same issue here. At first I only wanted to use the classification so I disabled the faulty lines. float * features;// = get_network_output_layer_gpu(net, feature_layer); If you do this you can run the classification and deapdream demo without any issue.

Now I also want to use the yolo feature to access the coco database. I will try to rebuild the darknet.dll hopefully this wil fix the linker error.

Update: I rebuild the windows dll from AlexeyAB github But the issue is still there. I think I know why. The network.h header file is changed a lot in the original version so all these forks have different versions.

1. Current Darknet Github version https://github.com/pjreddie/darknet/blob/master/src/network.h Here there is no network gpu layer function anymore.

2. The ofxDarknet version https://github.com/mrzl/ofxDarknet/blob/master/libs/darknet/include/network.h float * get_networkoutputlayer_gpu( network net, int i );

3. The windows version https://github.com/AlexeyAB/darknet/blob/master/src/network.h float * get_networkoutputgpu_layer(network net, int i);

I think I will just use bits of code from ofxdarknet to work with the yolo dll from AlexyAB windows version. Will post if it works. (update it works check comment below)

[vinjn]

I have forked AlexyAB's repos to mine. https://github.com/jing-neural/darknet And do experiments in darknet directly.

[lab101]

Hey, I just made a new openFrameworks integration based on the darknet windows version. https://github.com/lab101/ofxYolo2 Works well so far.

[genekogan]

@lab101 is there any reason this can't be merged with ofxDarknet? having the examples working cross-platform would be very useful and avoid duplicating effort on the same things.

[lab101]

@genekogan that was my goal in the beginning but like described in my previous comment there's to much of a difference between the darknet version everybody is using. ofxDarknet is ahead of the windows port but behind the darknet official version. Either ofxdarknet needs to use an older version of darknet (same as the windows port) or somebody has to update the windows version (https://github.com/AlexeyAB/darknet) to the darknet version of ofxdarknet ... not sure how much work all this is.

[genekogan]

i don't think we are very far behind darknet official. with the applications you have mentioned (classification, yolo) as well as go, rnn, and deepdream, we are at the same place as the official. there has been some preliminary work on GANs which i intend to integrate in the near future. of course to the extent we are behind on anything, we could use help from contributors to catch up. as you said, the windows port you built from is behind ours and does not seem to be trying to absorb changes from the official upstream, whereas we are integrating directly from official. and it is also windows-only, and is certainly not going to do any favors to openframeworks. the reason our version has many differences is so that it can be cross-platform and openframeworks ready.

the windows linking issue i believe is related to https://github.com/mrzl/ofxDarknet/commit/8ba7ade7709560667501c5492a16f823235955ae and i know that @mrzl and others have it working. i would try to resolve but i'm on mac at the moment (i will also have windows+linux in another month). i don't think it's a critical issue, i'm sure it can be fixed without duplicating efforts on an separate, farther-behind library.

[timonsku]

I agree, a multiplatform effort should always be favoured. Though I do not think it has anything to do with that commit at all. If it was the solution outlined here wouldn't get it to compile on the latest commit, there are some dependency issues in the VS solutions and likely some compiler flags are not set, otherwise the performance wouldn't be so much worse than plain darknet. It just seems that the addon hasn't been tested for quite a while on windows.

[lab101]

hey offcourse I'm also in favour a multiplatform setup especially with all the samples. I tried to build the ofxdarknet dll before I looked at the alexeyAB windows port.

When running CMake in ofxdarknet I got this error... `-- CUDA Version: -- CUDA Libararies: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v8.0/lib/Win32/cudart_static.lib -- CUDA NVCC target flags: -gencode;arch=compute_20,code=sm_20;-gencode;arch=compute_30,code=sm_30;-gencode;arch=compute_32,code=sm_32;-gencode;arch=compute_35,code=sm_35;-gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_52,code=sm_52 -- CUDA FOUND CMake Error at CMakeLists.txt:89 (target_link_libraries): Cannot specify link libraries for target "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v8.0/lib/Win32/cudart_static.lib" which is not built by this project.

Don't know much of cmake so it's difficult for me to fix this one. Seems the same error as this one btw. `

[genekogan]

@mrzl @BildPeter any ideas?

[schwittlick]

I will probably do a re-work of this library soon, hoping to learn a bit from the pitfalls people have experienced here.

@lab101 CMake is only for OSX I believe, never tried it myself on Windows. I will probably go your way with pre-compiled binaries for this addon from now on, like you did in your yolo2 addon. Initially I was thinking it would be great to always compile darknet with your addon, so you have control and the ability to change things in the library as you go. But I guess people mostly just wanna use it. A separate section for compiling these libraries sounds like the way to go.

@PTS93 For me it is still running, though some changes to the addon for the osx version broke some dependencies, so an older commit should still work out of the box, probably this one if you want to use yolo/nightmare/classification/rnn stuff: 7f0555fd09b3724d302dc257c8551e401a5044e6

Let's cross fingers this goes smoothly :}

[lab101]

hey @mrzl thx for the feedback. I don't think cmake is osx only it really focusses on creating build files for different platforms. If you didn't use cmake where is this dynlib comming from?https://github.com/mrzl/ofxDarknet/tree/master/libs/darknet/lib/vs/x64/Release

[schwittlick]

Okay, so I had a look and sorted some things out, basically compiling a static lib compiled form a fork of AlexAB's repo: https://github.com/mrzl/darknet

I have pushed all changes to this branch, which works pretty smooth on my side, maybe you guys have a moment to check it out. You'll have to as usual take care of two things:

1. right click on the project -> Build Dependencies -> Build Customizations -> Tick CUDA 8 2. set an OPENCV_PATH variable pointing to your opencv 2.5.9 location (to the root directory, containing two folders: build and sources) This is actually only necessary for the darknet static libary project.

The branch is here and the examples should compile and run in x64 with Debug and Release outside the box, after you took care of these two points above: https://github.com/mrzl/ofxDarknet/tree/mrzl/windows

@lab101 Previously I've built the static library from my own project, which I haven't published and was not using CMake. but it's essentially the same like AlexAB's repository https://github.com/AlexeyAB/darknet and its much more organized, so I was happy to use his project as the library project. Anyways, it's not using CMake either, or am I missing anything?

[lab101]

hmzz getting a bit further now but got some issues at the init of darknet. The issue is happening in the dll so difficult to debug. As you mentioned before adding the whole darknet src in the project could be a good solution for this cross platform issues.

[schwittlick]

it's all working on current master \o/