bugCERTI - Bugs: bug #24930, Win32 build is broken: Circular...

 
 

bug #24930: Win32 build is broken: Circular dependencies between libCERTI and libRTI-NG

Submitted by:  Petr Gotthard <gotthardp>
Submitted on:  Tue 25 Nov 2008 10:15:57 PM UTC  
 
Category: CERTISeverity: 5 - Blocker
Item Group: Compilation errorStatus: Ready For Test
Privacy: PublicAssigned to: Petr Gotthard <gotthardp>
Open/Closed: ClosedRelease: CVS
Reproducibility: NoneFixed Release: 3.3.2

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sat 04 Apr 2009 01:56:59 PM UTC, comment #41:

Fixed.

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Sat 04 Apr 2009 11:01:43 AM UTC, comment #40:

Nice catch Petr,

I did personnally had a look without finding.
How can compiler be such a fool!!

I'm ok with your solution which seems ok
besides the fact that we'll need to forward
call to embbeded class.

From a pure design point of view it may even
be a better solution for libRTI class not to
inherit from std::<Container> class, this
way we can only expose the appropriate interface.

Note that some do already do this with
"protected" inheritance instead of "public" inheritance.

Eric NOULARD <erk>
Project Administrator
Fri 03 Apr 2009 09:55:19 PM UTC, comment #39:

Did you ever exerienced this:

Two exported classes with an accidentally same base.

class __declspec(dllexport) ONE : public std::list<int>
{ ... };

class __declspec(dllexport) TWO : public std::list<int>
{ ... };

Will cause a link failure under VS because a system class genarated due to the template instantiation (_Container_base_aux_alloc_empty) has been generated twice.

In our case the VS failure is caused by std::list base classes in GAV.hh and similar base classes in RTItypes.hh.

I would propose to put the std::list inside the class, i.e. to transform

class __declspec(dllexport) ONE : public std::list<int>
{ ... };

into

class __declspec(dllexport) ONE
{
private:
public std::list<int> m_data;
};

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Fri 03 Apr 2009 03:36:11 PM UTC, comment #38:

Seems it doesn't work with VC9. It's caused by something in RTItypesImp.hh, but don't have any details yet.

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Fri 03 Apr 2009 10:59:01 AM UTC, comment #37:

You are welcome,
with this we should be able to release CERTI 3.3.2
for Windows and Linux.
(I may wait some more fix/features from Pierre and may be Christian).

Yes there is,

This way you have no libFedTime --> libRTI dependency
thus no circular dep.

This is ugly buts seems a usual "tricks" used by HLA 1.3 RTI.

For 1516/Evolved we should handle circular ref properly
which may needs a 2 phase compile on Windows.

Not done this time.

I'v checked the current HEAD now compile on Linux and Windows/MinGW.

I do have a compile error on libCERTI when using
Visual Studio 2008 Express (aka VC9),
would you be able to check a Windows/Visual Studio compile
on CVS HEAD, and tell us if you have any compile error
with your Visual Studio version?

My conf was Vista SP1 + VC9.

Eric NOULARD <erk>
Project Administrator
Fri 03 Apr 2009 07:28:34 AM UTC, comment #36:

Thanks for merging the patch, Eric.

Is there a reason why some throws in libRTI/RTIfedTime.cc were disabled?
My compiler warns about non-void function witghout a return value.

Index: libRTI/RTIfedTime.cc
===================================================================
RCS file: /sources/certi/certi/libRTI/RTIfedTime.cc,v
retrieving revision 3.1
diff -r3.1 RTIfedTime.cc
49c49
< //throw RTI::InvalidFederationTime("Could not cast to RTIfedTime");
---

> throw RTI::InvalidFederationTime("Could not cast to RTIfedTime");

73c73
< //throw RTI::MemoryExhausted("Cannot allocate RTI::FedTime.");
---

> throw RTI::MemoryExhausted("Cannot allocate RTI::FedTime.");

85c85
< //throw RTI::MemoryExhausted("Cannot allocate RTI::FedTime.");
---

> throw RTI::MemoryExhausted("Cannot allocate RTI::FedTime.");

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Thu 02 Apr 2009 07:57:25 PM UTC, comment #35:

I've just merged-in the branch to the HEAD.
Will retry a windows build tomorrow.

Corresponding patch against current HEAD attached.

(file #17851)

Eric NOULARD <erk>
Project Administrator
Mon 02 Feb 2009 02:07:55 PM UTC, comment #34:

Here comes a patch against
br_DEV_NoCircularRef branch

which makes it compiles on Windows with MinGW.

I still have the link error with Visual Studio Express 9.
I think this is a bug with some kind of STL issue with
this version.

I'll try the patch on Linux and then merge back
to HEAD.

(file #17383)

Eric NOULARD <erk>
Project Administrator
Wed 07 Jan 2009 05:14:51 PM UTC, comment #33:

I still have the error after a clean rebuild
1) all build tree delete
2) fresh checkout on the branch...

the only remaining difference is the Visual Studio version...

Note that I have the same error on the same machine
for Code::Blocks/MinGW build...
(plus a weird link error in libHLA
if I do not add HLA_EXPORT in front of __print_buffer)

I'll try to investigate this issue.

Eric NOULARD <erk>
Project Administrator
Wed 07 Jan 2009 04:45:01 PM UTC, comment #32:

All files are checked-in.

My configuration: Windows XP and Visual Studio 2005.

Sometimes the problems disappear when I re-run CMake, e.g. do "clean cache".

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Wed 07 Jan 2009 04:38:13 PM UTC, comment #31:

On my side the branch compiles fine on Linux but ...

I still have link trouble on Windows XP + Visual Studio Express 2008.

Are all your file checked-in?
If yes what is your configuration
i.e. Windows and Visual Studio version.

1>RTIambPrivateRefs.obj : error LNK2019: symbole externe non résolu "__declspec(dllimport) public: virtual _thiscall RTIfedTime::~RTIfedTime(void)" (__imp??1RTIfedTime@@UAE@XZ) référencé dans la fonction __catch$?callFederateAmbassador@RTIambPrivateRefs@@QAEXPAVMessage@certi@@@Z$0

1>RTIambPrivateRefs.obj : error LNK2019: symbole externe non résolu "__declspec(dllimport) public: _thiscall RTIfedTime::RTIfedTime(double const &)" (__imp??0RTIfedTime@@QAE@ABN@Z) référencé dans la fonction __catch$?callFederateAmbassador@RTIambPrivateRefs@@QAEXPAVMessage@certi@@@Z$0

1>D:\users\Erk\build_certi_NoCircRef\Debug\RTI-NG.dll : fatal error LNK1120: 2 externes non résolus

Eric NOULARD <erk>
Project Administrator
Wed 07 Jan 2009 11:14:25 AM UTC, comment #30:

Nice work.
I'll have a look and get a try too and
may be we can merge the change into HEAD afterwards.

Eric NOULARD <erk>
Project Administrator
Wed 07 Jan 2009 10:42:07 AM UTC, comment #29:

Seems a miracle have happened! The br_DEV_NoCircularRef branch now compiles and executes under both Windows and Linux.

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Mon 05 Jan 2009 03:45:42 PM UTC, comment #28:

Happy New Year, Eric!

the latest sources are in CVS (under that branch), but...

I just realized that I fixed only the libFedTime -- libCERTI circular reference.
The libFedTime -- libRTI circular reference is still there. It's the same old story: RTI::xxx need to create the FedTime and FedTime needs the RTI::exceptions.

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Sat 03 Jan 2009 01:56:22 PM UTC, comment #27:

Hi Petr,
and happy new year to you and your family.

You were right. My solution is not working
because of the stupid idea to put the factory
method in libRTI and not in libFedTime
with this idea we have an unavoidable

libFedTime --> libRTI --> libFedTime
dependency...

due to the fact that libRTI needs to
call FedTimeFactory::decode.

So far so good your solution is working mine is not.
Would you be able to check-in your up to date patch
in the br_DEV_NoCircularRef branch.

This way I may generate a patch a try to review
it for cvs HEAD.

Eric NOULARD <erk>
Project Administrator
Mon 15 Dec 2008 11:37:49 AM UTC, comment #26:

> I do not insist on my solution.


