New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unresolved external symbol when compile protoc with vs2015CTP in release mode (protobuf-3.0.0-alpha-2) #240
Comments
The warning looks suspicious indeed. Might be a VS2015 bug? Probably worth a bug report to the VS community as well. |
I'm having this problem too, right after migrating my project to VC 2015 Community RC. I posted a brief note on the Microsoft community forum referencing this thread. |
Same problem here |
+1 |
The problem has gone with visual studio 2015 rc. So this is indeed a bug of vs, not protobuf. |
Did MS just release a new 2015 RC ? The error showed up when I switched to On Tue, Jul 7, 2015 at 9:07 AM, toddwong notifications@github.com wrote:
|
I can still reprocude this issue using Microsoft Visual Studio Enterprise 2015 RC and protobuf v3.0.0-alpha-3.1.
And this warning:
|
I'm sorry , I mess up the build configurations. The issue still there in release mode. |
Hey, Any fix or workaround for this problem? How can I solve it for creating a release binary in VS 2015 (community) |
No fix for me, for now just building protoc in debug mode, and
|
I agree with @pherl's assessment that this is probably a vs 2015 bug rather than a protobuf one. Although I haven't been able to reproduce the exact problem in a simple program, I suspect the issue is related to declaration of specification of class template member functions. I mirrored the code structure of GenericTypeHandler with something like this: // foo.h template class Foo { public: static void Call() {} }; template<> void Foo::Call(); // foo.cc #include "foo.h" template<> void Foo::Call() {} #include "foo.h" int main() { Foo::Call(); } But when I tested the above program, it consistently fails with "Unresolved external symbol" error in both debug and release build. Not sure why protobuf code can still build debug build. |
Error is still occuring in the final release of VS2015 Enterprise |
If such changes can be compiled through modify message.h } // namespace protobuf } // namespace google modify message.cc 9> 正在生成代码... |
I can reproduce the problem while building the "2015-05-25 version 3.0.0-alpha-3" from the master with Visual Studio Professional 2015 (Version 14.0.23107.0 D14REL):
|
A quick and dirty hack for VS2015 x64 release build is to add another function implemetation into generated_message_reflection.cc |
Pull request #717 fixes this issue. |
Ha, I didn’t even see this issue – yes my pull request #717 is a workaround for exactly this. |
…ase build compiler bug. See issue protocolbuffers#240 - MSVC in VS2015 seems to inline a function it shouldn't. My original workaround was to disable inlining for the whole file, but I found a way to do it on just this specific function using __declspec(noinline). Unfortunately __declspec has to go at the start of the function declaration, while __attribute in GCC can go either before or after. I had to move lots of GOOGLE_ATTRIBUTE_NOLINE to make it compile. I have not yet tested this change with GCC. Will there be other side effects of defining this, given it wasn't previously? I also noticed a few functions marked with both the 'inline' keyword, and GOOGLE_ATTRIBUTE_NOINLINE - huh? Is there an explanation for this, or is it an oversight?
This should be fixed since pull request #726 has now been merged – I marked just the problematic function as __declspec(noinline) if the compiler is VS ≥ 2015. Can someone verify and close this issue? |
@TeBoring please help verify if it's working now for VS2015. |
For now, I should add next 4 lines to message.cc file: after template<> and before and after template<> and before Theese methods are imediately after fixed in #726 Message* GenericTypeHandler::NewFromPrototype(...) After this everything has built OK in MCVS 2015 Community Edition |
@xfxyjwf FYI, I confirm #726 has NOT fixed the problem. I have just updated my copy of the master and tried to build it with VS2015:
So, CMake patch in #717 still remains as the working solution for me. |
@0xAAE could you help send us a pull request? The change you mentioned seems to be what's missing from @DouglasHeriot's original pull request #726 |
Certainly, I'll send. Please, explain me briefly how can I do it. Also, notice that only release build produce the errors, debug one is OK |
Thanks. You can follow the generate instructions on how to send pull requests: Basically you first fork a protobuf branch under your github account, push your changes there, and create a pull request (a few simple clicks) to merge your branch to protobuf master branch. |
Ok, I'll post here when finish |
I've just done pull request #813 |
I believe this issue is fixed now (thanks @DouglasHeriot and @0xAAE ). |
* protocolbuffers/protobuf#240 * protocolbuffers/protobuf#813 * Add GOOGLE_ATTRIBUTE_NOINLINE to GetArena() and GetMaybeArenaPointer() methods. * This is to avoid "unresolved link" errors in MSVC 2015 during Release build
The following error reported:
And a suspicious warning:
The full output:
Any suggestion or workaround will be appreciated.
The text was updated successfully, but these errors were encountered: