[CMake] Mixing static and dynamic library

[Michael Hertling]

On 10/17/2011 09:31 AM, pellegrini wrote:
> Hi Michael,
> 
> thanks for your help.
> 
> You guessed right: there was no symlink against libXm.so.2. Surprinsigly 
> (is it actually ?) [...]

No, not really, see below.

> [...] there was no symlink against
> any of the libX libraries (Xmu, Xft, Xp ...) until I installed the 
> development packages that were missing for all of them.

Essentially, these so-called "name links" are a convenience feature
so that you can specify -lXm on the linker command line and have the
linker look for libXm.{so,a} automatically. You might also specify the
SONAME symlink or the actual library file instead. The reason why these
name links are typically contained in a package's development component
is the following: Suppose you have the Motif-2 runtime and development
components installed, i.e. libXm.so -> libXm.so.2 and libXm.so.2.x.y;
suppose further you have a Motif-1 program so you need the Motif-1
libraries. Now, if the Motif-1 package installs its name links, you
will end up with libXm.so -> libXm.so.1 so that the linker will link
against the Motif-1 libraries the next time it sees -lXm. Probably,
this is not what you want. Thus, the name links should be installed
by/for the packages that are used for development, and usually, you
cannot install the development components of different versions of
the same package to the same prefix, e.g. due to the headers. BTW,
CMake accounts for that with INSTALL()'s NAMELINK_{ONLY,SKIP} flags.

> The build works now, the output is not the one expected (a blank screen 
> instead of the expected GUI) but this is
> another story ...

Indeed, the lib{X11,Xt,Xm,...} stuff provides numerous opportunities to
stumble; e.g., not-managing Widgets, a missing XtRealizeWidget() on the
top-level shell or messed up resources are quite popular, IIRC. ;-)

> thanks again
> 
> Eric

Regards,

Michael

> Michael Hertling a écrit :
>> On 10/13/2011 03:27 PM, pellegrini wrote:
>>   
>>> Hi all,
>>>
>>> I would like to port a hardcoded build line from an old make file to my 
>>> CMakeLists.txt file for a fortran 90
>>> project using ifort compiler.
>>> The line is the following:
>>>
>>>     ifort *.o -o myexec -static-intel -Bstatic -lXm -Bdynamic -lXt
>>>
>>> First, if I get it right (sorry for my ignorance but I come from the 
>>> python world where I was quite
>>> preserved from these lines !!!), the goal is to build an executable:
>>>     - statically bound to the intel libraries
>>>     - statically bound to libXm library
>>>     - dynamically bound to libXt library
>>>
>>> A "locate" told me that on my machine both Xt and Xm are in dynamic form 
>>> (libXm.so.2, libXt.so.6) and in a standard location (/usr/lib). So in my 
>>> CMakeLists.txt file, I tried:
>>>
>>> set(CMAKE_Fortran_FLAGS_RELEASE "-static-intel")
>>> add_executable(myexec $SOURCES)
>>> target_link_libraries(myexec -Bdynamic Xm Xt)
>>>
>>> when building the project I get an error at link time (ld: cannot find 
>>> -lXm).
>>>
>>> Would you have any idea of what is going wrong with my settings ?
>>>
>>> thanks a lot
>>>
>>> Eric
>>>     
>>
>> The message "ld: cannot find -lXm" reveals that the linker can't find
>> libXm.so - or libXm.a if not ruled out - in the directories searched
>> for libraries; the mere presence of the SONAMEd libXm.so.2  does not
>> suffice unless you tell CMake to use it, e.g. via imported libraries
>> and appropriate IMPORTED_LOCATION properties. Typically, you have a
>> symlink libXm.so -> libXm.so.2 or to the actual library file, so the
>> -lXm is sufficient for the linker to succeed, but this symlink isn't
>> necessary to execute a program linked against the Motif library, and
>> sometimes it is dropped when the package's development component is
>> not installed. Thus, could you check if there is a libXm.so symlink?
>> If not, create it and try anew, and if it still does not work, could
>> you post the relevant part of the "make VERBOSE=1" output for further
>> investigation?
>>
>> Regards,
>>
>> Michael