Don't worry patches and discussion are welcome.

> I was just uneasy about blowing off the CERTI-Win32 port and
> delaying the fix due to other tasks. :-(


I understand that and I appreciate your effort.
However don't blame you,

  • I did review your patches.
  • CVS version may sometimes be broken on non Unix platform

this should not last but CVS is CVS this is not a
version.

> I will use the branch and finish my patch.


Ok fine tell me when you are done.

Eric NOULARD <erk>
Project Administrator
Mon 15 Dec 2008 09:52:02 AM UTC, comment #25:

> However your patch is more pragmatic and is solving
> the circular ref win32 trouble so I did create
> a branch called "br_DEV_NoCircularRef"
> I would suggest you check-in your patch there.
> (we may even release a CERTI 3.3.2 using the branch).
>
> Then if I manage to successfully go to the end of my idea
> then I'll backport the part of your patch I'm missing.
> If I do run out of time or if I fail :-(
> then I'll throw my work and merge your branch on the trunk.


I do not insist on my solution. I was just uneasy about blowing off the CERTI-Win32 port and delaying the fix due to other tasks. :-(

I will use the branch and finish my patch. It would be fine to have a working win32 port again (using whatever solution).

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Sun 14 Dec 2008 05:53:44 PM UTC, comment #24:

short answer:
libCERTI should not use RTI::FedTime at all.

If you look at the RTI::FedTime usage structure you will
find 3 majors places:

libRTI because RTI::FedTime appears as parameter
for "time stamped" version of RTIambassador API.
in this case you may use the "abstract" version
because you wont create any RTI::FedTime object
you get them from the call.

RTIA: here you need the to be able to create
RTI::FedTime object and you may use:
1) the libFedTime directly (no circular ref problem).
2) the RTI::FedTimeFactory::
2.a) makeZero()
if you want a constant.
Note that you may then call
RTI::FedTime::setEpsilon()
RTI::FedTime::setPositiveInfinity()
if you need those constant.

2.b) decode(const char *)
when you received an encoded value from RTIG or Federate.

RTIG: you receive [encoded] timestamped request
but you need to compute LBTS
(or other time concerned activity)

you may use the same method as in RTIA with
no circular ref trouble either.

The majority of FederationTime usage in libCERTI
should use EncodeFedTime_t opaque type
(for example typedef EncodeFedTime_t vector<char>;)
This is true for Message::fed_time,
Message::lookahead, NetworkMessage::date ...

The only I saw (at the moment :-) is with LBTS.cc/LBTS.hh
which is used in RTIA and RTIG and is currently part of
libCERTI.

I would say that LBTS should be a templated class
taking a TimeType as template parameter which
conforms to the RTI::FedTime API.

Then LBTS becomes a "generic" Time computing algorithm
that may be used (without circular ref) from RTIG and RTIA.
In fact if we want to support user provided time type
every "time manipulating" algorithm should be generically
written using RTI::FedTime API.

From what I have seen it seems doable.

> I assume the RTI::FedTime successor (RTIfedTime) has the
> getTime() method and do cast everytime this method is
> necessary. In current CVS this is commonly used method for
> casting to double (that used for computations inside RTIA).


That's precisely the point I think we don't need this.
Casting to double was done for convenience, but from
waht I saw (again until now) every computation may be done
with
RTI::FedTime
or
RTI::FedTimeFactory

APIs.

I'll try to continue along this road a little bit.
However your patch is more pragmatic and is solving
the circular ref win32 trouble so I did create
a branch called "br_DEV_NoCircularRef"
I would suggest you check-in your patch there.
(we may even release a CERTI 3.3.2 using the branch).

