And we need a constant wchar_t between loader and libstand as ld.bfd checks the
attributes across these when linking.
There are a few options, the simplest is probably to make sys/boot and libstand
all build with 16bit wchar_t, but it would need someone to check on wchar_t
usage in other loader
This seems to break world on ARM due to the size difference CHAR16 vs
ARM wchat_t (currently 32-bit in loader, apparently).
Best,
Conrad
On Thu, Aug 31, 2017 at 10:32 AM, Warner Losh wrote:
> Author: imp
> Date: Thu Aug 31 17:32:14 2017
> New Revision: 323063
> URL: https://svnweb.freebsd.org/ch
Yup. I have those patches in my tree, pending testing after a day or so of
fires at work. They are a hack and I wanted to stop duplicating so much
Makefile code between sys/boot and lib/libstand before I pushed them in. I
think there's no issues with other versions of the loader.
We can also lie a
On Tue, Sep 5, 2017 at 9:33 PM, Warner Losh wrote:
> On Mon, Sep 4, 2017 at 11:51 PM, Jia-Shiun Li wrote:
>
>> Seems to cause armv6 crossbuild to fail.
>> But did armv6 use efi anyway?
>>
>
>
Yea, this is just a command line flag. Will fix. Not sure why x86 doesn't
> suffer from this, but it's a
On Mon, Sep 4, 2017 at 11:51 PM, Jia-Shiun Li wrote:
> Seems to cause armv6 crossbuild to fail.
> But did armv6 use efi anyway?
>
>
> jsli@jsli-e5:/tmp/src # uname -a
> FreeBSD jsli-e5 12.0-CURRENT FreeBSD 12.0-CURRENT #59 r323150: Mon Sep 4
> 11:30:09 CST 2017 jsli@jsli-e5:/usr/obj/usr/src/
Seems to cause armv6 crossbuild to fail.
But did armv6 use efi anyway?
jsli@jsli-e5:/tmp/src # uname -a
FreeBSD jsli-e5 12.0-CURRENT FreeBSD 12.0-CURRENT #59 r323150: Mon Sep 4
11:30:09 CST 2017 jsli@jsli-e5:/usr/obj/usr/src/sys/GENERIC-NODEBUG
amd64
jsli@jsli-e5:/tmp/src # svnversion
323170
