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.
Olaf
Reply to: