Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Oct 2014 00:18:52 +0200
From:      Jeroen Hofstee <jeroen@myspectrum.nl>
To:        Warner Losh <imp@bsdimp.com>, Jeroen Hofstee <jeroen@myspectrum.nl>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: make xdev-links
Message-ID:  <544438CC.2040607@myspectrum.nl>
In-Reply-To: <B4573F69-6A83-4FB1-82EF-DF509DFA6562@bsdimp.com>
References:  <54438864.2050506@myspectrum.nl> <B4573F69-6A83-4FB1-82EF-DF509DFA6562@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello Warner,

On 19-10-14 22:03, Warner Losh wrote:
> On Oct 19, 2014, at 3:46 AM, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>
>> Hi,
>>
>> I noticed that the xdev target no longer installs the long names, but it needs
>> the xdev-links target for that purpose. However if you try to use that compiler you get:
>>
>> armv6-freebsd-cc main.c
>> ERROR: Source object /tmp/main-2cb9c8.o has EABI version 0, but target a.out has EABI version 4
> that’s weird. Looks like you tried to build in a stale tree, or with the wrong binaries
> since one of them is old ABI while the other one is new EABI 4 that we implement.

I don't understand what you mean by that, I build

commit 12cfd5c5b7dc8bca093c3db614f93a61d02aa127
Author: rpaulo <rpaulo@FreeBSD.org>
Date:   Sat Oct 18 17:00:55 2014 +0000

     Make the ti_mbox and ti_pruss drivers optional.

     MFC after:  1 week

with
make XDEV=arm XDEV_ARCH=armv6 xdev
make XDEV=arm XDEV_ARCH=armv6 xdev-links

resulting in

FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: armv6--freebsd
Thread model: posix

So I am not behind (too much) if that is what you meant.

>> If the symlinks are renamed to armv6-freebsd-gnuebi-* compiling works fine.
>> Should such a rename be considered?
> The links aren’t causing that error. They won’t be renamed. If there’s a real bug here,
> it needs to be fixed elsewhere.

I don't know the root cause, but clang e.g. will behave differently
depending on the name it is invoked with. So perhaps that logic needs
to be extended then.

>> Unrelated, since crochet wants to be run as root, I noticed u-boot will stop
>> compiling, since the root shell has VENDOR set to amd, overwriting the actual
>> board VENDOR in the Makefiles.
> That’s odd. It shouldn’t be doing that. Any idea where that’s coming from?

No idea, I do know 2 more people reported the same problem in the
u-boot mailinglist before, so it is not limited to my setup. I just didn't
encounter it before, since I typically don't build u-boot as root.

Regards,
Jeroen



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?544438CC.2040607>