Then if I manage to successfully go to the end of my idea
then I'll backport the part of your patch I'm missing.
If I do run out of time or if I fail :-(
then I'll throw my work and merge your branch on the trunk.

What do you think?

Eric NOULARD <erk>
Project Administrator
Sun 14 Dec 2008 09:47:56 AM UTC, comment #23:

OK. I wonder how you solve the problem caused by RTI::Exceptions generated by RTI::FedTime successors. Those cannot be used in CERTI. From my point of view the two independent classes are unaviodable.

I assume the RTI::FedTime successor (RTIfedTime) has the getTime() method and do cast everytime this method is necessary. In current CVS this is commonly used method for casting to double (that used for computations inside RTIA).

Tech answer: there is a typo in CMakeLists.txt; it should be FedTimeD.hh. In fact, without "D" it wouldn't compile on case-insesnsitive Windows compilers.

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Sat 13 Dec 2008 10:24:51 PM UTC, comment #22:

> I hope I did not interfere with your efforts.

You did :-).
No just kidding,
I was heading to another way to go for handling FedTime,
but I'm not finished yet...

My primary objective was not to get rid of circular
ref but to support user provided type, which will
frees us from circular ref.

In fact I think time is different from Exception and the like
there should not be a CERTI FedTime and RTI FedTime
because even if we can imagine a portable way
to go from user provided RTI::FedTime to CERTI::FedTime
we cannot build a user provided RTI::FedTime from
CERTI::FedTime.

My idea was to really make the RTI::FedTime an opaque
type for libCERTI.

In fact I think your idea is working because
you assume you have the method.

Double RTI::FedTime::getTime()

but unless I'm wrong this method is not in the HLA
(neither 1.3 nor 1516)

tech remark: Your patch does not compile on Linux
because of case sensitive FedTime.hh in
libCERTI/CMakeLists.txt
which is fedtime.hh on disk.

Do not commit your patch [yet].
I'll try to get mine to its end :-).

Eric NOULARD <erk>
Project Administrator
Sat 13 Dec 2008 06:01:39 PM UTC, comment #21:

Eric,
I fixed the libFedTime as well. Patch attached. I hope I did not interfere with your efforts.

I have
-- removed more RTI:: from certi.hh
-- duplicated time implementation into certi::FedTime and RTIfedTime.
-- changed TimeManagement to use certi::FedTime (marked as TODO for Pierre)

The certi implementation is in FedTimeD.hh (D = "double"). The filename is not nice. You might have a better idea.

Petr

