Windows Caffe build with VS2010 and fail in the train stage

[spark123456789]

Deall all,
My problem happened in the train stage.
As I only have VS2010, so I didn't use the prebuild 3rd party library. I compiled the 3rd party from the very beginning.
The prompt is shown below.
solver_factory.cpp:29] check failed: registry.count ==1 <0 vs 1> Unknown solver type

Your system configuration

Operating system: Windows 7
Compiler: Visual studio 2010
CUDA version (if applicable): N.A.
CUDNN version (if applicable): N.A.
BLAS: OpenBLAS
Python or MATLAB version (for pycaffe and matcaffe respectively): Anaconda py2.7

[PENGUINLIONG]

It seems you haven't specify the solver to use or the name was not found in the list of available solvers. Actually according to the latest codes a list of solver names should be printed. It seems weird if your log is just finished at that point. Maybe updating your code could help you.

Please also notice, I heard of Caffe is in transition to C++11, so I would recommend you to install a later version of VS, at least VS2013, if your employer allows you to do so. The building process can be much easier too.

[spark123456789]

@PENGUINLIONG
Thank your for your reply.
It's my bad not show all the prompted message. The all message should be:
"solver_factory.cpp:29] check failed: registry.count ==1 <0 vs 1> Unknown solver type: Nesterov ***check failure stack treace: ***". It is weird that, in the place of <known types: the should be some name related to SolverTypeListString()>, but nothing shown at all.
I also searched github, and found the #15 may related to this issue, but I am not sure wether it is related to "the way templates are instantiated in windows ‘tigros commented on 13 Nov 2015'".
Unfortunately, In my condition, VS2010 is the only option.

[PENGUINLIONG]

Yes, it might be MSVC's fault. The optimization strategy MSVC used to tackle with templates is sometimes troublesome. Because, according to my knowledge, it specialize templates when and only when a template is actually used. Some statically declared type could then fail to work properly. But it's sort of magic, and it seems not a really plausible explanation.

Could you check if there are protobuf files generated?

./build/include/caffe/proto/caffe.pb.cc
./build/include/caffe/proto/caffe.pb.h
./build/include/caffe/proto/caffe_pb2.py

Or other output/intermediate files presents. The message seems indicating the protobuf related files were not properly prepared. Please also check if other solvers are all invalid.

[spark123456789]

the whole thing shown in the prompt is:
./caffe.exe train -solver solver.prototxt
upgrade_proto.cpp:1082] Attemping to upgraded input file specified using deprecated ' solver_type' field ' : solver.prototxt
upgrade_proto.cpp:1089] Successfully upgraded file specified using deprecated ' solver_type' field ' to 'type' field
upgrade_proto.cpp:1091] Note that future Caffe release will only suport 'type' field for a solver's type
caffe.cpp:213] Use CPU.
solver_factory.cpp:29] check failed: registry.count ==1 <0 vs 1> Unknown solver type: Nesterov
***check failure stack treace: ***"

[PENGUINLIONG]

I tried triggering the error with solver_type: "Nesterov" in the solver definition file:

Yet I received this:

[libprotobuf ERROR C:\Users\guillaume\work\caffe-builder\build_v140_x64\packages\protobuf\protobuf_download-prefix\src\p
rotobuf_download\src\google\protobuf\text_format.cc:298] Error parsing text-format caffe.SolverParameter: 17:14: Expecte
d integer or identifier, got: "Nesterov"
F0427 18:09:39.306716 12252 upgrade_proto.cpp:1101] Check failed: ReadProtoFromTextFile(param_file, param) Failed to par
se SolverParameter file: solver.prototxt
*** Check failure stack trace: ***

So it seems you are using a relatively old version of caffe. Please upgrade and use type: "Nesterov" instead:

If you have to use your version of caffe, try solver_type: NESTEROV.

[spark123456789]

@PENGUINLIONG
Thank you for your reply.
I have these three files (caffe.pb.h\caffe.pb.cc\caffe_pb2.py) generated by proto.exe.
I also try the default solver_type (SGD), by just commenting out #solver_type: NESTEROV, but the problem is appeared again, just prompted "solver_factory.cpp:29] check failed: registry.count ==1 <0 vs 1> Unknown solver type: SGD" this time.
I also successfully build the pycaffe project, and I have the file named _caffe.pyd in lib directory. After I switched to the pycaffe directory, I import the caffe by "import caffe" command, The program promted "from ._caffe import Net, SGDSolver, NesterovSolver, AdaGradSolver, \ ImportError: DLL load failed: The specified module could not be found“.
Is there some relationship between this two? Is it possible happened because of "the way templates are instantiated in windows "?

[PENGUINLIONG]

Not so intuitive but yes. There are things couldn't be found in Caffe, which indicates your build of library was incomplete for some reason. And that reason might be caused by MSVC's lazy instantiation strategy.

Maybe something tricky should be done to force some early versions of MSVC to instantiate templates. According to the issue you gave (#15 ), it might help if you remove the intermediate caffe.lib and have the codes for executables directly compiled, although more time will be taken.

Try making a new .cpp file in ./src/caffe and instantiate all templates used in these ways. I could have no more recommendation as I don't have much idea about that. /_\

[willyd]

Because of the way templates are instantiated in caffe we have to do some magic to force caffe.exe to link in all symbols which the linker would otherwise strip. Look for a file called include_symbols.hpp in your build directory. If this header file exist there must be some difference between VS2010 and 2013 or 2015. In that case you two options:

1. Add explicit reference to the solver and layers in caffe.cpp by for example defining a function that instantiates the Solver and Layer classes.
2. Try to build the shared library with BUILD_SHARED_LIBS=1.

Closing as VS2010 is not supported.