Thanks for replying,
I have Visual C++ 9.0, but I found the problem. It was a pretty easy fix.
Forgot to post the solution. Slipped my mind.
It was a combination of:
1) The project settings kept pointing to the old IDL (of 2.3.5).
2) The custom build path in the project settings was corrupted from the
upgrade to VS2008.
3) The IDL generates a name.cpp and a name.h. In the old IDL (2.3.5), the
cpp file was generated with the line:
#include "name.h"
The new IDL (2.3.13) generates a cpp file with the line:
#include <name.h>
Because of the change of brackets, I had to include an extra directory
(since < > checks environment and not dir of cpp).
Not sure why I didn't catch it earlier.
Thanks again
On Tue, Oct 20, 2009 at 11:18 AM, Karel Gardas
<kgar...@objectsecurity.com>wrote:
>
> Hello,
>
> what VC++ version do you use? Please make sure you use at least VC++
> 7.1. Everything older is unsupported.
>
> Thanks,
> Karel
>
>
> > Trying to upgrade my mico lib from 2.3.5 to 2.3.13. I thought a simple
> swap
> > would do it, but now it's been an exhaustive 5 days and I can't seem to
> > figure out the problem. I downloaded the .zip and did an "nmake /f
> > Makefile.win32" thru the VS Command Prompt. Everything went smoothly. I
> > copied the mico2313.lib over to where I had my mico235.lib. I changed the
> > reference to the 2313 lib. I get the 3 errors on a clean/rebuild:
> >
> > 1>main.obj : error LNK2019: unresolved external symbol "public:
> __thiscall
> > CORBA::IOP::ServiceContext::~ServiceContext(void)" (??1servicecont...@iop
> > @CORBA@@q...@xz) referenced in function "public: void * __thiscall
> > CORBA::IOP::ServiceContext::`scalar deleting destructor'(unsigned int)"
> > (??_gservicecont...@iop@CORBA@@qaep...@z)
> >
> > and
> >
> > 1>main.obj : error LNK2019: unresolved external symbol "public:
> __thiscall
> > CORBA::IOP::TaggedComponent::~TaggedComponent(void)"
> (??1taggedcompon...@iop
> > @CORBA@@q...@xz) referenced in function "public: void * __thiscall
> > CORBA::IOP::TaggedComponent::`scalar deleting destructor'(unsigned int)"
> > (??_gtaggedcompon...@iop@CORBA@@qaep...@z)
> >
> > and
> >
> > 1>xcom_idl.obj: error LNK2019: unresolved external symbol "public:
> virtual
> > class CORBA::ServerRequestBase * __thiscall
> > PortableServer::StaticImplementation::make_request(class
> CORBA::ORBRequest
> > *,class CORBA::Object *,unsigned long,class CORBA::ObjectAdapter *,class
> > CORBA::Principal *)" (?make_requ...@staticimplementation@PortableServer@
> > @uaepavserverrequestb...@corba@@pavorbrequ...@4@pavobj...@4
> > @kpavobjectadap...@4@pavprinci...@4@@Z) referenced in function
> > "[thunk]:public: virtual class CORBA::ServerRequestBase * __thiscall
> >
> PortableServer::StaticImplementation::make_request`vtordispex{8,8,4294967292,12}'
> > (class CORBA::ORBRequest *,class CORBA::Object *,unsigned long,class
> > CORBA::ObjectAdapter *,class CORBA::Principal *)"
> > (?make_requ...@staticimplementation@PortableServer@@$r477ppppp...@m
> > @aepavserverrequestb...@corba@@pavorbrequ...@4@pavobj...@4
> > @kpavobjectadap...@4@pavprinci...@4@@Z)
> >
> >
> >
> > NOTE: My mico235.lib wasn't compiled and built from source, it was
> > downloaded as a lib already.
> >
> > I tried including the other libs (idl2313.lib, micocoss2313.lib,
> > pthreadVC2.lib) that the nmake spit out. Same exact problem. I take the
> > HAVE_EXPLICIT_STRUCT_OPS preprocessor definition out, and I only get the
> 3rd
> > error. But I have to have this definition. It looks like I'm missing a
> > library, but I've included everything. Are the errors I have due to not
> > overriding/implementing them aka were those new functions introduced
> AFTER
> > mico 2.3.5? Tried looking through the archives and was unlucky.
> >
> > The ServiceContext and TaggedComponent are in the mico/orb/ioptypes.cc
> file.
> > The make_request (3rd error) is in the mico/orb/poa_base.cc file.
> >
> > I also tried 2.3.13RC1, but same thing happens.
> >
> > I change the reference back to mico235.lib and everything works fine and
> > dandy. Solution may be obvious as I'm not too experienced with linkers
> and
> > mico. It would make my day if anybody could help.
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Mico-devel mailing list
> > Mico-devel@mico.org
> > http://www.mico.org/mailman/listinfo/mico-devel
>
>
> --
> Karel Gardas kgar...@objectsecurity.com
> ObjectSecurity Ltd. http://www.objectsecurity.com
>
_______________________________________________
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
