G'day. I've just trying to compile IlmBase on Windows 7 x64 under VS2005. All the VS solutions failed during link time for me with a module vs link target platform config conflict. I later found out this was due to createDLL.exe adding a /MACHINE:x86 flag to the link.exe invoke. :)
As it happens I hate VS and actually most IDEs with every fiber of my body. :) So after hitting above wall, initially, in VS, I just rewrote the whole build system of IlmBase for CMake. It works a treat as far as compiling goes (tested on Linux, OSX & Windows with "NMake Makefiles" target). Now linking IlmBase on Windows, as far as I understand, is handled with a combination of the M$ linker and a tool called 'createDLL.exe' which exports global symbols from a .dll and creates the matching export .lib (aka: does away with the need for all that C-wrapper rubbish on windows). Sounds bloody awesome. All I had to do was to patch createDLL.cpp so it adds the /MACHINE:X64 flag to the linker, on request. Now for the problem: when createDLL runs link.exe with the response file this creates the .lib successfully but /deletes/ my .dll (instead of overwriting it, as the comment in createDLL.cpp says would happen). As a result I also get all symbols listed as undefined (i.e. they are in the .lib but the linker errors as the .dll is now missing). This is no problem while building IlmBase -- the linker only needs the .lib to create the resp. .dll for the next target. However, at the end, I'm left with a successfull build but no .dlls as they all get deleted, one by one, by createDLL's spawning of link.exe. :o So thats is where I'm stuck: how to get link.exe ran from createDLL to not delete the .dll. I must be missing something pretty obvious here? Beers, Moritz _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/openexr-devel
