unresolved std::list - what should I be looking for?

Using VC++8.0, I'm building an app that will ultimately use libsigc++2 (among others). For initial testing purposes I've built a small "HelloWorld" test app. When I build it I get the following unresolved external (sorry about the lengthy output !!):-

Quote:

---

HelloWorld.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) protected: class std::list<class sigc::slot_base,class std::allocator<class sigc::slot_base> >::_Iterator<1> __thiscall sigc::signal_base::connect(class sigc::slot_base const &)" (__imp_?connect@signal_base@sigc@@IAE?AV?$_Iterator@$00@?$list@Vslot_base@sigc@@V?$allocator@Vslot_base@sigc@@@std@@@std@@ABVslot_base@2@@Z) referenced in function "public: struct sigc::slot_iterator<class sigc::slot<void,struct sigc::nil,struct sigc::nil,struct sigc::nil,struct sigc::nil,struct sigc::nil,struct sigc::nil,struct sigc::nil> > __thiscall sigc::signal0<void,struct sigc::nil>::connect(class sigc::slot<void,struct sigc::nil,struct sigc::nil,struct sigc::nil,struct sigc::nil,struct sigc::nil,struct sigc::nil,struct sigc::nil> const &)" (?connect@?$signal0@XUnil@sigc@@@sigc@@QAE?AU?$slot_iterator@V?$slot@XUnil@sigc@@U12@U12@U12@U12@U12@U12@@sigc@@@2@ABV?$slot@XUnil@sigc@@U12@U12@U12@U12@U12@U12@@2@@Z)

---

Maybe I'm reading this wrong but it seems to suggest that it can't find std::list. But that can't be right because std::list is a template class so the linker shouldn't be trying to import it from anywhere. I think I must be misinterpreting the message. What does it mean? Is it in fact the function sigc::signal_base::connect that can't be found?

Quote:

---

Originally Posted by John E

Is it in fact the function sigc::signal_base::connect that can't be found?

---

I can build the app by commenting out all references to that function, so I'm guessing that it isn't getting found for some reason (admittedly it's in a DLL but I am linking to the relevant link library). My current theory is that it isn't being exported for some reason but I've used the library before without coming across this problem. :confused: I'll keep looking.... :ehh:

Did you build the DLL with the same compiler/settings as the client?
http://support.microsoft.com/kb/168958

gg

try to copy the dll and the lib file to the directory where the .exe is present

Quote:

---

My current theory is that it isn't being exported for some reason

---

The reason might be very simple: some template class/function is instantiated (outside the library) with the typename the dll has no implementation for.

That's strange - I didn't get any notifications for these replies :confused:

Frustratingly though, the problem mysteriously just disappeared. I'm beginning to have my doubts about VC++8.0 because I seem to be getting a lot of problems that just crop up occasionally and then disappear for no apparent reason. For example, when trying to run an app (particularly a Debug build) I'll often see messages saying that a particular DLL can't be found. A couple of hours later, the program will run just fine, even though I didn't change anything. I also get problems with certain projects being rebuilt all the time (as if they're out of date) when in fact, they're up to date. A couple of hours later, the problem will go away. Then the next day, it's back again. It all seems a bit flaky to me. :(

Hm, I don't have that experience at all with 2005, for me it's rock solid. I experience more that 2005 is the last (at the moment) good release of MSVC (2010 more or less untested). 2008 works ok but the help system very often fail to find things that 2005 do find, the parallell build is a build-boost when having a quad CPU but very often it also cause some pdb-lock that require a full rebuild or exit/restart to resolve.

I still use XP though so that might have something to do with it.

The problem with missing dll while running exe has nothing to do with VS, whatever version it is.

Quote:

---

Originally Posted by S_M_A

I still use XP though so that might have something to do with it.

---

I think you might be right. Before I actually bought VS2005 (which I'm using with Win7) I'd previously been using the Express Edition with XP and the only problem I remember was that it would lock up (sometimes for several minutes) when creating an ncb file for the very first time (in fact, that's still a problem, even with the Professional Edition which I eventually bought). I never had any of the other problems though.

Quote:

---

Originally Posted by Igor Vartanov

The problem with missing dll while running exe has nothing to do with VS, whatever version it is.

---

.... usually I'd be inclined to agree, except I'm pretty confident that this one definitely IS a VS issue. For example, one regular problem I see is when I press F5 to run an application in the debugger. Maybe 10-15 percent of the time I'll see a message box saying that MSVCR80D.dll can't be found. At first I tried all kinds of things to make this go away (with mixed success) but eventually, I hit on a reliable method.... rebuild the app's executable with the runtime library set to Multi-threaded Debug and run it. Now switch back to Multi-threaded Debug DLL and rebuild. So far, this has never failed to solve the problem! :confused:

Quote:

---

a message box saying that MSVCR80D.dll can't be found.

---

You definitely need to investigate this somewhat deeper. I could suspect the situation when the said dll version specified in the manifest does not match to the one installed in your system. If this appeared to be true, I would investigate who does cripple the manifest (source version control system might do, if you use any :))

Actually this is only a theory, as I never met the effect, with 2005, 2008 and 2010 studios, neither in XP nor 7. :)

I must admit Igor, I never had this problem either when I was using the Express Edition and XP. It worries me that the above rigmarole always seems to fix it (i.e. first I need to link statically to the Debug runtime, then I re-build again to link dynamically). When I first mentioned this problem on another thread, another user replied to say that he also suffered from it and had tried reporting it to Microsoft. However, because VS2005 was considered an old product, they weren't interested. :(

As long as you did not react to my mention of source control system, I can conclude you do not have one in use. :)

Oops, I forgot about that.... No, I'm not using source control at the moment.

looks like installation of VS has not happened properly.. leading to missing of the dll.. or mislocated.. try to search for that dll and copy it to your debug/release folder and try rebuild..

John what anti-virus do you use? In my experience most anti-virus programs occasionally cause those freeze/lockups. A bad disk may also do that but that should show up in the event log.

It could be worth to try to run without anti-virus for awhile. Especially if you have some known way of reproducing the issue.

Quote:

---

Originally Posted by vcdebugger

looks like installation of VS has not happened properly.. leading to missing of the dll.. or mislocated.. try to search for that dll and copy it to your debug/release folder and try rebuild..

---

That could be worth trying. I'll give it a go, next time this happens. Only malware product I'm using is Microsoft Security Essentials.

It's worth mentioning that the freezing only ever occurs the very first time that an ncb file gets created (i.e. for a brand new project). I can usually see the size of the ncb file growing and growing while my IDE is frozen. I get the impression that whatever creates my ncb files must be running in the IDE's GUI thread (hence why it appears to lock me out). The ncb files can be quite large (30MB is typical although I guess that's relatively small by today's standards!) No idea why they take so long to get generated. :confused:

Quote:

---

Originally Posted by John E

... you've installed a service pack which I haven't got (in fact, I don't think I've installed any service packs at all yet for VS2005).

---

http://msdn.microsoft.com/en-us/vstudio/bb265237

Your issue may of been fixed...

gg

For some reason I always put off installing service packs, even though I've never had a bad experience with them. Must put it on my TODO list..! That can be my new year resolution! :D