Compiling ports in a post-9.0-RELEASE world
matthias.andree at gmx.de
Thu Mar 17 17:33:12 UTC 2011
Am 17.03.2011 14:07, schrieb Konstantin Tokarev:
> 17.03.2011, 15:39, "Konstantin Tokarev"<annulen at yandex.ru>:
>> 16.03.2011, 11:33, "Alberto Villa"<avilla at freebsd.org>;:
>>> On Wednesday 16 March 2011 09:15:07 Konstantin Tokarev wrote:
>>>> From http://clang.llvm.org/docs/LanguageExtensions.html
>>>> "In addition to the language extensions listed here, Clang aims to
>>>> a broad range of GCC extensions."
>>>> So GCC extensions may also be considered as missing features.
>>> gcc-isms also means "bad code which is nonetheless supported by gcc"
>> In this case don't hesitate to file a bug against gcc :)
Not necessarily. If it's a documented extension that you'd allowed (and
even by sticking to the implicit gnu89 language default of GCC) then
you'll hardly hear back anything else than "invalid, works as documented".
> Let me elaborate my idea a bit.
> One may think that reporting bugs on GCC he supports development of
> technology that FreeBSD does not endorse . I don't think so.
> 1) Latest versions of GCC are more standard-compliant than earlier ones,
> and bad written code tends to produce compilation errors with newer GCC.
> For example, I've seen lots of legacy code written for GCC 3.x but failing
> to compile with 4.x. 4.x branch is also being improved.
This is based on the implicit assumption that the code were to be
compiled with -std=c99 -pedantic-errors [-Wall] or similar. The
majority of upstream packages doesn't follow such a purity paradigm, but
knowingly or unbeknownst use -std=gnu89, and often GNU libc, extensions.
Documented extensions have NOT USUALLY gone away in newer GCC minor
> 3) Projects with dead upstreams should be excluded from ports collection
> someday, unless maintainers are willing to do "upstream" job. Folks using
That's a separate discussion under the "deprecation campaign" subject.
Please discuss that there.
More information about the freebsd-ports