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 <
brad.christian...@thalesgroup.com.au> 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:* osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] *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 <s.d.hamm...@googlemail.com>
> 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 <ande...@cs.umu.se> 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 <s.d.hamm...@googlemail.com>
> wrote:
>
>
>
> On 26 August 2010 17:35, Anders Backman <ande...@cs.umu.se> 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
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
>
> --
> http://www.ssTk.co.uk
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> 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
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
