svn commit: r335888 - in head: contrib/blacklist/bin lib/libpjdlog sbin/hastd

[Mark Millard]

Eitan Adler lists at eitanadler.com wrote on
Thu Jul 5 00:56:02 UTC 2018 :

> On Tue, 3 Jul 2018 at 08:22, John Baldwin <jhb at freebsd.org
> > wrote:
> > since GCC usually breaks
> > them.
> 
> 
> Could you explain what you mean or point to a prior conversation?

I'll take a stab at it without giving much for specific code examples.
I do not claim the wording gives complete coverage but it should
suggest some types of problems to expect.

A) Gcc considers various FreeBSD definitions wrong by their criteria
and attempts to override them. (That is what the Gcc "include-fixed"
headers are for relative to FreeBSD. The issue is not unique to
FreeBSD.)

B) FreeBSD considers various Gcc definitions wrong by its criteria
and attempts to override them. (FreeBSD, being an OS, would normally
have the larger set of definitions overall. For example Gcc likely
would not consider FreeBSD's _STANDALONE distinctions for max_align_t,
say. [I've not checked the details. Only illustrative of a potential
example.])

The mixing of code with (A) and (B) tends to be problematical. One
way is that if the details for Gcc or FreeBSD change, things tend to
end up mis-matched (at least until both sides adjust) even if they
were working together correctly before. But even without that there
are frequently problems with various details as they have been.

Part of the overall issue is that FredBSD targets multiple standards,
not just language standards, and various standards are not in full
agreement. Gcc does not necessarily target the same set of standards
or have the same selections for dealing with potential conflicts for
what it does target.

There are also issues of file conflicts, such as the area with float.h
(from C) for Gcc also having altivec.h (not from C) and FreeBSD having
its own file of the name --and the system-clang compiler source also having
one. The 3 altivec.h files serve different purposes and are not alternatives
for each other, despite the common name. Having Gcc (as a cross compiler)
build system-clang with __ALTIVEC__ defined and picking out clang's
altivec.h would be painful. (Currently targeting powerpc64 that way does
not build system-clang with __ALTIVEC__ defined. The lack avoids the
file issue but does not cover altivec correctly in the built clang.)

(A) has been a difficult area for a long time and sometime back a ways
was finally disabled in various Gcc ports. Even without (A), there are
issues like the altivec.h issue that can end up involved.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)