(file #17050)

Anonymous
Sun 07 Dec 2008 09:53:40 PM UTC, comment #20:

Ok thanks Petr,

I'll go on with the libFedTime dependency.

Eric NOULARD <erk>
Project Administrator
Sun 07 Dec 2008 08:43:57 PM UTC, comment #19:

The changes are in CVS.

I found another catch (RTI::...) issue and removed the explicit certi:: prefix from symbols in RTIA/RTIG as this should be the default prefix there.

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Sun 07 Dec 2008 05:46:30 PM UTC, comment #18:

FederationList.cc has the same catch (RTI::...) issue.
I've attached the file.

I did attach the "whole" patch too just in case it's easier
to apply for others.

(file #16999, file #17000)

Eric NOULARD <erk>
Project Administrator
Sun 07 Dec 2008 05:33:39 PM UTC, comment #17:

OK I have found the issue.
Some catch statement in RTIG/RTIG_processing.cc sources wrongly caught:

catch (RTI::<exception> &e)

instead of

catch (certi::<exception> &e)

the modified file is attached.

I think this shouldn't have compiled at all
but in fact with the current state of the patch
certi.hh still includes RTI.hh which shouldn't
be the case.

I think after fixing this "RTIG/RTIG_processing.cc"
issue your may commit your patch and we could
go on in order to continue this effort.

(file #16998)

Eric NOULARD <erk>
Project Administrator
Sun 07 Dec 2008 04:43:39 PM UTC, comment #16:

The idea of the patch is to be able
to trace ANY exception.

You may
export CERTI_EXCEPTION=X

just as you may
export RTI_EXCEPTION=X

this should work on windows as well too.
Note that in the same way you can monitor
NetworkMessage/Message exchange using

RTIG_MSG=D
RTIA_MSG=A

Eric NOULARD <erk>
Project Administrator
Sun 07 Dec 2008 04:41:29 PM UTC, comment #15:

Hi Petr,

After "manual" reviewing your patch seems OK but I do have
a trouble with FederateAlreadyExecutionMember which
does not flow from RTIG to RTIA properly...

(this is used by HLA_TestsSuite/test_Sync which
try to join with the name "syncFed<i>" where
is tried beginning with 0 and increment each time
FederateAlreadyExecutionMember is received)

The exception is generated on RTIG side but does
not appear on RTIA...

I'm still investigating the issue.

I would however propose to update your patch with
a basic tracability feature for certi::Exception.

See proposed Exception.[hh|cc] attached.

(file #16996, file #16997)

Eric NOULARD <erk>
Project Administrator
Sat 06 Dec 2008 02:19:53 PM UTC, comment #14:

Nice work,
I should be able to have a look at this tomorrow
and may tackle the FedTime trouble.

Eric NOULARD <erk>
Project Administrator
Fri 05 Dec 2008 06:11:51 PM UTC, comment #13:

My Windows compiler now complains only concerning FedTime, and first tests under Linux passed, so it might be a good time to make a first review round. A 220k patch this time :-/

I split exceptions, HandleSets and Regions into two different namespaces. The certi:: and RTI:: implementations are now very similar and some methods in the certi:: namespace are probably useless (can be deleted later). I expect after implementation of rti1516, the certi:: side will change significantly.

The libRTI target is back to "RTI", but the name is still "RTI-NG". This is because the RTI_EXPORTS. The define is CMake automated and it shouldn't be RTI_NG_EXPORTS.

(file #16986)

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Wed 26 Nov 2008 03:30:26 PM UTC, comment #12:

No problem,
since you will do it all then :=)

Eric NOULARD <erk>
Project Administrator
Wed 26 Nov 2008 02:58:50 PM UTC, comment #11:

I'm just somewhere in the middle of this task. I'm afraid this is a rename-compile job that cannot be split into more tasks.

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Wed 26 Nov 2008 02:02:49 PM UTC, comment #10:

> Avoid any certi:: class to be a child of a RTI:: class.


Yes I agree that what should have been done in the
beginning :=)

> There should be certi::FederateHandleSet, throwing certi::exceptions.
>The RTI::FederateHandleSet should be a wrapper of
> certi::FederateHandleSet, translating the exceptions (and possibly other values).


Yes we may have generic "wrapping/translating" functions
that properly translate
certi::<type> to needed rti::<type> and then you are right
to rti1516::<type>.

This may need some amount of work I gently called
"side-effect", sadly it may not be easily split in sub-task?

Would you have time and will to go into it?

Eric NOULARD <erk>
Project Administrator
Wed 26 Nov 2008 12:46:26 PM UTC, comment #9:

This is a pretty nice example of another problem:

> RTI::FederateHandleSet *
> RTI::FederateHandleSetFactory::create(ULong)
> throw (MemoryExhausted, ValueCountExceeded)
> {
> return ((FederateHandleSet *) new FederateHandleSetImp());
> }


RTI::FederateHandleSet methods throw RTI::Exceptions. Its child, the certi::FederateHandleSetImp cannot use any RTI::symbols since it's in libCERTI, but has to throw the same exceptions as RTI::FederateHandleSet.

Unless you find something better, I will try the following solution:

Avoid any certi:: class to be a child of a RTI:: class. There should be certi::FederateHandleSet, throwing certi:: exceptions.
The RTI::FederateHandleSet should be a wrapper of certi::FederateHandleSet, translating the exceptions (and possibly other values).

As a side effect, it may be easier to implement hla13, or hla1516 with the same libCERTI/RTIG/RTIA. We may have whatever functionality in certi:: and do translation to a particular standard RTI:: in libRTI-NG, librti13, or librti1516.

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Wed 26 Nov 2008 10:23:28 AM UTC, comment #8:

Go ahead any cleaner refactoring is beneficial
unless it would have foreseen side effects.

OK for GAV_aux.c deletion with proper implem' in GAV.cc

Eric NOULARD <erk>
Project Administrator
Wed 26 Nov 2008 10:04:30 AM UTC, comment #7:

Another side question:

The libCERTI/GAV.cc is empty and classes defined in GAV.hh are implemented in GAV_aux.cc.

I would suggest to move everything to GAV.cc and delete GAV_aux.cc.

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Wed 26 Nov 2008 09:54:12 AM UTC, comment #6:

Just a side-note.
The current RTI::Exception contains char*
for name and reason.

The drop-in CERTI::Exception replacement
should preferably use a std::string.

Eric NOULARD <erk>
Project Administrator
Wed 26 Nov 2008 09:44:17 AM UTC, comment #5:

That's a good way forward. I will try it.

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Wed 26 Nov 2008 09:00:14 AM UTC, comment #4:

> may use certi::Exception, store it to a code in certi::Message
> and the RTIambPrivateRefs::processException may translate that
> code into a RTI::Exception.


That's a valid technical solution,
in fact you do the "translation" at the same
time you "unmarshall/process" the exception.

However there is a side-effect,
all RTI::Exception directly thrown in RTIambassador may be kept
but every RTI::Exception thrown in libCERTI should be replaced
with "hopefully" identically named certi::Exception.

> Any idea how (in an elegant way) avoid the RTI::xxxSet::Create


As far as my find over the source told me we only
use two of them
RTI::AttributeSetFactory::create
RTI::AttributeHandleSetFactory::create

however we can design a generic scheme for avoiding circular ref.

transform every RTI::<WhatEverFactory>::create into
CERTI::<WhatEverFactory>::create

then make
RTI::<WhatEverFactory>::create
simply call
CERTI::<WhatEverFactory>::create

that's pretty much already what have been done in the past
(and probably forgotten since then) because if you
look at:

RTI::FederateHandleSet *
RTI::FederateHandleSetFactory::create(ULong)
throw (MemoryExhausted, ValueCountExceeded)
{
return ((FederateHandleSet *) new FederateHandleSetImp());
}

FederateHandleSetImp is belonging to libCERTI
the factory method belongs to libRTI.

With this scheme you use the XXXXImpl constructor when
within libCERTI and use the factory method when in libRTI
(on in a Federate).

I think this is the good way to go.
The RTI factory method usage from within libCERTI is a
mistake probably due to a misunderstanding and
too our very complete design documentation :=)

What is your opinion?

Eric NOULARD <erk>
Project Administrator
Wed 26 Nov 2008 08:36:45 AM UTC, comment #3:

Few quick comments (more will follow after I do more anlysis):

If libRTI-NG may use libCERTI, then libCERTI must avoid using any RTI:: symbols. I found at least two:
- RTI::Exceptions
- RTI::xxxSet::Create

We may not need any additional exception translation. I'm not (yet) sure if this will work, but libCERTI may use certi::Exception, store it to a code in certi::Message and the RTIambPrivateRefs::processException may translate that code into a RTI::Exception.

Any idea how (in an elegant way) avoid the RTI::xxxSet::Create inside libCERTI?

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.
Tue 25 Nov 2008 10:50:32 PM UTC, comment #2:

OK my patch should not be enough, now I remember.
We have used the "somehow lazy approach" of
using RTI::Exception inside libCERTI.

All this happens in:
certi.hh

// RTI Shortcuts
typedef RTI::AttributeHandle AttributeHandle ;
typedef RTI::AttributeHandleSet AttributeHandleSet ;
typedef RTI::DimensionHandle DimensionHandle ;
....

and even worse we use the RTI_EXCEPT macro for
defining CERTI internal Exception
later in certi.hh:

// CERTI Exception-derived Exceptions (including deprecated HLA exceptions)
RTI_EXCEPT(FederateNotPublishing)
RTI_EXCEPT(FederateNotSubscribing)
RTI_EXCEPT(InvalidObjectHandle)
RTI_EXCEPT(SecurityError)
...

I think its a bad idea.
We should have certi::Exception within certi.
Then RTIambassador should properly translate
from
certi::Exception to rti::Exception in order to
avoid the circular dependence alltogether.

This a little more work because we need
to replace the:
typedef RTI::AttributeHandle AttributeHandle ;
with something like a macro
CERTI_EXCEPTION(AttributeHandle)
and write a not so beautiful function/switch
which makes RTI::Exception out of any CERTI::Exception.

This may need some python scripting :-)
However I think it would be much better after that.

What is your opinion?
Should this solve the circular ref?
Do you find it's a good solution?

Eric NOULARD <erk>
Project Administrator
Tue 25 Nov 2008 10:38:21 PM UTC, comment #1:

Ouch,

Now I remember the hard time we had on the first Win32 compile...
I would rather avoid the circular ref alltogether.

libRTI-NG imports libCERTI that's fine.

but where exactly does the libCERTI imports RTI::Exception comes from?

I think the baseTypes.hh is wrongly #included in
SocketUN.cc and SocketTCP.cc

then the baseTypes.hh wrongly use the CERTI_EXPORT macro
instead of RTI_EXPORT

Would you try the attached patch?

(file #16922)

Eric NOULARD <erk>
Project Administrator
Tue 25 Nov 2008 10:15:57 PM UTC, original submission:

Even a small change can cause big troubles, so it did.

To compile under Windows, the involved DLL must have no circular dependencies. CERTI now does.
libRTI-NG: exports RTI:Exception, imports certi::Message and certi::Exception;
libCERTI: exports certi::Message and certi::Exception, imports RTI:Exception

Perhaps we need some more symbol shifting? BUT! The RTIA--Federate socket communication uses common classes, that are used from both libRTI-NG and libCERTI. The circular dependency is unavoidable.

I guess the only solution is to put some symbols into a static library and use it from both libRTI-NG and libCERTI.

What do you think should go into that static library?
- the symbols we just moved, i.e. RTI::Exception and RTI::...Set::Create()
- the certi:: exceptions, certi:: Message and the SockUN communication
- or something else?

Petr Gotthard <gotthardp>
Project MemberIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #17383:  certi-NoCircularRef-MinGW-Win32-OK.patch added by erk (47kB - application/octet-stream)
file #17050:  time.patch added by None (101kB - text/x-patch - Proposed change.)
file #17000:  FederationsList.cc added by erk (57kB - text/x-c++src)
file #16998:  RTIG_processing.cc added by erk (55kB - text/x-c++src)
file #16996:  Exception.cc added by erk (10kB - text/x-c++src)
file #16997:  Exception.hh added by erk (9kB - text/x-c++hdr)
file #16986:  certi.patch added by gotthardp (219kB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by erk (Updated the item)
  • -unavailable- added by gotthardp (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 17 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 31 May 2010 11:50:06 AM UTCerkDependencies-=>bugs #30003 is dependent
    Wed 29 Apr 2009 09:05:53 AM UTCerkOpen/ClosedOpen=>Closed
      Fixed ReleaseNextRelease=>3.3.2
    Sat 04 Apr 2009 01:56:59 PM UTCgotthardpStatusIn Progress=>Ready For Test
    Fri 03 Apr 2009 09:55:19 PM UTCgotthardpStatusReady For Test=>In Progress
    Thu 02 Apr 2009 08:23:47 PM UTCerkStatusIn Progress=>Ready For Test
    Thu 02 Apr 2009 07:57:25 PM UTCerkAttached File-=>Added certi-NoCircularRef-MinGW-Win32-OK-against-HEAD.patch, #17851
    Mon 02 Feb 2009 02:07:55 PM UTCerkAttached File-=>Added certi-NoCircularRef-MinGW-Win32-OK.patch, #17383
    Sat 13 Dec 2008 06:01:39 PM UTCNoneAttached File-=>Added time.patch, #17050
    Sun 07 Dec 2008 05:46:30 PM UTCerkAttached File-=>Added win32-compile-24930-erkV1.patch, #16999
      Attached File-=>Added FederationsList.cc, #17000
    Sun 07 Dec 2008 05:33:39 PM UTCerkAttached File-=>Added RTIG_processing.cc, #16998
    Sun 07 Dec 2008 04:41:28 PM UTCerkAttached File-=>Added Exception.cc, #16996
      Attached File-=>Added Exception.hh, #16997
    Sat 06 Dec 2008 02:19:53 PM UTCerkStatusNone=>In Progress
    Fri 05 Dec 2008 06:11:51 PM UTCgotthardpAttached File-=>Added certi.patch, #16986
    Tue 25 Nov 2008 10:38:21 PM UTCerkAttached File-=>Added libRTI-NG-win32-compile.patch, #16922

    Back to the top


    Powered by Savane 3.1-cleanup