Dan McLeran wrote:
Yesterday, I tried upgrading from Boost 1.30 to 1.33 and I got the weirdest reaction from my linker. Some background: I am using MSVC6SP6; The code in question is a dll that runs under PharLap 9.1. I am linking against libcmt as well as a lib called cellexe.lib, which provides all of the C runtime stuff and PharLap-specific OS stuff. <snip>
Why are you linking against libcmt if cellexe.lib has C runtime stuff? (what does cmt have that cellexe doesn't, in other words)
I can't understand why the linker is now searching for _main when the project is a dll and I have all the necessary stuff: .def file, /dll switch, etc. I have compiled and run this dll for literally years when using Boost 1.30.
Can anyone think of anything in this Boost library upgrade that could cause this? Keep in mind that I did not change any project setting other than the include directories to point the compiler at the directories containing Boost 1.33 and that I have been using this code along with Boost 1.30 for years.
It sounds very strange. Is it possible to check this with another compiler? MSVC 6 is known to be rather, /interesting/ in it's interpretation of the standard, but I haven't heard much about linking issues. It could be a latent issue with your linking order that a change in the boost lib's exposed, but I can't think of any (reasonable) reason why they would. Can you give the link line you're using? Does removing LIBCMT stop the search for main (for some reason)? PS: PharLap is the Real-Time Windows-API-compatible mini-kernel? It looks quite cool. -- don't quote this