Re: Problem compiling rust

2018-04-19 Thread Bryan Drewery
On 4/17/18 10:25 AM, Filippo Moretti wrote:
> I have the folloing error while compiling rust on i386 current of April the 
> 9th

It looks like the normal bootstrap bug with the ino64 changes but is
fine on my amd64 system. Perhaps I missed something for i386 support.
Are you able to build lang/rust-nightly?


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature


Re: /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:5:1: error: expected unqualified-id

2018-04-19 Thread Dimitry Andric
On 19 Apr 2018, at 06:48, KIRIYAMA Kazuhiko  wrote:
> 
> r332743 make builworld failed:
> 
> c++  -O2 -pipe 
> -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang 
> -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
> -I/usr/src/contrib/llvm/tools/clang/lib/Basic 
> -I/usr/src/contrib/llvm/tools/clang/lib/Driver 
> -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include 
> -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL 
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS 
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -ffunction-sections 
> -fdata-sections -gline-tables-only -MD 
> -MF.depend.Frontend_SerializedDiagnosticReader.o 
> -MTFrontend/SerializedDiagnosticReader.o -Qunused-arguments 
> -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -std=c++11 
> -fno-exceptions -fno-rtti -gline-tables-only -stdlib=libc++ 
> -Wno-c++11-extensions  -c 
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp 
> -o Frontend/Se!
> rializedDiagnosticReader.o
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:5:1:
>  error: expected unqualified-id
> /7 This fi!is dW0<8B>ibut[d<8C>nder ,<9C> 
> University of IllinEV<90>Open Source
> ^
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:5:13:
>  error: source file is not valid UTF-8
> /7 This fi!is dW0<8B>ibut[d<8C>nder ,<9C> 
> University of IllinEV<90>Open Source
>   ^
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:5:21:
>  error: source file is not valid UTF-8
> /7 This fi!is dW0<8B>ibut[d<8C>nder ,<9C> 
> University of IllinEV<90>Open Source
> ^
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:5:29:
>  error: source file is not valid UTF-8
> /7 This fi!is dW0<8B>ibut[d<8C>nder ,<9C> 
> University of IllinEV<90>Open Source
>   ^
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:5:37:
>  error: source file is not valid UTF-8
> /7 This fi!is dW0<8B>ibut[d<8C>nder ,<9C> 
> University of IllinEV<90>Open Source
> ^
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:5:60:
>  error: source file is not valid UTF-8
> /7 This fi!is dW0<8B>ibut[d<8C>nder ,<9C> 
> University of IllinEV<90>Open Source
>   
> ^
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:5:61:
>  error: source file is not valid UTF-8
> /7 This fi!is dW0<8B>ibut[d<8C>nder ,<9C> 
> University of IllinEV<90>Open Source
>   
> ^
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/SerializedDiagnosticReader.cpp:10:10:
>  fatal error: 'qlang/Frontend/SerializeNagnosticReader(h' file not found
> #include "qlang/Frontend/SerializeN<87>oagnosticReader(h"
> ^~~~

It definitely looks like your source files are corrupted, as this is
certainly not the normal contents.  Please check your RAM and storage
for errors.  If there are no errors, try deleting the source tree, and
obtaining a fresh checkout.

-Dimitry



signature.asc
Description: Message signed with OpenPGP


suspend/resume does not work in qemu (qemu-devel)

2018-04-19 Thread Andriy Gapon

Not sure if this really matters and on what end the problem might be, but
resuming from S3 in qemu is stuck forever here:

#3  x86emu_exec_one_byte (emu=0x81eac618 ) at
/usr/devel/git/cpu-pause/sys/contrib/x86emu/x86emu.c:4655
#4  0x8106c398 in x86emu_exec (emu=0x81eac618 ) at
/usr/devel/git/cpu-pause/sys/contrib/x86emu/x86emu.c:246
#5  0x8106b8d4 in x86bios_intr (regs=0xfe002e1933f0, intno=16) at
/usr/devel/git/cpu-pause/sys/compat/x86bios/x86bios.c:634
#6  0x80fb7cd2 in vesa_bios_save_restore (code=2, p=0xf8000365e004)
at /usr/devel/git/cpu-pause/sys/dev/fb/vesa.c:551
#7  vesa_load_state (adp=, p=) at
/usr/devel/git/cpu-pause/sys/dev/fb/vesa.c:1535
#8  0x810632e0 in vga_resume (dev=0xf800039eb100) at
/usr/devel/git/cpu-pause/sys/isa/vga_isa.c:112
#9  0x8106311e in isavga_resume (dev=0xf800039eb100) at
/usr/devel/git/cpu-pause/sys/isa/vga_isa.c:243
#10 0x80ac2de4 in DEVICE_RESUME (dev=) at 
./device_if.h:305
...

Using -vga none works around the problem, of course.
Maybe it's buggy video BIOS in the emulation.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"