Compilation of mico head

Karel Gardas

2012-07-18 10:36:52 UTC

Hi Dmitry,

could you be so kind and give a try to
http://mico.org/snapshots/mico-snapshot-2012-07-18.tar.bz2 ? I've just
tested this on Solaris 11 + GCC 4.7.1 both in 32bit and 64bit and
everything went fine, i.e. no compilation failure.

Thanks,
Karel

Post by Dmitry Kachan
Hi,
I just tried to install mico head on my machine (OpenSUSE 11.4; kernel
2.6.37.6 ; gcc version 4.7.0)
I've downloaded distributive*/mico-head-2011-01-18.tar.bz2/*
(18-Jan-2011 18:18 7.5M) from http://mico.org/snapshots/
make[1]: Entering directory `/<path-to-mico>/mico-head-2011-01-18/orb'
c++ -I../include -O2 -Wall -Wwrite-strings -fno-strict-aliasing
-D_REENTRANT -DPIC -fPIC -c orb.cc -o orb.pic.o
orb.cc: In member function 'CORBA::ORBInvokeRec*
orb.cc:2397:29: error: redeclaration of 'std::map<unsigned int,
CORBA::ORBInvokeRec*, std::less<unsigned int> >::iterator i'
orb.cc:2392:38: error: 'std::map<long unsigned int,
MICOMT::Locked<std::map<unsigned int, CORBA::ORBInvokeRec*,
std::less<unsigned int> > >*>::iterator i' previously declared here
orb.cc: In member function 'void
orb.cc:2448:29: error: redeclaration of 'std::map<unsigned int,
CORBA::ORBInvokeRec*, std::less<unsigned int> >::iterator i'
orb.cc:2443:38: error: 'std::map<long unsigned int,
MICOMT::Locked<std::map<unsigned int, CORBA::ORBInvokeRec*,
std::less<unsigned int> > >*>::iterator i' previously declared here
make[1]: *** [orb.pic.o] Error 1
make[1]: Leaving directory `/<path-to-mico>/mico-head-2011-01-18/orb'
make: *** [system] Error 1
2392 for (ThreadIDInvokeMap::iterator i = _invokes.begin();
2393 i != _invokes.end();
2394 i++) {
2395 Locked<InvokeMap>* map = (*i).second;
2396 AutoLock l2(*map);
2397 InvokeMap::iterator i = map->find(id);
2398 if (i != map->end()) {
2399 rec = (*i).second;
2400 return rec;
2401 }
2402 }
and
2443 for (ThreadIDInvokeMap::iterator i = _invokes.begin();
2444 i != _invokes.end();
2445 i++) {
2446 Locked<InvokeMap>* map = (*i).second;
2447 AutoLock l2(*map);
2448 InvokeMap::iterator i = map->find(id);
2449 if (i != map->end()) {
2450 delete (*i).second;
2451 map->erase(i);
2452 return;
2453 }
2454 }
Does anybody know how it should works? two same-name iterators?
To avoid these mistakes I've changed the name of iterators (second
2392 for (ThreadIDInvokeMap::iterator i = _invokes.begin();
2393 i != _invokes.end();
2394 i++) {
2395 Locked<InvokeMap>* map = (*i).second;
2396 AutoLock l2(*map);
2397 InvokeMap::iterator k = map->find(id);
2398 if (k != map->end()) {
2399 rec = (*k).second;
2400 return rec;
2401 }
2402 }
and
2443 for (ThreadIDInvokeMap::iterator i = _invokes.begin();
2444 i != _invokes.end();
2445 i++) {
2446 Locked<InvokeMap>* map = (*i).second;
2447 AutoLock l2(*map);
2448 InvokeMap::iterator k = map->find(id);
2449 if (k != map->end()) {
2450 delete (*k).second;
2451 map->erase(k);
2452 return;
2453 }
2454 }
These changes allowed me to go further with compilation of mico head.
Than I was forced to set the -fpermissive flag to compile a few files
c++ -I../include -O2 -Wall -Wwrite-strings -fno-strict-aliasing
-D_REENTRANT -D_GNU_SOURCE -DPIC -fPIC -c poa_impl.cc -o
poa_impl.pic.o
poa_impl.cc: In constructor 'MICOPOA::POA_impl::POA_impl(const
char*, PortableServer::POAManager_ptr, const PolicyList&,
poa_impl.cc:1955:80: error: invalid user-defined conversion from
'const ObjVar<CORBA::Policy>' to 'CORBA::Object*' [-fpermissive]
In file included from ../include/CORBA.h:153:0,
ObjVar<T>::operator T*() [with T = CORBA::Policy] <near match>
../include/mico/template.h:96:3: note: no known conversion for
implicit 'this' parameter from 'const ObjVar<CORBA::Policy>*' to
'ObjVar<CORBA::Policy>*'
poa_impl.cc:1955:80: error: passing 'const ObjVar<CORBA::Policy>' as
'this' argument of 'ObjVar<T>::operator T*() [with T =
CORBA::Policy]' discards qualifiers [-fpermissive]
make[1]: *** [poa_impl.pic.o] Error 1
make[1]: Leaving directory `/<path-to-mico>/mico-head-2011-01-18/orb'
make: *** [system] Error 1
is it okay? from my perspective this flag could make a unexpected
changes in workflow.
Anyway, after all these manipulations I've compile and install mico head.
with new mico head my project compiles perfectly, however during the
my_projrct: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.
Aborted
(this project worked perfectly with usual mico 2.3.13 and gcc v 4.6;
however I was forced to use gcc v 4.7, and the project started show me
segmentation fault on the mico functions during project execution.)
Does anybody knows how can I fix it?
Best regards
-Dmitry Kachan.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mico-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mico-devel

--
Karel Gardas ***@objectsecurity.com
ObjectSecurity Ltd. http://www.objectsecurity.com