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. With Boost 1.30, everything compiles and links just peachy. When I pointed the project at Boost 1.33, I had to make a couple of small code changes: 1. I had to change boost::mpl::apply_if to boost::mpl::eval_if. 2. I had to stop using TrivialIteratorConcept and switched to ForwardIteratorConcept or RandomAccessIteratorConcept. That's really the only code changes I can think of but now my linker gives me a bunch of warnings and 1 error message, which is what's really killing me: Linking... LIBCMT.lib(typinfo.obj) : error LNK2005: "const type_info::`vftable'" (??_7type_info@@6B@) already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(strtol.obj) : error LNK2005: _strtoul already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(chkstk.obj) : error LNK2005: __chkstk already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(xtoa.obj) : error LNK2005: __ultoa already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(atox.obj) : error LNK2005: _atoi already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(typinfo.obj) : warning LNK4006: "const type_info::`vftable'" (??_7type_info@@6B@) already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(strtol.obj) : warning LNK4006: _strtoul already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(chkstk.obj) : warning LNK4006: __chkstk already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(xtoa.obj) : warning LNK4006: __ultoa already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(atox.obj) : warning LNK4006: _atoi already defined in cellexe.lib(Cellexe.exe); second definition ignored Creating library PharLapRelease/Devo.lib and object PharLapRelease/Devo.exp LIBCMT.lib(crt0.obj) : error LNK2001: unresolved external symbol _main PharLapRelease/Devo.dll : fatal error LNK1120: 1 unresolved externals Error executing link.exe. 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.
"Dan McLeran" <dan.mcleran@seagate.com> writes:
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. With Boost 1.30, everything compiles and links just peachy. When I pointed the project at Boost 1.33, I had to make a couple of small code changes:
1. I had to change boost::mpl::apply_if to boost::mpl::eval_if. 2. I had to stop using TrivialIteratorConcept and switched to ForwardIteratorConcept or RandomAccessIteratorConcept.
That's really the only code changes I can think of but now my linker gives me a bunch of warnings and 1 error message, which is what's really killing me:
Linking... LIBCMT.lib(typinfo.obj) : error LNK2005: "const type_info::`vftable'" (??_7type_info@@6B@) already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(strtol.obj) : error LNK2005: _strtoul already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(chkstk.obj) : error LNK2005: __chkstk already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(xtoa.obj) : error LNK2005: __ultoa already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(atox.obj) : error LNK2005: _atoi already defined in cellexe.lib(Cellexe.exe)
Looks like a build configuration problem. You seem to have a copy of your compiler's runtime lib linked into LIBCMT.lib and also into the DLL you were building. -- Dave Abrahams Boost Consulting www.boost-consulting.com
The weird thing is I didn't change the build config. The only thing I changed was the include path and a couple minor things in the code. I'm quite baffled by this. "David Abrahams" <dave@boost-consulting.com> wrote in message news:uoe59vay3.fsf@boost-consulting.com...
"Dan McLeran" <dan.mcleran@seagate.com> writes:
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. With Boost 1.30, everything compiles and links just peachy. When I pointed the project at Boost 1.33, I had to make a couple of small code changes:
1. I had to change boost::mpl::apply_if to boost::mpl::eval_if. 2. I had to stop using TrivialIteratorConcept and switched to ForwardIteratorConcept or RandomAccessIteratorConcept.
That's really the only code changes I can think of but now my linker gives me a bunch of warnings and 1 error message, which is what's really killing me:
Linking... LIBCMT.lib(typinfo.obj) : error LNK2005: "const type_info::`vftable'" (??_7type_info@@6B@) already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(strtol.obj) : error LNK2005: _strtoul already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(chkstk.obj) : error LNK2005: __chkstk already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(xtoa.obj) : error LNK2005: __ultoa already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(atox.obj) : error LNK2005: _atoi already defined in cellexe.lib(Cellexe.exe)
Looks like a build configuration problem. You seem to have a copy of your compiler's runtime lib linked into LIBCMT.lib and also into the DLL you were building.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
Why are you linking against libcmt if cellexe.lib has C runtime stuff? (what does cmt have that cellexe doesn't, in other words)
Yeah, the cellexe lib contains 90% of what I need but not all of it. I could just change the cellexe, but it's not that easy. This code runs in factories around the world 24/7 and it's kinda painful to upgrade thousands of machines to a new code version. So, I just leave the static stuff alone as much as humanly possible and add features via dlls.
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.
Me either. I'm playing some games with linkage order just to see if it affects the outcome. So far, the only thing I change from working to broken is the Boost directories. It's probably an MSVC issue, I just can't seem to work around it, yet. Unfortunately, the only compilers supported by this version of PharLap are MSVC6 and Borland 5.5, which I have. Some of my code will not compile under Borland as it is now, but I could make it so with some effort.
PS: PharLap is the Real-Time Windows-API-compatible mini-kernel? It looks quite cool.
It's OK. I'm pretty sick of programming against Windows 95 using a compiler from 1998, but it pays.
participants (3)
-
Dan McLeran -
David Abrahams -
Simon Buchan