[Cmake] RE: cmake RFC

[David Capel]

On Wed, 2002-05-01 at 12:54, William A. Hoffman wrote:
> At 11:34 AM 5/1/2002 +0100, Geoffrey Cross wrote:
> 
> >Can someone answer this (I'm a windoze user now):
> >
> > > Having used CMake for about a day now, I can summarize a few
> > > IMO fairly fundamental flaws in the UNIX makefile generator :
> > >
> > > 1) The flags passed to the to select static/dynamic linking
> > > are determined in a hand-edited configure file in the CMake
> > > distribution, and are wrong for Linux at least.
> > >
> 
> 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.

> > > 2) A typical release build will require some libraries to be
> > > linked statically (vxl,libstdc++) and others dynamically
> > > (GL,X,libm,libc). Apart from the linker flags being wrong,
> > > there is no mechanism for this split into "local" and
> > > "system" libraries. Consequently, hand-editing of link-lines
> > > is necessary to make release builds.
> > >
> 
> 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.


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

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

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

BR,
David.