Hello Masa, I've installed "Service Pack 1" and "2" for NET. This did not help since the bug was discovered recently. Turning off the optimization has helped to compile "Cint" library. However I failed (so far) to create a DLL :-( I mean I've faced the problem that Axel had met: libCint.exp : error LNK2001: unresolved external symbol _CT??_R0?AVexception@@@8??0exception@@QAE@ABV0@@Z12 libCint.exp : error LNK2001: unresolved external symbol _CT??_R0?AVlength_error@std@@@8??0length_error@std@@QAE@ABV01@@Z40 libCint.exp : error LNK2001: unresolved external symbol _CT??_R0?AVlogic_error@std@@@8??0logic_error@std@@QAE@ABV01@@Z40 libCint.exp : error LNK2001: unresolved external symbol _CT??_R0?AVout_of_range@std@@@8??0out_of_range@std@@QAE@ABV01@@Z40 libCint.exp : error LNK2001: unresolved external symbol _CTA3?AVlength_error@std@@ libCint.exp : error LNK2001: unresolved external symbol _CTA3?AVout_of_range@std@@ libCint.exp : error LNK2001: unresolved external symbol _TI3?AVlength_error@std@@ libCint.exp : error LNK2001: unresolved external symbol _TI3?AVout_of_range@std@@ libCint.dll : fatal error LNK1120: 8 unresolved externals It sounds the name mangling the ROOT compilation generated and the names of the classes from the system library are different (missing namespace?? ) I'd like to call your attention to the "Microsoft Knowledge Base Article - 154419" says: " . . . NOTE: It may seem that headers without the ".h" extension are Standard C++ headers and ones with the ".h" extension are C-Runtime headers or old iostream headers. This is not true. As explained below, the files <useoldio.h> and <use_ansi.h> determine the libraries with which your application will link. Actually, there are two header files, <useoldio.h> and <use_ansi.h>, that contain #pragmas. The #pragmas force either the old iostream library or the Standard C++ library to be linked in by default. The header file <useoldio.h> contains #pragma statements that force the old iostream library to be linked in. All old iostream headers include <useoldio.h>: If you include any old iostream header in your application, the old iostream library will be linked by default. . . . " > -----Original Message----- > From: owner-roottalk@pcroot.cern.ch [mailto:owner-roottalk@pcroot.cern.ch] > On Behalf Of Masaharu Goto > Sent: Monday, December 02, 2002 5:22 PM > To: Axel Naumann > Cc: Marc Irsch; cint@pcroot.cern.ch; roottalk@pcroot.cern.ch > Subject: [ROOT] Re: Cint and MSVC7 > > Hello Alex, > > Thank you for trying this. Let me look into this. Meanwhile, > will you send me the modified bcvstrm.cxx? I'll try to generate > vc7strm.cxx out from it. > > There is another person who is compiling Cint (pure cint) with > VC++7.0. Sounds like he uses vcstrm.cxx and his original > VC++6.0 setup as is. Just for your information. > > Thank you > Masa Goto > > ======================================================= > Marc Irsch(marc@computerspacken.org) wrote: > > MG> I don't think debug and release build make big difference. It is > encouraging > MG> that you can run Cint with VC++7.0. We have several people who have > MG> VC++7.0 and having problem with Cint. It will be quite helpful if you > MG> provide us some information. > > MG> - How you compiled Cint with VC++7.0? > MG> a. with platform/visual/setup.bat script > MG> b. with src/libcint/libcint.mdp and cint/cint.mdp > MG> c. other > > The answer is c. I built my own project files on VC++ 6.0 and > imported them on VC++ 7.0 later on. > Worked immediately, without any modification. > > I didn't use the setup files with VC++ 7.0 yet. > > MG> - Which iostream dictionary file did you use? > MG> a. src/libstrm.cxx > MG> b. src/vcstrm.cxx > MG> c. src/cbstrm.cxx > MG> d. src/gcc3strm.cxx > MG> e. src/fakestrm.cxx > MG> f. other... > > b. > > MG> - I guess you compiled libcint.dll and cint.exe. How about other > MG> libraries > MG> especially precompiled STL container class libraries. > MG> stl/string.dll , stl/vector.dll , stl/list.dll , > stl/deque.dll , > MG> stl/map.dll , etc... > > Nope, sorry. Never touched these files. > > Regards, > Marc > > > > ----- Original Message ----- > From: "Axel Naumann" <axel-naumann@gmx.de> > To: "'Masaharu Goto'" <MXJ02154@nifty.ne.jp> > Sent: Tuesday, December 03, 2002 3:00 AM > Subject: Cint and MSVC7 > > > > Dear Masa, > > > > I finally sat down and tried to build CInt (well, Root's version of > > CInt) with Microsoft Visual C++.NET. As you suggested during the root > > workshop I started out with the bcstream files. Those worked quite well, > > the only changes I had to make were > > * remove wrappers to streambuf::sputn and sgetn (not supported by MSVC's > > streambuf) > > * fstreambase and strstreambase (they are not base classes for MSVC's > > fstream and strstream, only iostream is base for strstream): Remove > > class setup, method wrappers and inheritance setup > > * remove wrapper to strstreambuf::doallocate (declared as protected in > > MSVC) > > > > > > Now all I'm left with is > > > > libCint.exp : error LNK2001: unresolved external symbol > > _CT??_R0?AVexception@@@8 > > ??0exception@@QAE@ABV0@@Z12 > > libCint.exp : error LNK2001: unresolved external symbol > > _CT??_R0?AVlength_error@ > > std@@@8??0length_error@std@@QAE@ABV01@@Z40 > > libCint.exp : error LNK2001: unresolved external symbol > > _CT??_R0?AVlogic_error@s > > td@@@8??0logic_error@std@@QAE@ABV01@@Z40 > > libCint.exp : error LNK2001: unresolved external symbol > > _CT??_R0?AVout_of_range@ > > std@@@8??0out_of_range@std@@QAE@ABV01@@Z40 > > libCint.exp : error LNK2001: unresolved external symbol > > _CTA3?AVlength_error@std > > @@ > > libCint.exp : error LNK2001: unresolved external symbol > > _CTA3?AVout_of_range@std > > @@ > > libCint.exp : error LNK2001: unresolved external symbol > > _TI3?AVlength_error@std@ > > @ > > libCint.exp : error LNK2001: unresolved external symbol > > _TI3?AVout_of_range@std@ > > @ > > bin\libCint.dll : fatal error LNK1120: 8 unresolved externals > > make: *** [lib/libCint.dll] Error 96 > > > > An #include <exception> doesn't solve that problem. There are two things > > I don't understand with that: > > * why does the linker search for the symbol std::length_error and not > > length_error (without std::)? > > * why is the exception stuff not in MSVCIRT.LIB, the multi threaded > > dynamic link default library that supports the old iostream library > > (instead of the new std c++ lib) > > > > MS states clearly that the old iostream library (e.g. <iostream.h>) and > > the new std c++ lib are incompatible, and only one will be used at a > > time to search for symbols. If MSVC finds any #include<..h> (like > > <iostream.h> or <strstream.h>) it will use the old one. Maybe exception > > is not part of the old library? I really don't know, all I could find is > > that exception _is_ part of the _new_ std c++ library, but that still > > doesn't tell me whether it's also in the old iostream lib. Do you happen > > to know that? > > > > Hope we can figure this one out. > > Cheers, Axel. > > > >
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:22 MET