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

Re: List of FTBFS in Ubuntu

On Fri, Dec 10, 2010 at 1:09 PM, Roger Leigh <rleigh@codelibre.net> wrote:
>> 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.

Adding support for auto linking to g++ (via pragma or some other way)
doesn't mean g++ no longer conforms to SUSv3 or POSIX.

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

Works pretty well for Boost.

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

It's a long-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.

Isn't that exactly what I'm trying to achieve?

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

I agree

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

How about Windows?

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

Again, I'm not saying pkg-config is bad.

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

You're encoding it in the path instead, which seems worse.


Reply to: