64-bit compiling (again)

Started by
15 comments, last by ApochPiQ 17 years, 7 months ago
I was going to post a reply to my last thread, but it's been retired. I'm still having issues with 64-bit compiling, this time on a much simpler project (I gave up with x64 on my larger project). I get the exact same error message: DruinkEdit.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3 I can't disable exceptions, since then I get a bunch of errors about exceptions being disabled comming from the STL. Even this simple program doesn't link:

#include <windows.h>
#include <string>

static void ErrorBox(const std::wstring& strError)
{
	MessageBox(NULL, strError.c_str(), L"Error", MB_OK | MB_ICONERROR);
}

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
	ErrorBox(L"Test");
}



With the following errors:

------ Build started: Project: bar, Configuration: Release Win32 ------
Compiling...
Main.cpp
Linking...
Main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: wchar_t const * __cdecl std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >::_Myptr(void)const " (__imp_?_Myptr@?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@IEBAPEB_WXZ)
Main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: wchar_t const * __cdecl std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >::c_str(void)const " (__imp_?c_str@?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@QEBAPEB_WXZ)
Main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >::~basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >(void)" (__imp_??1?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@QEAA@XZ)
Main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >(wchar_t const *)" (__imp_??0?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@QEAA@PEB_W@Z)
c:\foo\bar\Release\bar.exe : fatal error LNK1120: 4 unresolved externals
Build log was saved at "file://c:\foo\bar\bar\Release\BuildLog.htm"
bar - 5 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========



Anyone got any [more] ideas? EDIT: It links fine if I remove the STL stuff and don't use any exceptions. But that's not very useful...
Advertisement
It looks to me like it simply isn't linking the libs into the rest of the code. Which seems strange if it can include standard libs. I am in no way meaning to insult you but just thought I'd try a memory test, did you check and insure the libs you're using are included in the project?

Since STL deals with templates perhaps that has something to do with it. Have you tried compiling using a library that doesn't use templates? Not that this is a long term solution but it may help isolate or define the problem.

"You can't say no to waffles" - Toxic Hippo

Yup, it's only linking in the standard libs. I tried creating an application not using the STL, and that works fine. An empty application with exceptions (try, catch, throw) in it also won't link.
Bump. Anyone had any problems with x64 and exception stuff?
Try including string before windows.h?
That won't affect anything, it's a link problem rather than a compile problem.

Tried it, no difference.
Quote:Original post by Evil Steve
That won't affect anything, it's a link problem rather than a compile problem.

Tried it, no difference.


Stupid question, but are you including the x64 versions of the standard libs? I'm new to the x64 platform myself, however I do know that a x64 application cannot link to an x86 dll (and vice versa). If I understand it correctly, it is because the 32 bit applications must be executed by the WOW64 service. In order to provide linking between the two, it would be quite a costly operation. I would imagine that an x64 app could not link to previously compiled x86 lib's because of the differences in code generation between the two. Not sure if this helps, you may even have looked into this already.
can you please post you complete compilation and ofcourse linking line(s) ...

may be he links to the rwong libraries?
im just guessing that the standard setup links to the 32bit version and thus its crashing.

(and yes i have no visual studio 2005 avail, to try it myself)

did you set up the correct library and include directories in your settings ? ( i remember, that there are some subdirectorys with "x64" in it.)


... why is there a penguin at the title (without this penguin i probably would have never whatched this one :lol:)
All the compiler directories are set to the /win64/amd64 folders where possible (E.g. E:\Microsoft Platform SDK\Bin\win64\AMD64).

My compiler line is:
/Od /I "E:\Source Control\DruinkClient\/" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_CRT_SECURE_NO_DEPRECATE" /D "_CRT_NON_CONFORMING_SWPRINTFS" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MDd /GS- /GR- /Fo"Debug x64\\" /Fd"Debug x64\vc80.pdb" /W4 /WX /nologo /c /Wp64 /Zi /TP /errorReport:prompt

And my linker line is:
/OUT:"E:\Source Control\DruinkClient\Debug x64\DruinkClient.exe" /INCREMENTAL /NOLOGO /MANIFEST /MANIFESTFILE:"Debug x64\DruinkClient.exe.intermediate.manifest" /DEBUG /PDB:"e:\Source Control\DruinkClient\Debug x64\DruinkClient.pdb" /SUBSYSTEM:WINDOWS /MACHINE:X64 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

I'm using VC2005 Professional if it makes a difference (Which does support x64).
well i dont understand much of this, but i doubt that this is everything ...
e.g. where is the linking of this crt stuff?

can you enable verbose output or sth like that?
or what does you build log say? (post it)

and did you try it without unicode? (at least i think that this "w"-stuff is unicode)


e.g. my gcc (amd64 ubuntu) says:
--------------------------------

#include <string>

int main( int argc, char **argv ) {

std::string s("asdf");

return 0;
}


---------------------------------------------
--------Compile------------------------------
---------------------------------------------
$ g++ -v -c test.cpp

Ziel: x86_64-linux-gnu
Konfiguriert mit: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release x86_64-linux-gnu
Thread-Modell: posix
gcc-Version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/cc1plus -quiet -v -D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -mtune=k8 -auxbase test -version -o /tmp/ccPTwlkQ.s
nicht vorhandenes Verzeichnis »/usr/local/include/x86_64-linux-gnu« wird ignoriert
nicht vorhandenes Verzeichnis »/usr/include/x86_64-linux-gnu« wird ignoriert
#include "..." - Suche beginnt hier:
#include <...> - Suche beginnt hier:
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/x86_64-linux-gnu
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/include
/usr/include
Ende der Suchliste.
GNU C++ version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) (x86_64-linux-gnu)
compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5).
GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
as -V -Qy --64 -o test.o /tmp/ccPTwlkQ.s
GNU assembler version 2.16.91 (x86_64-linux-gnu) using BFD version 2.16.91 20060118 Debian GNU/Linux


---------------------------------------------
--------Link---------------------------------
---------------------------------------------
$ g++ -v -o test test.o

Ziel: x86_64-linux-gnu
Konfiguriert mit: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release x86_64-linux-gnu
Thread-Modell: posix
gcc-Version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.0.3/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.0.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.0.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 test.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.0.3/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64/crtn.o

This topic is closed to new replies.

Advertisement