Date: Tue, 22 Jun 2010 17:46:56 +0000 From: "b. f." <bf1783@googlemail.com> To: Janne Snabb <snabb@epipe.com> Cc: freebsd-ports@freebsd.org Subject: Re: mail/thunderbird3 does not build with gcc 4.5.1 Message-ID: <AANLkTim1oQMRe9c2ilImhT9woUgf5hKfQHEVMLiFykHj@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1006221504000.22303@tiktik.epipe.com> References: <AANLkTikhO6G4GIQee4dNZdTwN4pDR3BkKbWVBN2ReiuK@mail.gmail.com> <4C206505.2060601@FreeBSD.org> <AANLkTimGZBtrAC-zg3Y9YzwJn9_eP8Zik_xehQRGDlHt@mail.gmail.com> <alpine.BSF.2.00.1006221504000.22303@tiktik.epipe.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/22/10, Janne Snabb <snabb@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 different ports. > > 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: > > CC > CFLAGS > CXX > CXXFLAGS > CPP > CPPFLAGS > LD > LDFLAGS > AS > AFLAGS > AR > ARFLAGS > RANLIB > INSTALL > OBJCOPY > With the exception of INSTALL, yes. Probably also: ADDR2LINE CXXFILT FC FFLAGS GPROF NM OBJCFLAGS OBJDUMP READELF SIZE STRINGS STRIP 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 builds. > > 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 > ports. 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. b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTim1oQMRe9c2ilImhT9woUgf5hKfQHEVMLiFykHj>