2 replies to this topic

[Snoob]

For my project I've to set up an Angleproject x64 build, which I've to integrate in my MinGW64 environment. The angle project build mechanism is exlusively for Microsoft Visual Studio. So I've set up Visual Studio 2012 and installed the defined requirements (Windows and Dx SDK). So far so good, I could build the complete project without any issue with Visual Studio for x86 platform.

When I try to build the sources for x64 platform the build fail on libGLESv2 build with Linker error:

error LNK1104: File "C:\angleproject\src\compiler\x64\Debug\BuiltInFunctionEmulator.obj" could not opened. C:\angleproject\src\libGLESv2\LINK libGLESv2

This is correct, the file doesn't exist. I figured out that this file is part of the translator_common subproject. And now comes the strange part I could not explain:

1. If I build the translator_common project as stanalone x64 build no object file is created under x64/Debug folder.
2. If I build same project as x86 build, the missing file is created for x86 under Debug/common and x64/Debug
3. Now I can build project successfully for x64 platform

4. If I now try to create the libGLESv2 project what has a indirect dependency to translator_common the file is deleted and not created. The failure above occurs.

The same failure occurs with translator_hlsl subproject, which has an dependency to translator_common and is used by libGLESv2 project.

I'm absolutly not familar with Microsoft Visual Studio. Has someone an idea what could be wrong.
Thanks for any help.

[Reedbeta]

How odd. I haven't used Angleproject before, but I've never heard of a problem occurring in VS builds with just a single file out of a project - usually such issues occur on a project-by-project basis. (Unless BuiltInFunctionEmulator.cpp is the only .cpp in that project?)

Anyway, (sadly) usually the first thing to try with weird VS build issues is to do a clean build, in case its internal dependency information is corrupted somehow. In VS, go to Build -> Batch Build, click Select All and then Clean. This will wipe out the built files for all platforms and configurations. Then try to build the desired platform/configuration again.

If it still doesn't work, try poking around in the project properties - right-click on the project node in Solution Explorer and choose Properties. Look specifically at the output/intermediate paths and names in the General tab - you should see something like $(Platform)\$(Configuration), which means it will generate paths like x64\Debug. It may have been changed from the defaults. The project properties can also vary per platform and configuration (see the dropdowns at the top of the properties dialog), so it's possible someone meant to change it for x64 and accidentally changed it for x86 as well, or some such.

Another place to look is in Build -> Configuration Manager. That sets which project configurations are built for each solution configuration. It's possible something is messed up there too (e.g. the x64 solution configuration builds the project in x86 or some such).

[Snoob]

Thanks Reedbeta for the detailed description. I will try it out ... For your information. The project folder (compiler) contains more than 90 files, splitted in the two translator projects. I think the link error is related to first file try to link ...