mips misbehaving, not respecting make.conf

Garrett Cooper yaneurabeya at gmail.com
Mon Nov 17 12:27:32 UTC 2014


On Nov 16, 2014, at 16:01, Warner Losh <imp at bsdimp.com> wrote:

> On Nov 16, 2014, at 4:36 PM, Garrett Cooper <yaneurabeya at gmail.com> wrote:
> 
>> On Nov 16, 2014, at 15:15, Sean Bruno <sbruno at ignoranthack.me> wrote:
>> 
>>> I have set make.conf to use AS=/nxb-bin/usr/bin/as and
>>> CC=/nxb-bin/usr/bin/cc
>>> 
>>> Yet, while monitoring, I still see the ports build process
>>> using /usr/bin/as and /usr/bin/ld and /usr/libexec/cc1
>>> 
>>> I don't see this on armv6 when building in a jail + qemu.
>>> 
>>> I'm trying to understand what is missing from our gcc toolchain here
>>> that is causing the builds to ignore my directives.
>> 
>> It all kinds of boils down to this bug with the configuration of our base system copy of gcc: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192394 .
> 
> I’ve never seen this happen in the decade or so I’ve been doing cross builds. I’ve seen gcc breakage, but always from stupid C or C++ tricks, not from how we have things setup.

There are a lot of nifty features in the binutils/gcc configuration that we don’t tweak, for better or for worse. -sysroot is one item (that I brought up before), but it’s not Sean’s problem. Still, it needs to be fixed because we still ship gcc today on the tier-2/-3 platforms and I’ve hit bugs in the past where it picks up the wrong headers with gcc, but not clang.

>> The prefixing/sysroot isn’t being setup properly, which means that you have to use $PATH to tell gcc and friends which tool you want to use (which make buildworld, etc does). One way to fix this (if we used autoconf in the base system build) would be to reconfigure it with a particular sysroot:
>> 
>> $ ./configure --help | grep -A 3 sysroot
>> --with-build-sysroot=sysroot
>>                         use sysroot as the system root during the build
>> --with-sysroot=DIR Search for usr/lib, usr/include, et al, within DIR.
>> --with-gnu-ld           assume the C compiler uses GNU ld default=no
>> --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
>> --without-libiconv-prefix     don't search for libiconv in includedir and libdir
>> $ svn info configure | grep ^URL:
>> URL: svn+ssh://ngie@svn.freebsd.org/base/head/contrib/gcc/configure
> 
> The native-xtools builds should be setup to use the right binaries. I don’t think this is sean’s problem.

Correct (as I noted in my later reply). The thing is that we override PREFIX with binutils/gcc and there aren’t really any blatant comments in the source code pointing out why things are being done that way. You have to use svn blame and svn log to find the right commit that describes the feature.

Cheers!

------------------------------------------------------------------------
r55220 | obrien | 1999-12-29 06:42:46 -0800 (Wed, 29 Dec 1999) | 6 lines

Allow the specification of a prefix for gcc to find all the various bits.
If one wishes to anchor the compiler toolchain tree somewhere other than /,
all one needs to do is set "TOOLS_PREFIX" to a different rooting.

Submitted by:   marcel (in a different format and reworked by me)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20141117/fbbb8005/attachment.sig>


More information about the freebsd-arch mailing list