Hi Sukender, Add /FORCE:MULTIPLE to your link options
-Fred ----- "Sukender" a écrit : > Hi all, > > Any update on this side? I've got the same issue (I use fstream in my > project which depends on osgDB, under VC2010 x64). > Or is there a way to temporarily workaround this in OSG with an ugly > #ifdef? > > Sukender > PVLE - Lightweight cross-platform game engine - > http://pvle.sourceforge.net/ > > ----- "Anders Backman" <[email protected]> a écrit : > > > Ok, I have localized the problem. > > > > > > For example, the class osgDB::fstream: > > > > > > > > class OSGDB_EXPORT fstream : public std::fstream > > { > > > > > > }; > > > > > > which just inherits from std:.fstream causes the symbols of > > std::fstream to be exposed into osgDB.dll > > > > > > This effectively means that It might cause problems for people > linking > > against osgDB.dll later on. > > Same goes for inheriting from std::string, std::ostringstream etc. > > > > > > This must obviously be a bug, a very serious one in VS2010. > > We had a class derived from std::ostringstream, which exposed the > > symbols in the vtable for the class: > > > > > > namespace ns > > { > > class Notify : public std::ostringstream > > { > > }; > > } > > > > > > Using depends.exe to analyze the dll-file gives: > > > > > > const ns::Notify::`vftable'{for > `std::basic_ostringstream<char,struct > > std::char_traits<char>,class std::allocator<char> >'} > > > > > > My issue was reported to the msdn forum. Their first take was: Oh > you > > use CMake, thats not our product :-) > > But in later threads, they tried to reproduce the problem without > > luck... > > So if you manage to reproduce this in a small example, go ahead and > > post it. We must make them aware of this problem. > > > > > > > http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/191de00a-53c9-4bd9-9cb6-e844eb224ca2 > > > > > > /Anders > > > > On Mon, Aug 30, 2010 at 4:31 AM, Christiansen, Brad < > > [email protected] > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > Unfortunately I can't offer a solution, but I thought I would > mention > > I have come across this exact problem and have also pulled my hair > out > > trying to find a solution. This same problem exists when building > > virtual planet builder, linking with osgDB causes the multiply > defined > > symbols. I had no other issues building the 3rd party libs and osg > > with 2010. > > > > > > > > The only way I could move forward was to allow multiply defined > > symbols (as has already been mentioned). I agree this seems > dangerous > > and is not a solution but it has allowed me to continue working. So > > far it hasn’t caused any issues with my vpb build. > > > > > > > > Given you have used the streams extensively without issue and it > seems > > osgDB is the source of the trouble, have you had a look to see if > > there is any discernable difference between your code and that in > > osgDB ? > > > > > > > > I would love to find a solution to this. > > > > > > > > Cheers, > > > > Brad > > > > > > > > > > From: [email protected] [mailto: > > [email protected] ] On Behalf Of Anders > > Backman > > Sent: Friday, 27 August 2010 4:00 PM > > To: OpenSceneGraph Users > > Subject: Re: [osg-users] OT: VS2010 LNK2005 problem related to > > ostringstream > > > > > > > > > > > > > > > > I have verified the build mode for all ingoing libraries. > > > > > > > > > > > > I build all the dependencies myself. Including OSG. > > > > > > > > > > > > The problem I have (which is OSG related), is that if I build > without > > OSG support (no rendering), it all works. > > > > > > And I still use std::ostringstream and std::stringstream quite > > extensively... > > > > > > We still link against OpenThreads (but no rendering). > > > > > > > > > > > > > > > > > > So only when I link against osg (osg.lib, osgDB.lib, osgText.lib, > > osgShadow.lib, osgViewer.lib osgGA.lib) I get this problem. > > > > > > > > > > > > I have verified that osg (and OpenThreads) are all built > consistently > > all over the field. Release and /MD (MultiThreadedDLL), which is > > default from CMake. > > > > > > > > > > > > > > > > > > So I can use/link against OpenThreads.lib, but not OSG... > > > > > > > > > > > > Rather nasty problem, I'm trying to reduce it, but I'm getting > > nowhere. > > > > > > And once again, same settings, same CMake version, same code all > over > > the place, and it works in VS2008... > > > > > > > > > > > > /A > > > > > > > > > > > > On Thu, Aug 26, 2010 at 8:17 PM, Simon Hammett < > > [email protected] > wrote: > > > > Ah ok, then next things to check: > > > > Make absolutely sure you aren't mixing up objects & libraries from > the > > different builds. > > For my projects I include a vc version number in the name, so > > .vc7.lib/vc7.dll & .vc9.lib/.vc9.dll > > and I also use the vc version in the name of output & intermediate > > directory > > > > Then check all the code for any use of > > > > #pragma comment(lib, "libname") > > > > and make sure any preprocessor guards that select different versions > > have been updated to know about vc2010. > > > > > > > > > > > > > > > > > > On 26 August 2010 18:37, Anders Backman < [email protected] > wrote: > > > > Well, I have verified that ALL the dependencies Im using are all > built > > with /MD and NOT debug. > > > > > > Im building all of the dependencies for osg and our lib myself, so I > > got full control. > > > > > > > > > > > > Also, as I wrote before, I have even tried to build our libs using > > project files generated from cmake > vs2008, build with vs2008 -> > > works ok. > > > > > > Open same project files in vs2010 -> problem occurs. > > > > > > Im using buildscripts to build dependencies, and it all works for > > vs2008... > > > > > > No external libraries, everything is built from code. > > > > > > > > > > > > For VS2010, all the dependencies (including osg 2.8.3) builds/links > > fine. > > > > > > But for my libs, I get the linking errors. > > > > > > > > > > > > Allowing multiple symbols sounds dangerous, and it did not resolve > my > > problem... > > > > > > > > > > > > /A > > > > > > > > > > > > On Thu, Aug 26, 2010 at 7:26 PM, Simon Hammett < > > [email protected] > wrote: > > > > > > > > > > On 26 August 2010 17:35, Anders Backman < [email protected] > wrote: > > > > <snip> > > > > > > > > > > > > > > CMake defaults to /MD code generation (MultiThreaded). Im using this > > consistently over all my libraries (just double checked to be sure). > > > > > > Never use that setting unless you know what you are doing. > > > > Change every project to > > > > Multi-threaded Debug DLL (/MDd) for Debug builds and > > Multi-threaded DLL (/MD) for Release builds > > > > And it will all start working. > > > > Those Runtime library settings are the number one 'gotch-ya' for > > Visual studio, and Cmake defaulting to them is daft. > > > > -- > > http://www.ssTk.co.uk > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > > > -- > > http://www.ssTk.co.uk > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > > DISCLAIMER:--------------------------------------------------------------------------- > > This e-mail transmission and any documents, files and previous > e-mail > > messages attached to it are private and confidential. They may > contain > > proprietary or copyright material or information that is subject to > > legal professional privilege. They are for the use of the intended > > recipient only. Any unauthorised viewing, use, disclosure, copying, > > alteration, storage or distribution of, or reliance on, this message > > is strictly prohibited. No part may be reproduced, adapted or > > transmitted without the written permission of the owner. If you have > > received this transmission in error, or are not an authorised > > recipient, please immediately notify the sender by return email, > > delete this message and all copies from your e-mail system, and > > destroy any printed copies. Receipt by anyone other than the > intended > > recipient should not be deemed a waiver of any privilege or > > protection. Thales Australia does not warrant or represent that this > > e-mail or any documents, files and previous e-mail messages attached > > are error or virus free. > > > -------------------------------------------------------------------------------------- > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
