mail/thunderbird3 does not build with gcc 4.5.1
bf1783 at googlemail.com
Tue Jun 22 17:47:00 UTC 2010
On 6/22/10, Janne Snabb <snabb at epipe.com> wrote:
> On Tue, 22 Jun 2010, b. f. wrote:
>> I can tell you right now from my own experiences that the ports
>> infrastructure and many individual ports do not respect the necessary
>> compiler and toolchain-related variables.
I should say that a few simple changes in the infrastructure makefiles
are sufficient to solve many, but not all problems. I doubt we will
make the ports tree completely compiler/toolchain (C/T)-agnostic in
the near future -- that would probably require more time and effort
than the committers are willing to invest -- but it seems desirable to
try to support at least (1) clang+BSD-licensed ELF toolchain and (2)
the latest stable release of gcc+GNU binutils. One outstanding
question is how to handle the C/T and their dependencies. In future
releases it seems likely that (1) will be in the base system. But
what about the use of (1) with older, but still supported releases?
And what about (2)? If the C/Ts aren't in the base system, then the
present USE_GCC arrangement must be modified so that important
dependencies of the C/Ts, like perl, may themselves be built with the
C/Ts without introducing circular dependencies. Also, will the use of
different C/Ts for the base system and for ports be supported? Or the
use of different C/Ts for different ports? That seems desirable, but
it makes life more difficult for ports committers. For example, the
current USE_GCC arrangement is problematic, because even with special
LDFLAGS, there are problems with the new gcc libraries from ports
interposing on the old base system gcc libraries, and vice versa. And
various build utilities like libtool, cmake, and qmake sometimes use
hard-coded defaults based upon the C/T that is used to built them,
causing problems for those who want to use different C/Ts for
> Part of this problem is that the Porters Handbook only tells porters
> to respect CC, CXX and CFLAGS, nothing else.
> This issue came up as well in the "Building ports with stack-protector"
> thread a couple of weeks ago (by yourself).
> What would be the comprehensive list of variables to respect?
> There are already quite many from the top of my head:
With the exception of INSTALL, yes. Probably also:
Some of these are obviously less important than others, because they
are used by a smaller number of ports, or in special targets like
regression tests, or are less susceptible to problems when mixing
C/Ts, but we should probably ensure consistent use of utilities from
only one C/T for a given port, or perhaps even for all ports.
> Some of the above would generally be required to be respected only
> when cross-compiling to an another architecture.
There are already examples of how mixing utilities from the older base
system and newer ports gcc/binutils causes problems even with regular
> I have been thinking of making a test build of all ports with some
> useless options in relevant variables and capturing output or doing
> ktrace to figure out which ports respect those flags and which do
> not. Haven't gotten around to actually doing it just yet :).
Some scripts to detect these problems would be useful additions to ports/Tools.
> Another work-around would be to make a directory containing
> wrapper-shell-scripts with the names like cc, gcc, ld, cpp etc.
> and make them invoke the desired tools with desired flags. That
> directory would be placed in the beginning of PATH before compiling
> ports. This would be a quicker alternative to patching lots of
Perhaps. We'd obviously have to act to prevent environment variables
or auto-detection from overriding these, too -- but such an approach
may save some work.
More information about the freebsd-ports