On 2017-Jun-16, at 7:48 PM, Konstantin Belousov wrote:
> On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote:
>> . . .
>
> UFS uses 32bit inodes, changing to 64bit is both pointless currently, and
> causes on-disk layout incompatibilities.
>
> As a consequence, use of ino_t (64bit) or
On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote:
> buildworld via clang for powerpc64 and powerpc fails for lack of
> `__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size
> code. But this lead to me looking around and I found a conceptually
> separate possible issue. . .
>
Top post of context note:
I should have noted up front that:
/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c
does:
#include "ufsread.c"
and that is the context of the __udivdi3
use that is rejected at link time when
clang is used to buildworld for powerpc
or pwoerpc64.
My original note might
buildworld via clang for powerpc64 and powerpc fails for lack of
`__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size
code. But this lead to me looking around and I found a conceptually
separate possible issue. . .
sys/sys/_types.h :
typedef __uint64_t __ino_t;/* inode
[Top posted note: I have submitted bugzilla 220024 for this
powerpc64 and powerpc issue. It has also been reproduced
when using /usr/local/powerpc64-freebsd/bin/ for binutils
for a powerpc64 buildworld attempt.]
On 2017-Jun-15, at 11:32 PM, Mark Millard wrote:
[powerpc64 has the same problem.]
I grabbed a spare USB 2 TB hard drive yesterday. Put a GPT
scheme on the drive and then used newfs to create 1 large
UFS2 partition with softupdates and with journalling enabled.
I then some 150 GB of data to drive. The drive in question is
ugen0.3: at usbus0
umass0 on uhub8
umass0: on usbus0
Hi
Following this thread
https://lists.freebsd.org/pipermail/freebsd-ports/2015-June/099398.html
it seems someone (Tom?) was working on a port for libchromiumcontent.
Whatever happened to this effort?
libchromiumcontent is required for Electron which is required for Atom.
I would love to use
