bugCERTI - Bugs: bug #22881, libRTI requires libCERTI,...


bug #22881: libRTI requires libCERTI, libFedTime is missing

Submitter:  Petr Gotthard <gotthardp>
Submitted:  Wed 09 Apr 2008 03:38:13 PM UTC
Category:  CERTI Severity:  * 2 - Minor
Item Group:  HLA compliance error Status:  Ready For Test
Privacy:  Public Assigned to:  gotthardp
Open/Closed:  Closed Release:  * CVS
Reproducibility:  Every Time Fixed Release:  * 3.3.2
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Wed 26 Nov 2008 08:24:58 AM UTC, comment #13: 

Hi Petr,
Never mind.
I didn't remember if we already discussed
our bug processing way so I take the message
as an occasion.

Sorry about that if you already know :=)

Eric NOULARD <erk>
Group administrator
Wed 26 Nov 2008 08:20:01 AM UTC, comment #12: 

Well, you should "keep bug open" read as "keep bug in progress". I didn't mean to literally "close" the bug. I just wrote it in that way.

Petr Gotthard <gotthardp>
Group Member
Tue 25 Nov 2008 06:11:51 PM UTC, comment #11: 

Ok fine.
However concerning,

> I'll keep this bug open until I verify the CERTI build under Windows ...

Just a reminder:
A bug should remain Open until it
has been included in a CERTI Release.
However it should go from Status::In Progress to
Status::Fixed or Status::Ready For Test as soon
as you think it is in CVS and precisely "Ready For Test".

When I release CERTI I do check all
Open & Fixed or Open & Ready For Test bugs and close
them if I'm confident they are included in the release
at the same time I set the "Fixed Release" to the appropriate

The whole process is loosely described here:

Eric NOULARD <erk>
Group administrator
Tue 25 Nov 2008 05:06:44 PM UTC, comment #10: 

Patch applied, however I'll keep this bug open until I verify the CERTI build under Windows and try dynamic-link compatibility with MAK RTI.

Petr Gotthard <gotthardp>
Group Member
Mon 24 Nov 2008 11:53:21 AM UTC, comment #9: 

Ok with your patch.
Ga ahead apply it.

Eric NOULARD <erk>
Group administrator
Sat 22 Nov 2008 03:47:30 PM UTC, comment #8: 

Attached a patch and a new libRTI file that
 - change the libRTI to libRTI-NG
 - create libFedTime
 - move RTI symbols to libRTI

I prefer to not create any backward-compatibility libraries because it may cause unnecessary troubles when linking wrong libraries together.

