some build hosts choke on stub libs

stub_libs building change

Certain build hosts are using build-ID tags in a note section, this is used to
match debuginfo with the binary it's for, as well as other purposes. All
that's okay - but the linker only adds tags if you ask it to, with the
--build-id option. gcc does this by default on systems which fully use this
behavior, which leads to an effect that if you link with gcc you get them, if
you link with ld you don't, unless you add the linker option.

The LSB stub libraries (also in lsb-build-desktop) are affected by this as they
are linked with a direct call to LD, when built on such a host they don't get
the id. Adding the linker option would cause these to likely not build on some
hosts which don't have the linker option.

Why is this a problem? Well, on the same host this behavior was observed
(Fedora 10), rpmbuild runs a tool to extract debuginfo to construct the
separate package, and this step now does validation on the build id's and
simply fails if it finds objects that don't have them. The result is we can't
package lsb-build-base or lsb-build-desktop on such a host, because the check
will fail.

Not sure if we need to fix for these packages, but an experiment showed that a
small patch will let things build calling the compiler for shared library
construction, and is attached here for record-keeping purposes - it's not
really tested whether the result is okay.

Note that packaging of lsbcc also fails, for the same reason but without as
simple an answer as "use cc to link" - the problem here is besteffort.o, and
object files, which haven't been linked, don't have this section. More
research needed there.