[Cmake] RE: cmake RFC

[David Capel]

On Wed, 2002-05-01 at 14:46, Bill Hoffman wrote:
> 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?

The -shared flag is indeed correct. I think -export-dynamic is only
necessary if you want to link a library as a dlopenable module, or an
executable which contains symbols which will be referenced by a dlopened
module. It doesn't do any harm though.  

> 
> >> 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.

That sounds like a good plan.

> >> > > 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.

Oddly (?) the only difference when using gcc-2.96 (Redhat version) is
the inclusion of -lstdc++ and -lm when linking via g++ (to an ELF
object). So the crtbegin/crtend/crti/crtn objects are linked-in
regardless, hence ensuring that global constructors/destructors are
called before/after main().

[ deleted ]

> >> > > 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.

That sounds promising.

> >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.

I'll see what I can do...

David