(file #16898, file #16899)

Petr Gotthard <gotthardp>
Group Member
Sat 15 Nov 2008 05:35:16 PM UTC, comment #7: 

The HLA 1.3 DLC uses librti13 and libfedtime13. In a first step I propose to modify the libRTI(-NG?) and create a libFedTime.

I checked the libCERTI and only the following files need to be modified:
 - The RTI::xxx functions in libCERTI/GAV_aux.cc should be moved to a libRTI/RTItypes.cc
 - The RTI::xxx definitions in libCERTI/Exception.cc should be moved to libRTI/RTItypes.cc (yes, the same)

By doing this, all certi:: excepptions defined in libCERTI/Exception.hh will be implemented in libCERTI/Exception.cc and all RTI:: types defined in include/RTItypes.hh will be implemented in libRTI/RTItypes.cc. (I considered making libRTI/Exceptions.cc, but this seems to me more consistent.)

Then I propose to modify libCERTI/CMakeLists.txt, create there the libFedTime target a link there everything in FedTime.cc. The FedTime.cc may stay in libCERTI. (Or should it be moved to libRTI? Or to libFedTime? I think that moving it to libFedTime is not necessary.)

This should solve this bug report. As a next step, full DLC compliancy may be introduced, but this will require additional changes.

Petr Gotthard <gotthardp>
Group Member
Sat 15 Nov 2008 12:07:24 PM UTC, comment #6: 

We should add libFedTime
in order to be HLA 1.3 DLC compliant.

It would "only" break CERTI-specific federate
which should not be an issue, but it worth a poll on

What would you propose?

(I won't be much responsive this Week-End,
 next week will be better)

Eric NOULARD <erk>
Group administrator
Sat 15 Nov 2008 10:14:11 AM UTC, comment #5: 

Works well under Linux: Only libRTI needs to be linked (libFedTime is missing, but FindRTI handles that).

Under (my installation of) Windows both libRTI and libCERTI need to be included. The FindRTI therefore doesn't properly work with CERTI under Windows (the DLC compliancy is broken).

My Visual Studio says that the following should be moved to libRTI
 - RTI::Exception and its children
 - RTI::xxxxSetFactory::create()
 - RTIfedTime

Well, preferrably the RTIfedTime() should go to libFedTime, but this would break build of all existing CERTI federates.

Petr Gotthard <gotthardp>
Group Member
Thu 10 Apr 2008 09:07:10 AM UTC, comment #4: 

Thank you.

Just for the record: The problem reported in this report is valid also for the cmake, but I'm unnable to create the patch (yet).

The X11 related problem is reported as bug #22890.

Enjoy your holidays.

Petr Gotthard <gotthardp>
Group Member
Wed 09 Apr 2008 06:22:01 PM UTC, comment #3: 

OK I see,
It should work,
However, most of our machine do have X :-(
Could you open a specific bug for this
telling us more about the configuration
(Linux flavor, SOlaris etc...)
I will fix this.

In the meantime you may set
FORCE_NO_X11 using either

cmake -DFORCE_NO_X11=ON
using ccmake.

Eric NOULARD <erk>
Group administrator
Wed 09 Apr 2008 04:33:23 PM UTC, comment #2: 

Regarding cmake:
Seems that cmake does not set X_DISPLAY_MISSING. I have troubles building the examples when using cmake.

Petr Gotthard <gotthardp>
Group Member
Wed 09 Apr 2008 04:00:34 PM UTC, comment #1: 

Hi Petr,
Thank you for another patch.
I'll give it a look in a week or two since holidays
are coming for me.

From your patch I see you may be using autotools
to build CERTI.

We try to switch to CMake as build system
since we want CERTI to compile easily on Windows
and autotools are just painful beside cygwin.
There is a note on CERTI on Windows build with CMake:

The CMake-based certi build system is currently operational
on Linux/Solaris/Windows so
that I would advise you to give it a try since we may
drop autotools usage sooner or later.

Eric NOULARD <erk>
Group administrator
Wed 09 Apr 2008 03:38:13 PM UTC, original submission:  

An application must be linked with CERTI using
-lRTI -lCERTI -lxml

However, it should be independent on used RTI, so "-lCERTI" should not be used if no CERTI extensions are used.
For example, the MAK RTI can be linked using
-lRTI-NG -lFedTime

I suggest to create standalone libRTI, so -lCERTI and -lxml is not needed (when not using CERTI extensions). This is a "safe", backwards compatible change.
Additionaly, the -lFedTime library can be created, however this change might require changes to all simulations using CERTI.

See the attached patch.

Petr Gotthard <gotthardp>
Group Member


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

Attach Files:

Attached Files
file #16899:  fedtime.diff added by gotthardp (22KiB - text/x-patch)
file #16898:  RTItypes.cc added by gotthardp (16KiB - application/octet-stream)
file #15429:  makefile.patch added by gotthardp (2KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


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

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-04-29 erk StatusIn Progress Ready For Test
        Open/ClosedOpen Closed
        Fixed ReleaseNextRelease 3.3.2
    2008-11-24 erk StatusNone In Progress
        Assigned toerk gotthardp
        Fixed ReleaseUnknown NextRelease
    2008-11-22 gotthardp Attached File- Added RTItypes.cc, #16898
        Attached File- Added fedtime.diff, #16899
    2008-11-15 gotthardp ReproducibilityNone Every Time
    2008-04-09 erk Assigned toNone erk
    2008-04-09 gotthardp Attached File- Added makefile.patch, #15429

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code