[Cmake] RE: cmake RFC

[Bill Hoffman]

At 02:08 PM 5/1/2002 +0100, David Capel wrote:

>> Can you be more specific about what is wrong?   CMake is working on many 
>> platforms
>> including many varieties of linux.   I am pretty sure that c++ -shared *.o 
>> is the way to build
>> a shared library on linux.
>
>Actually yes, I apologize. I thought that the -rdynamic flag (used in
>SHLIB linking) was deprecated in gcc, but actually it invokes
>-export-dynamic in the linker.

So, is cmake right or wrong here?

>> I am not sure how to fix this.  Do you have any suggestions?
>> For releases here, I usually create a directory with symbolic links to the 
>> static
>> libraries I need to link, and add that to the link path.   I guess you can
>> do -static -shared around libraries.  What do you suggest?
>
>That's what we do, but of course we have to do it with an manually
>edited link-line because there's no mechanism for specifying
>static/dynamic linking on 3rd party libs in CMake. This would be a very
>welcome addition. Maybe via an extra option which simply specifies a
>list of libs that should always be linked behind a -shared flag.
It would be a good addition.   How should it be specified?
Perhaps modify LINK_LIBRARIES and TARGET_LINK_LIBRARIES:
LINK_LIBRARIES(SHARED lib lib2 lib3  STATIC libs libs2)
TARGET_LINK_LIBRARIES(SHARED ... STATIC ...)

This would be used if possible for the compiler specified.


>> > > 3) The c++ compiler is used as the linker, meaning that
>> > > libstdc++ is always linked dynamically, which is bad.
>> > >
>> 
>> This is required for C++ code.  If you do not use C++ for the linker, global
>> constructors are not called properly.
>
>We always link with gcc and explicity specify -lstdc++ on the link-line.
>It appears to be the only way to get libstdc++ linked statically in
>release builds. I've never encountered any problems with this, but if
>you can highlight any then I would be very interested to hear.
If you have any global constructors that need to be called, and you link with gcc
they will not be called.

Try linking a shared library with gcc -v and c++ -v and look at the different
link lines.  They are quite different.

For releases, we do this:

[hoffman at ringworld hoffman]$ c++  foo.cxx 
[hoffman at ringworld hoffman]$ ldd a.out 
        libstdc++-libc6.1-2.so.3 => /usr/lib/libstdc++-libc6.1-2.so.3 (0x4001f000)
        libm.so.6 => /lib/libm.so.6 (0x4006e000)
        libc.so.6 => /lib/libc.so.6 (0x4008c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

# create a sym link to the static libstdc++:
[hoffman at ringworld hoffman]$ ln -s /usr/lib/libstdc++-libc6.1-2.a.3 libstdc++.a
# put the directory with the static libstdc++ in a -L directory and link:
[hoffman at ringworld hoffman]$ c++ -L. foo.cxx 
[hoffman at ringworld hoffman]$ !ldd
ldd a.out 
        libm.so.6 => /lib/libm.so.6 (0x4001f000)
        libc.so.6 => /lib/libc.so.6 (0x4003d000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[hoffman at ringworld hoffman]$ 

>> > > 4) There is no uniqifying of libraries on the link-line, so I
>> > > get cases where each library appears five or six times. I
>> > > guess this is hard to fix if there is no dependency engine to
>> > > determine the correct ordering. This makes the hand-editing
>> > > required in gripe 2 even more tedious.
>> 
>> This is a problem with vxl and how it uses cmake.   cmake does duplicate 
>> the libraries
>> twice, so that most of the time users do not have to worry about link order 
>> for static links
>> vs. shared links.   However, vxl, causes much more duplication than is done 
>> by cmake.
>> However, Amitha is working on a dependency engine as we speak to fix this 
>> for vxl.
>
>Yes, I've just been looking through the vxl source and I can see why it
>occurs. I'm looking forward to trying the dependency engine when it's
>ready. 

With the new cmake, I think this could be cleaned up some.   You can now have lists.
So, you can now store libraries in variables.

SET( packageLIBS a b c)
...

# this can be used in another cmakelist file:
LINK_LIBRARIES(${packageLIBS})

It may be possible to clean up vxl some with this approach.


>I would be happy to tinker with cmUnixMakefileGenerator if someone can
>suggest an acceptable fix for the static/dynamic linking problem. 

Sounds great, see above suggestion.


>BR,
>David.