Re: [certi-dev] CERTI Windows build

[Eric Noulard]

2011/9/28 Jan-Patrick Osterloh <address@hidden>:
> Hi JPL,
>
> --- Quoted from Jean-Philippe Lebel (Date: 28.09.2011 14:54): ---
>> Doing so would result, on Windows at least, on the VarData1516 not being
>> exported at all, thus resulting in a bunch of unresolved external when
>> linking with an app that uses Certi. I don't know I that could work on
>> mingw.
> Ok, I see that. But then I wonder on #3:
>
>> I've suggested that we use #3 but that we do not export symbol of
>>     VariableLengthData from either libfedtime1516 or librti1516.
> Isn't that then the same problem, if neither libfedtime1516 nor
> librti1516 export the VariableLengthData? I think one of them has to
> export the symbols.
>
> So, let's say libRTI1516 exports VariableLengthData, and libfedtime1516
> not. Then we just have to ensure, that fedtime can be build. For this,
> we could use the static library. I tried this, and for me it worked well
> on mingw. I attached my patch. Maybe you can test this with VS? If it
> works for you too, then Eric could check it on Unix.

It appear that on linux you cannot link a shared library with a static one...

so that:
TARGET_LINK_LIBRARIES(FedTime1516 VarData1516)

makes the link of FedTime1516.

On can keep the VarData1516 but it has to be shared on Linux.

Now since current CVS HEAD works well on Linux
may be we can just conditionnally build the static VarData1516
static lib, i.e. in the CMakeLists.txt

if(WIN32)
  build static VarData1516
endif()

if(WIN32)
   TARGET_LINK_LIBRARIES(FedTime1516 VarData1516)
else()
   TARGET_LINK_LIBRARIES(FedTime1516 VarData1516)
endif()


>> The
>>     circular dependencies is present in both Pitch and Mak
>>     implementation...
>
>  How are they solving the problem? I couldn't see how to do it in an
> other way, because as I read in the cmake documentation, circular
> dependencies work only, when both libraries are static libraries, but
> this is probably not what we wan't? Ok, I'm not that big expert with
> cmake, etc., maybe you have a better solution.

We are using CMake because it's convenient for portability but
nothing tell us that those who manage to build circularly dependent libs
do use CMake ;-]

Not doable with CMake does not mean not do-able.
As far as I understand the issue is that Windows linker requires to have
the so-called "A.LIB" library for building the B.DLL which depends on A.DLL

B.DLL --> A.DLL is a runtime dependency
B.DLL --> A.LIB is a build time dependency

since A.LIB is usually generated during the compilation of A.DLL
A.DLL --> B.LIB generates the trouble.

On unix you don't have any build time dep' beside the header so there
is no trouble.

On windows you may (not with plain CMake) find a way to create your
missing A.LIB (or B.LIB) before compilin A.DLL (or B.DLL)
this is the subject of these articles:

http://www.eggheadcafe.com/software/aspnet/30952908/how-to-create-a-lib-file-to-use-for-circular-dependencies.aspx
http://support.microsoft.com/kb/q131313/

however I will be pragmatic for this, if the STATIC lib is the way to
go on Windows go ahead
with this particular case in CMakeLists.txt we'll live with it.


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