gameboy Posted October 22, 2017 Report Share Posted October 22, 2017 (edited) Today, I tested SVN20325, and I was compiling errors. External symbol error 65 error LNK2019: public: class std: could not parse: basic_string<char, struct: std: char_traits<char>, class std:: allocator<char> glooxwrapper:: Client: > __thiscall: getID (void) "(? GetID@Client@glooxwrapper@@QAE? AV? $basic_string@DU? $char_traits@D@std@@V? $allocator@D@2@@std@@XZ), the symbol" public: virtual void __thiscall function in XmppClient: (class: SendIqChangeStateGame std: struct: basic_string<char, std:: char_traits<char>, class: std: allocator<char> & class std: > const, struct: basic_string<char, std:: char_traits<char>, class: std: const & allocator<char> >) "(? SendIqChangeStateGame@XmppClient@@UAEXABV? $basic_string@DU? $char_traits@D@std@@V? $allocator@D@2@@std@@0 @Z D:\trunk\build\workspaces\vc2013\lobby.lib (XmppCl) cited Ient.obj) test My operating system is win10 64bit, and the compiler I use is VS2013. Edited October 26, 2017 by gameboy 1 Quote Link to comment Share on other sites More sharing options...
Imarok Posted October 22, 2017 Report Share Posted October 22, 2017 @@Dunedan Quote Link to comment Share on other sites More sharing options...
gameboy Posted October 22, 2017 Author Report Share Posted October 22, 2017 @elexis Quote Link to comment Share on other sites More sharing options...
Dunedan Posted October 22, 2017 Report Share Posted October 22, 2017 Relevant changeset: SVN20321. I'm afraid I can't really help here, as I'm neither really familiar with C++ nor do I have Windows available for testing. If there's anything I can help with I'm glad to do so. Just a shot, but can you check what happens if you apply the patch below? diff --git a/source/lobby/glooxwrapper/glooxwrapper.h b/source/lobby/glooxwrapper/glooxwrapper.h index 6b2f33a374..b6afe2bd6d 100644 --- a/source/lobby/glooxwrapper/glooxwrapper.h +++ b/source/lobby/glooxwrapper/glooxwrapper.h @@ -394,7 +394,7 @@ namespace glooxwrapper bool connect(bool block = true); gloox::ConnectionError recv(int timeout = -1); - std::string getID(); + const std::string getID(); void send(const IQ& iq); void setTls(gloox::TLSPolicy tls); 1 Quote Link to comment Share on other sites More sharing options...
gameboy Posted October 22, 2017 Author Report Share Posted October 22, 2017 (edited) @Dunedan @Imarok@ItmsUsing your patch, this error still exists at compile time. Edited October 22, 2017 by gameboy 1 Quote Link to comment Share on other sites More sharing options...
Dunedan Posted October 22, 2017 Report Share Posted October 22, 2017 Have you tried recompiling gloox as suggested a while back when you had a similar problem? https://trac.wildfiregames.com/ticket/4605 Quote Link to comment Share on other sites More sharing options...
gameboy Posted October 22, 2017 Author Report Share Posted October 22, 2017 Yes I tried recompiling gloox, but errors persisted. Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted October 22, 2017 Report Share Posted October 22, 2017 14 minutes ago, gameboy said: Yes I tried recompiling gloox, but errors persisted. @fcxSanya helped me with this problem: fcxSanya said: Add --build-shared-glooxwrapper to update-workspaces.bat run params or remove --use-shared-glooxwrapper inside. Quote Link to comment Share on other sites More sharing options...
elexis Posted October 22, 2017 Report Share Posted October 22, 2017 Ah, so the code isn't actually broken for windows, but we just have to upload a new DLL like was done in rP19712, right? Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted October 22, 2017 Report Share Posted October 22, 2017 1 minute ago, elexis said: Ah, so the code isn't actually broken for windows, but we just have to upload a new DLL like was done in rP19712, right? Yeah, it seems right. 1 Quote Link to comment Share on other sites More sharing options...
Imarok Posted October 22, 2017 Report Share Posted October 22, 2017 Could someone do that? (I currently don't have access to my PC...) Btw, @Itms why where there no warnings from Jenkins/vulkan, that the build is broken? Quote Link to comment Share on other sites More sharing options...
Stan` Posted October 22, 2017 Report Share Posted October 22, 2017 @Imarok I guess that's because its only in game. A bit like when you change requirements in c++ code for templates. Quote Link to comment Share on other sites More sharing options...
Imarok Posted October 22, 2017 Report Share Posted October 22, 2017 No, Vulcan failed with building the autobuild because of that. Quote Link to comment Share on other sites More sharing options...
leper Posted October 22, 2017 Report Share Posted October 22, 2017 Because compilation tests on Phabricator are only done one one platform (some Ubuntu last I checked) with a single compiler. Quote Link to comment Share on other sites More sharing options...
Imarok Posted October 22, 2017 Report Share Posted October 22, 2017 Sure, but we could let Vulcan find out which commit broke the windows autobuild and then post it somewhere or send a mail Quote Link to comment Share on other sites More sharing options...
leper Posted October 22, 2017 Report Share Posted October 22, 2017 Testing should happen on as many platforms as possible. At least some libc++/clang and some MSVC++ tests would be needed. Guess what has been argued for since ages, also guess what happened so far. Quote Link to comment Share on other sites More sharing options...
Imarok Posted October 22, 2017 Report Share Posted October 22, 2017 We can feel lucky to have at least some testing... Quote Link to comment Share on other sites More sharing options...
Itms Posted October 22, 2017 Report Share Posted October 22, 2017 24 minutes ago, leper said: Testing should happen on as many platforms as possible. At least some libc++/clang and some MSVC++ tests would be needed. Guess what has been argued for since ages, also guess what happened so far. Yes I fully agree with you and I don't think anybody has ever been against more testing - however putting that into place takes a bit more time than what I currently have. For Windows I admit I am the only active one with full access to stuff, so I am responsible, but for libc++/clang, I'd be happy to receive an incremental patch on top of D18 (I will probably commit the current one next week, so patches can be proposed!) I suspect making arc work under Windows through Jenkins job will be very tricky, so we probably shouldn't loose the habit of performing manual testing when touching sensitive things like the gloox wrapper. Quote Link to comment Share on other sites More sharing options...
Imarok Posted October 22, 2017 Report Share Posted October 22, 2017 Sure. What about: When an autobuild fails, Vulcan only applies the first new commit and then tries building, if that succeeds it tries the next one. By that, Vulcan finds out the commit which fails and than could notify the committee the same way, as it does, when a Linux post commit test/build fails. (Alternatively we could yous bisecting) Quote Link to comment Share on other sites More sharing options...
Itms Posted October 22, 2017 Report Share Posted October 22, 2017 7 minutes ago, Imarok said: Sure. What about: When an autobuild fails, Vulcan only applies the first new commit and then tries building, if that succeeds it tries the next one. By that, Vulcan finds out the commit which fails and than could notify the committee the same way, as it does, when a Linux post commit test/build fails. (Alternatively we could yous bisecting) Well autobuilds shouldn't fail, so if we don't test patches on Windows, we would be better off with autobuild failures loudly reported to everyone, and then we would figure out what broke. Let's keep the sophistication for clever continuous integration Quote Link to comment Share on other sites More sharing options...
leper Posted October 22, 2017 Report Share Posted October 22, 2017 Well someone might have also suggested having more than one person with access to some infrastructure. And last I checked I don't have any such access, and I might have better things to do than wait what seems like years for things to get anywhere than random ideas. Also libc++/clang even on some other *nix would help with not breaking that OSX/macOS/whatever support that always comes back to bite when a release is planned, but it does seem like just dropping that platform would be easier. Quote Link to comment Share on other sites More sharing options...
gameboy Posted October 22, 2017 Author Report Share Posted October 22, 2017 Has the issue been fixed? Quote Link to comment Share on other sites More sharing options...
gameboy Posted October 24, 2017 Author Report Share Posted October 24, 2017 We still can't compile it successfully in Windows 10 What time will the problem be fixed? Thank you, my friend. Please forgive my urgent attitude. Quote Link to comment Share on other sites More sharing options...
Imarok Posted October 24, 2017 Report Share Posted October 24, 2017 I'd guess the time is, uhmm ... just now? Try it out 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.