[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: List of FTBFS in Ubuntu

On Thu, Dec 09, 2010 at 02:00:24PM +0100, Olaf van der Spek wrote:
> On Mon, Dec 6, 2010 at 4:34 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> >> I was wondering why you considered the auto linking stuff to be so horrible.
> >> IMO the best solution would be to get auto link support into GCC too.
> >
> > It's non standard
> > - it's not specified by ISO C
> > - it's not specified by SUS/POSIX
> So?

When we write code, we write it with the intention and expectation
that it will be built using a standards-conforming compiler.  I.e.
one which implements the C and/or C++ language specification, and
which also implements standard UNIX command-line options.  While
platform- specific features are provided by various platforms, the
basic behaviour of the compiler and linker are specified by POSIX/SUS.

As an example, look at the SUSv3 specification for the "c99"
program (linked to gcc on GNU/Linux).  How to compile and link a
program is directly specified here.  You can't change that without
breaking a fundamental part of what a GNU/Linux system *is*.  If it's
no longer SUSv3 conforming, it's broken, because most of the programs
built on Debian rely upon this standard.

> > It's not portable
> > - it uses vendor-specific #pragma magic
> >
> > It's fragile
> > - every header must include the auto-link magic, either directly or
> >  indirectly.  If you forget to do this just once in a single file,
> >  linking will break
> Sounds like an easy-to-solve hypothetical problem.

Easy to fix once you notice a problem.  The issue is how maintainable
it would be in practice.  i.e. how often will people break it when
refactoring code, adding new headers etc..  It could be a significant

> > If it were incorporated into GCC, we still couldn't use it
> > - it's not backward compatible with other UNIX compilers
> > - it's not backward compatible with itself
> Who is we?
> Do we need that kind of backwards compatibility?

Yes, without a doubt.  If this was used by a project as the linking
mechanism, you wouldn't be able to build on any past release of Debian,
or any other GNU/Linux distribution.  You also wouldn't be able to
build on any other UNIX system.  It's not a feasible short-term goal.

Such a change should really go via the standards committees if
you really want support for such a feature.  But this is a long-
term solution, and would take years.  Also, the standards committees
tend to standardise existing practice, so an implementation of this
behaviour in GCC and binutils (ld/gold) would be a prerequisite.

As I mentioned at the top of this mail, standards conformance is a
big deal.  If we break that, we lose portability.  If this is done
through a revision to an existing standard (and SUS is probably the
best place for this; the C/C++ standards don't AFAICT involve
themselves in tool specs), support becomes much easier since it will
be adopted across all conforming platforms.

> > Now, pkg-config isn't standardised /either/, but it's useful because
> > it will work with any standards-conforming compiler.  It's just a
> > generalisation of existing practice (in the form of foo-config
> > scripts generated during a package build).
> Pkg-config probably isn't bad, but it does increase the complexity of
> build script. Especially compared to auto linking.

It integrates trivially with autoconf-using projects
(PKG_CHECK_MODULES).  It's also trivial to support in projects using
plain make or other build systems
(FOO_LIBS=$(shell pkg-config --libs foo)).

But the main thing going for it is that it works with existing
standards-conforming toolchains right now.  It doesn't require adding
non-standard compiler extensions.

> > But this is all moot.  I've written the pkg-config support into the
> > auto-link header, and we just need to integrate it into the build
> > system to get the job done.
> How does pkg-config handle the selection of the threading variant?
> Toolset-variant? Seems it's hard-coded to a single variant.

This is correct.  The auto-link support could be adapted to
encode the variant into the pkg-config .pc filename and/or the
library names.  Upstream specifically do not want to support
multiple .pc files (see the upstream bug report and mailing list

People who do need this can build multiple versions, install them
into different prefixes and then set PKG_CONFIG_PATH to select
the variant they want at configure time.  Unlike Boost, which has
to support Windows, we can support multiple versions very easily
without the need for encoding additional information into the library


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature

Reply to: