Linking or Compiling... Nothing seems to be working!

#1

Hey all,

I’m having a lot of difficulty with 1.40. I have started to use the VC++ Express 2005 compiler/Platform SDK for coding, and things are not working out. Compiling and linking the library under the Express environment ends up giving me jucelib_static.lib in the bin/ directory, but linking with this library gives me an error on even the most basic JUCE project:

------ Build started: Project: demosaic, Configuration: Release Win32 ------ Compiling... main.cpp JUCE! Library to link to: jucelib_static_Win32.lib Linking... LINK : fatal error LNK1104: cannot open file 'jucelib_static_Win32.lib' Build log was saved at "file://f:\cpp\vcexpress\demosaic\demosaic\Release\BuildLog.htm" demosaic - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

This file doesn’t exist. I tried copying the file and naming the copy to that, but that gave me some linker errors:

------ Build started: Project: demosaic, Configuration: Release Win32 ------ Linking... jucelib_static_Win32.lib(juce_win32_Windowing.obj) : error LNK2019: unresolved external symbol "public: virtual __thiscall juce::ComponentMovementWatcher::~ComponentMovementWatcher(void)" (??1ComponentMovementWatcher@juce@@UAE@XZ) referenced in function __unwindfunclet$??0ActiveXControlData@juce@@QAE@PAUHWND__@@QAVActiveXControlComponent@1@@Z$0 jucelib_static_Win32.lib(juce_win32_Windowing.obj) : error LNK2019: unresolved external symbol "public: __thiscall juce::ComponentMovementWatcher::ComponentMovementWatcher(class juce::Component * const)" (??0ComponentMovementWatcher@juce@@QAE@QAVComponent@1@@Z) referenced in function "public: __thiscall juce::ActiveXControlData::ActiveXControlData(struct HWND__ *,class juce::ActiveXControlComponent * const)" (??0ActiveXControlData@juce@@QAE@PAUHWND__@@QAVActiveXControlComponent@1@@Z) jucelib_static_Win32.lib(juce_win32_Windowing.obj) : error LNK2001: unresolved external symbol "public: virtual void __thiscall juce::ComponentMovementWatcher::componentMovedOrResized(class juce::Component &,bool,bool)" (?componentMovedOrResized@ComponentMovementWatcher@juce@@UAEXAAVComponent@2@_N1@Z) jucelib_static_Win32.lib(juce_win32_Windowing.obj) : error LNK2001: unresolved external symbol "public: virtual void __thiscall juce::ComponentMovementWatcher::componentParentHierarchyChanged(class juce::Component &)" (?componentParentHierarchyChanged@ComponentMovementWatcher@juce@@UAEXAAVComponent@2@@Z) f:\cpp\vcexpress\demosaic\Release\demosaic.exe : fatal error LNK1120: 4 unresolved externals Build log was saved at "file://f:\cpp\vcexpress\demosaic\demosaic\Release\BuildLog.htm" demosaic - 5 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

This also happens with the same compiler under Code::Blocks (a recent nightly build).

When GCC 4.1.1 is thrown into the equation, I get a lot of errors cursing the long long datatype. Bypassing these errors leaves me with:

I’m at a loss for what to do! If at all possible, I would like to get the VC++ 2005 one working first as GCC tends to… just have more problems, unfortunately.

– Cam

#2

Sounds like you’ve got some kind of mix-up there - maybe you’ve got more that one juce source tree and are using the wrong one? The current version is designed to build jucelib_static_Win32.lib, not jucelib_static.lib.

#3

I’m having this exact same error. I’ve only got one copy of the source tree and never had any more than that.

Is there something obvious I’m missing?

#4

Nevermind, I found a solution from another thread. For anyone else having this problem, or a whole host of related problems, you need to change the little drop down menu on one of the top bars of visual studio to “Debug” instead of “Debug DLL”

#5

I did mention that in the notes, didn’t I?

Anyway, I’ve found a way to hack it so that in the next release it’ll all default to the non-dll builds and avoid any confusion.

#6

[quote=“jules”]I did mention that in the notes, didn’t I?

Anyway, I’ve found a way to hack it so that in the next release it’ll all default to the non-dll builds and avoid any confusion.[/quote]

I’m using 1.39. Is the hack in that version?

#7