Jump to content
  • Advertisement
Sign in to follow this  
Evil Steve

Unity 64-bit compiling (again)

This topic is 4398 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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:)

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!