Latest GIT error in Visual Studio 2003


#1

I get this error when compiling, but I don’t understand why:
\juceGIT\juce\src\gui\components\juce_Component.cpp(1562) : error C2326: ‘void juce::Component::exitModalState::ExitModalStateMessage::messageCallback(void)’ : function cannot access ‘juce::operator`!=’’


#2

That’s ridiculous - must be a VS2003 bug, there’s nothing wrong with the code. I guess the workaround is to change it to:

No such problems in VS2008. (I’d recommend moving to VS2008 if you can, its compiler is much more standards-compliant).


#3

I already reported this two weeks ago:
http://www.rawmaterialsoftware.com/viewtopic.php?f=3&t=6129

It still happens also in VS2005.


#4

[quote]That’s ridiculous - must be a VS2003 bug, there’s nothing wrong with the code. I guess the workaround is to change it to:

Code: Select all
if (target.getComponent() != 0)

No such problems in VS2008. (I’d recommend moving to VS2008 if you can, its compiler is much more standards-compliant).[/quote]

That does the job. Let me tell you why I’m using 2003, although I have VS2008 Express installed: It’s because 2003 is much faster when it comes to Intellisense and also compiling is faster. All in all 2003 seems lighter on the PC’s resources than 2008 and doesn’t make me wait as much. So I try to stay with it as long as I can. If I had had the choice I would still be using VS6 because it was even faster.


#5

Another issue (when linking my project against jucelib_static_win32.lib built of latest GIT), dunno if it’s VS2003-specific:

jucelib_static_Win32.lib(juce_win32_NativeCode.obj) : warning LNK4218: non-native module found; restarting link with /LTCG jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol __Getcvt jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol "public: __thiscall std::_Locinfo::~_Locinfo(void)" (??1_Locinfo@std@@QAE@XZ) jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol "public: __thiscall std::_Locinfo::_Locinfo(char const *)" (??0_Locinfo@std@@QAE@PBD@Z) jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol "public: __thiscall std::_Lockit::~_Lockit(void)" (??1_Lockit@std@@QAE@XZ) jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol "public: __thiscall std::_Lockit::_Lockit(int)" (??0_Lockit@std@@QAE@H@Z) jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol "private: static int std::locale::id::_Id_cnt" (?_Id_cnt@id@locale@std@@0HA) jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol "public: void __thiscall std::_String_base::_Xran(void)const " (?_Xran@_String_base@std@@QBEXXZ) jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol "public: void __thiscall std::_String_base::_Xlen(void)const " (?_Xlen@_String_base@std@@QBEXXZ) jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol "public: void __thiscall std::locale::facet::_Register(void)" (?_Register@facet@locale@std@@QAEXXZ) jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol "public: class std::locale::facet const * __thiscall std::locale::_Getfacet(unsigned int)const " (?_Getfacet@locale@std@@QBEPBVfacet@12@I@Z) jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol "public: __thiscall std::locale::locale(void)" (??0locale@std@@QAE@XZ) jucelib_static_Win32.lib(juce_String.obj) : error LNK2001: unresolved external symbol __Mbrtowc Release Standalone (JUCE151)/start.exe : fatal error LNK1120: 12 unresolved externals


#6

No idea. You know, your life would be considerably easier if you just used VC2008 and linked juce via the amalgamated build…


#7

Ok, I’m gonna give it a try. But I still would like to know what’s going on. The reason I am not fond of using the amalgamated version is that sometimes I tend to do modifications to JUCE (for instance when I fix a bug in JUCE myself) and so using the amalgamated version is not an option.


#8

Get the new jucer to create you a project that includes the library directly - that’s like the amalg version but it actually uses the cpp files directly so you can edit and debug them. That’s what I use for working on the library, so I’m sure it’ll be good enough for you to make a few changes.


#9

Now I get (when building my app, JUCE built fine!):

Linking... jucelib_static_win32.lib(juce_win32_NativeCode.obj) : warning LNK4218: non-native module found; restarting link with /LTCG Generating code g:\jucegit\juce\src\gui\graphics\imaging\image_file_formats\pnglib\pngerror.c(256) : warning C4702: unreachable code g:\jucegit\juce\src\events\juce_asyncupdater.cpp(48) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\main.c', line 148) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information LINK : fatal error LNK1257: code generation failed

I don’t understand why VS is moaning about a C++ file inside JUCE since that file has been compiled since long time ago.


#10

Sorry, I’ve no idea either! Might just be time to update to VS2008.


#11

Subliminal message:
Upgrade to VS2008

The current git tree is now more demanding on the C++ compiler. I recently backported the last GIT tree to VS6, and it’s a real real pain now.
Microsoft made some progress recently on their parser, with less ICE, less dumb error. But still, VS2003 is still using the VS6 technology, so it’s crashing everywhere unless you move the comma or rework your code with some more typedef, etc…
If you don’t want to upgrade to VS2008, try VS2005, it’s way better, not that slower than VS2003.

VS2010 is even better, their intellisense, for once, is usable.


#12

Sadly, I’m going to have to stick with VS2008. Although VS2010 is much better, they’ve deliberately nobbled a load of useful features, making the free version pretty much useless. And I’m far too cheap to pay for the pro version.

(…but if anyone from MS is reading this, and wants to send me a free copy of VS2010, I promise I’ll start saying nicer things about it!)


#13

Well the thing that makes all the difference is the linking, I don’t know why, but it takes about 1 min to link JUCE to my app in Release. With VS2003 it takes 2 seconds. If somebody can point me out why this is the case, or if somebody can guarantee me this is not the case with 2010, I’ll certainly switch.


#14

I don’t know about VS2008 (I don’t have it), but I had linker time issue in the past, with linux.
The solution was to use “gold” instead of “ld”, the former using O(log(N)) lookup on the mangled name, while the second use a hash table in O(1).
While theorically “ld” should be faster, there was so many collision (C++ mangled name are almost the same), that the whole link time was wasted in the collided bucket’s chained list, which is finally a O(N) algorithm.

Here, on VS2005, the link time with a pre-compiler juce library is very short (< 10s) (it’s not a big project, but still in the hundred of classes).
That said, Microsoft could have done the same “optimization” in their VS2008 linker. Try not to optimize for size, for example.

I don’t remember that my project took so much time to link in VS2010, but I can’t test right now. Will tell you later on.


#15

Ok, I’ll try 2005 then. VS2008 is unusable. The compilation takes about 5x more time than with 2003. I really don’t need that.


#16

Sadly, I’m going to have to stick with VS2008. Although VS2010 is much better, they’ve deliberately nobbled a load of useful features, making the free version pretty much useless. And I’m far too cheap to pay for the pro version.
(…but if anyone from MS is reading this, and wants to send me a free copy of VS2010, I promise I’ll start saying nicer things about it!)[/quote]

Before you go running off to upgrade to Microsoft’s proprietary product of the month, you might want to Google “Visual Studio 2010 sucks”:

http://www.google.com/search?q=visual+studio+2010+sucks

Basically, 2010 is a backward step from 2008 in many ways.


#17

2005 and 2008 are much slower than 2003, I tried 2005 now too and it’s about the same as 2008.
Jules, if you still have 2003, please give it a try, if it’s just about changing a few JUCE code lines, it’s worth it. It makes the development considerably faster to use 2003. I’m not talking about some 25% gain factor, but the build times are magnitudes faster than in 2005 or 2008.


#18

Have to admit that I’ve never really worried about build times, I’m more concerned about the compiler actually supporting the C++ standard and producing decent code! I don’t really mind if it takes a few extra seconds to build, I’m usually busy doing something else or thinking or staring blankly out the window when it’s doing that anyway…

Perhaps you’re just hitting a memory issue - the newer compilers use far more memory, has your machine got a decent amount of RAM?


#19

I’ve got 4GB RAM, and if I only modify 1 single line in my project, it takes each time 1:40 min to link in VS2005 or VS2008 (against maybe 5 seconds with VS2003).
I’m sure the problem causing the internal compiler error is just something really stupid. I’ve had this before in my own projects a few times, but at that time I knew what was wrong because it was just a matter of undo’ing until it compiled properly again .


#20

Try turning off Link Time Code Generation for your app and the JUCE library.

Matt