certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] Problem building CERTI on Mac OS X


From: Eric Noulard
Subject: Re: [certi-dev] Problem building CERTI on Mac OS X
Date: Sun, 12 Jun 2011 11:49:28 +0200

2011/6/11 John Tipper <address@hidden>:
> After tearing my hair out literally all night, I've got CERTI to play on the 
> Mac, and thought I'd record what I did for the benefit of anyone else that 
> may come across this.
>
> I have rebuilt CERTI as a series of static libraries - this was done by 
> editing the CMakeCache.txt file and setting the shared library setting to OFF:

Editing CMakeCache.txt by hand may be dangerous.
You can switch to static build using cmake/ccmake/cmake-gui and set
BUILD_SHARED to OFF from there.

>> //Build libraries as shared library
>> BUILD_SHARED:BOOL=OFF
>
> When I tried to link this with a project being built in XCode, I then got 
> warnings that the architecture that these libraries was built for did not 
> match that which XCode was expecting (i386) - I'm running on a MacBook Pro.  
> So I then recompiled CERTI using the -m flag:
>
>> //Flags used by the compiler during all build types.
>> CMAKE_CXX_FLAGS:STRING=-m32
>
> and
>
>> //Flags used by the compiler during all build types.
>> CMAKE_C_FLAGS:STRING=-m32

This one is odd.
You should get the appropriate XCode project did you use CMake XCode
project generator?


> This will build most of CERTI (apart from the Windows specific modules that 
> Mark described
> in an earlier post, fails at 98%), albeit with a large number of warnings:

[...]

Yes we should fix those warnings, one by one.
Some of them are due to the circular ref trouble, some other
should definitely be fixed.
I'll try something next week.

However, patches are welcome :-]

> And this is where it gets to and fails, but the main libraries are built and 
> they now work:
>
>> [ 98%] Building CXX object 
>> test/utility/CMakeFiles/CertiProcessus_A.dir/Main_SocketSHM.o
>> Linking CXX executable CertiProcessus_A
>> ld: library not found for -lrt

This one should have been fixed,
are you using CERTI 3.4.0 or CERTI CVS version?

> To get my plugin to work I had to include libraries from the libRTI, libHLA 
> and libCERTI folders.

Yes this is the expected behavior since you have

libRTI --> libCERTI  --> libHLA dependency.
you may need to link with libFedTime too if you are using TSO services.

Thank you for your feedback.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]