[It may well be that powerpc is not an intended cross compile target via clang
since clang is insufficient for an FreeBSD/powerpc ABI compliant buildworld as
stands. Still I use this to illustrate the more general points for clang use in
cross builds.]
The failure:
> --- libc.so.7.full ---
> /
Mark Millard wrote:
> > .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
> . . .
> > _filemon= filemon
> . . .
>
> Thus, for example, arm variants (32 bit and 64 bit) and powerpc
> variants (32bit and 64 bit) do not have WITH_META_MODE as an option as
> things are set up.
This was my first-time-ever WITH_META_MODE attempt. I show a chunk of the log
later below.
Retrying without WITH_META_MODE=yes resulted in no problems, unlike below.
A self-hosted powerpc64 11.0 -r300944 build using devel/powerpc64-gcc as the
so-called "cross compiler" also did not have this pr
On Sun, May 29, 2016 at 11:05:01PM -0400, Jason Hunt wrote:
> Intermittently after building world/kernel and installing kernel, upon
> reboot I sometimes get stuck at:
>
> >> FreeBSD EFI boot block
>Loader path: /boot/loader.efi
>
>Initializing modules: ZFS UFS
>Probing 35 block devic
Intermittently after building world/kernel and installing kernel, upon
reboot I sometimes get stuck at:
>> FreeBSD EFI boot block
Loader path: /boot/loader.efi
Initializing modules: ZFS UFS
Probing 35 block devices ... done
ZFS found the following pools: zroot
UFS found no partit
On 30/05/2016 12:33 AM, Tim Kientzle wrote:
On May 29, 2016, at 8:55 AM, Julian Elischer wrote:
I was thinking that in order to do this properly the chrooted child should do
all it's fetch requests etc via the non-chrooted parent, but that would have
probably been a bit too complicated. (incl
On 05/29/16 21:05, Michael Butler wrote:
> I was just fooling around with ESX this evening and trying to add an
> NFSv4 mount onto it as extra storage. Curiously, given the correct
> credentials, it will report the total volume size and free remaining but
> won't display either files or subdirector
I was just fooling around with ESX this evening and trying to add an
NFSv4 mount onto it as extra storage. Curiously, given the correct
credentials, it will report the total volume size and free remaining but
won't display either files or subdirectories :-(
In this case, the underlying file-system
ok, so there seem to be more lingering 802.11n issues. can you tell me
mrore about the environment there, so I can try to duplicate it?
I'd like to fix whatever 11n issues there are in iwn!
Thanks!
-a
On 29 May 2016 at 14:27, Ronald Klop wrote:
> On Sun, 29 May 2016 19:59:05 +0200, Adrian Ch
On Sun, May 29, 2016 at 10:41:16PM +, Glen Barber wrote:
> On Sun, May 29, 2016 at 10:35:33PM +, Glen Barber wrote:
> > On Mon, May 30, 2016 at 12:30:05AM +0200, Ben Woods wrote:
> > > Hi everyone,
> > >
> > > I recently reinstalled my FreeBSD laptop using a 11-current snapshot from
> > >
Quoting the original note about WITH_META_MODE (
https://lists.freebsd.org/pipermail/freebsd-current/2016-May/061481.html ):
> You will also need to load the filemon(4) module with 'kldload filemon'.
But head's sys/modules/Makefile says:
> .if defined(MODULES_OVERRIDE) && !defined(ALL_MODULES)
On Sun, May 29, 2016 at 10:35:33PM +, Glen Barber wrote:
> On Mon, May 30, 2016 at 12:30:05AM +0200, Ben Woods wrote:
> > Hi everyone,
> >
> > I recently reinstalled my FreeBSD laptop using a 11-current snapshot from
> > the end of April.
> >
> > Today I noticed that 2 cofiguration files were
On Mon, May 30, 2016 at 12:30:05AM +0200, Ben Woods wrote:
> Hi everyone,
>
> I recently reinstalled my FreeBSD laptop using a 11-current snapshot from
> the end of April.
>
> Today I noticed that 2 cofiguration files were not install in the system:
> /etc/ppp/ppp.conf
> /etc/dma/dma.conf
>
> I
Hi everyone,
I recently reinstalled my FreeBSD laptop using a 11-current snapshot from
the end of April.
Today I noticed that 2 cofiguration files were not install in the system:
/etc/ppp/ppp.conf
/etc/dma/dma.conf
I have done 2 PkgBase upgrades since then (with an etcupdate run also after
each
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FTP mirrors.
As with any development branch, the installation snapshots are not
intended for use on production systems. We do, however, encou
On Sun, 29 May 2016 19:59:05 +0200, Adrian Chadd
wrote:
hi,
Do ifconfig wlan0 -ht (ie, disable 11n)
see if that helps
Hi,
This does make the errors go away and startup more smoothly.
Regards,
Ronald.
-a
On 29 May 2016 at 05:46, Ronald Klop wrote:
Hello,
My laptop has troubles
On Sun, May 29, 2016 at 01:39:07PM +0200, O. Hartmann wrote:
> Recompiled sources with flag -DNO_CLEAN (I mention this because it might have
> impact).
>
> After that, I tried restarting rpcbind via:
>
> root@localhost: [src] service rpcbind restart
> rpcbind not running?
> Starting rpcbind.
> r
hi,
Do ifconfig wlan0 -ht (ie, disable 11n)
see if that helps
-a
On 29 May 2016 at 05:46, Ronald Klop wrote:
> Hello,
>
> My laptop has troubles obtaining an ip address on the wlan0 (if_iwn). The
> interface has trouble staying up during dhcp resolving. Below some
> information from logs. *I
> On May 29, 2016, at 8:55 AM, Julian Elischer wrote:
>
> I was thinking that in order to do this properly the chrooted child should do
> all it's fetch requests etc via the non-chrooted parent, but that would have
> probably been a bit too complicated. (including add requests)
How complex wo
On 23/05/2016 4:32 AM, b...@freebsd.org wrote:
On Sun, May 22, 2016 at 10:31:08PM +0200, b...@freebsd.org wrote:
On Sun, May 22, 2016 at 01:24:12PM -0700, Tim Kientzle wrote:
Crochet has some experimental hooks to install packages onto the system being
built, but this seems to be hitting probl
Hello,
My laptop has troubles obtaining an ip address on the wlan0 (if_iwn). The
interface has trouble staying up during dhcp resolving. Below some
information from logs. *If* it obtains an IP address it seems quite stable
afterwards.
Before https://svnweb.freebsd.org/base?view=revision&rev
FreeBSD_HEAD_amd64_gcc - Build #1268 - Fixed:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1268/
Full change log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1268/changes
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1268/console
Am Sun, 29 May 2016 03:00:56 -0700
"Ngie Cooper (yaneurabeya)" schrieb:
> > On May 29, 2016, at 00:32, O. Hartmann wrote:
> >
> > After updating sources and build- and installworld, I realize that all
> > rpcbind related
> > services, so far NFS, are not working. On a client I check the start
I have a Fortran application that has built forever on FreeBSD-current;
that is, until recently. It now dies with the following error:
gfortran48 -O2 -pipe -march=native -mtune=native -static -funroll-loops \
--param max-unroll-times=4 -ftree-vectorize -Wall\
-rpath /usr/local/lib/gcc48 -I/ho
Am Sun, 29 May 2016 03:00:56 -0700
"Ngie Cooper (yaneurabeya)" schrieb:
> > On May 29, 2016, at 00:32, O. Hartmann wrote:
> >
> > After updating sources and build- and installworld, I realize that all
> > rpcbind related
> > services, so far NFS, are not working. On a client I check the start
> On May 29, 2016, at 00:32, O. Hartmann wrote:
>
> After updating sources and build- and installworld, I realize that all
> rpcbind related
> services, so far NFS, are not working. On a client I check the start of
> rpcbind by
> setting option -d and receive the output shown below.
>
> Well,
Hi,
The port games/0ad which I maintain crashes during compilation on i386
with clang. It says an assertion failed:
Assertion failed: (Subtarget->hasSSE2() && "Requires at least SSE2!"),
function ReplaceNodeResults, file
/poudriere/jails/11i386/usr/src/lib/clang/libllvmx86codegen/../../../contrib
After updating sources and build- and installworld, I realize that all rpcbind
related
services, so far NFS, are not working. On a client I check the start of rpcbind
by
setting option -d and receive the output shown below.
Well, prior to r300949 rpcbind started without complains - as it did wit
Am Sat, 28 May 2016 17:27:29 -0600
Alan Somers schrieb:
> On Sat, May 28, 2016 at 4:26 PM, Bryan Drewery wrote:
> > On 5/28/16 3:07 PM, O. Hartmann wrote:
> >> CXXFLAGS+= -std=c++11
> >>
> >>
> >> As it has been earlier stated, there is no -std=c++11 visible in the cc
> >> option
On 28 May 2016 at 14:30, Mark Millard wrote:
> On 2016-May-28, at 12:03 PM, Adrian Chadd wrote:
>
>> [snip]
>>
>> hi,
>>
>> please don't patch the ports compiler assumptions about things like
>> this. We should be targeting external toolchains on OSes (eg macosx)
>> where it may already generate
On 5/28/2016 12:03 PM, Adrian Chadd wrote:
> [snip]
I beg of you to *stop* snipping all context.
>
> hi,
>
> please don't patch the ports compiler assumptions about things like
I said it was not right, and was an experiment.
> this. We should be targeting external toolchains on OSes (eg macos
> On May 28, 2016, at 17:31, Shawn Webb wrote:
…
> No worries. No rush here. I appreciate the help! Can you add “Reported by:
> HardenedBSD” to the commit log?
Fixed in r300922 — thanks!
-Ngie
signature.asc
Description: Message signed with OpenPGP using GPGMail
32 matches
Mail list logo
