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

 
 

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

Submitter:  Petr Gotthard <gotthardp>
Submitted:  Tue 25 Nov 2008 10:15:57 PM UTC
   
 
Category:  CERTI Severity:  * 5 - Blocker
Item Group:  Compilation error Status:  Ready For Test
Privacy:  Public Assigned to:  gotthardp
Open/Closed:  Closed Release:  * CVS
Reproducibility:  None Fixed Release:  * 3.3.2
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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

Fixed.

Petr Gotthard <gotthardp>
Group Member
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>
Group 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>
Group Member
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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group Member
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>
Group Member
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>
Group 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>
Group 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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group Member
Wed 26 Nov 2008 03:30:26 PM UTC, comment #12: 

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

Eric NOULARD <erk>
Group 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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group Member

 

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

Attach Files:
   
   
Comment:
   

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

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

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

    Follow 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-05-31 erk Dependencies- bugs #30003 is dependent
    2009-04-29 erk Open/ClosedOpen Closed
        Fixed ReleaseNextRelease 3.3.2
    2009-04-04 gotthardp StatusIn Progress Ready For Test
    2009-04-03 gotthardp StatusReady For Test In Progress
    2009-04-02 erk StatusIn Progress Ready For Test
    2009-04-02 erk Attached File- Added certi-NoCircularRef-MinGW-Win32-OK-against-HEAD.patch, #17851
    2009-02-02 erk Attached File- Added certi-NoCircularRef-MinGW-Win32-OK.patch, #17383
    2008-12-13 None Attached File- Added time.patch, #17050
    2008-12-07 erk Attached File- Added win32-compile-24930-erkV1.patch, #16999
        Attached File- Added FederationsList.cc, #17000
    2008-12-07 erk Attached File- Added RTIG_processing.cc, #16998
    2008-12-07 erk Attached File- Added Exception.cc, #16996
        Attached File- Added Exception.hh, #16997
    2008-12-06 erk StatusNone In Progress
    2008-12-05 gotthardp Attached File- Added certi.patch, #16986
    2008-11-25 erk Attached File- Added libRTI-NG-win32-compile.patch, #16922

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code