similar to: [supermin PATCH] Add stdarg.h to fix issues with va_start.

https://bugzilla.mindrot.org/show_bug.cgi?id=2456 Bug ID: 2456 Summary: gssapi-keyex blocked by PermitRootLogin=without-password Product: Portable OpenSSH Version: 7.1p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component: sshd

This takes a list of package names, adding them to the image without pulling any dependencies. Only implemented for Debian at the moment. zypper wasn't build-tested because I don't have the dependency. --- src/.depend | 2 +- src/supermin.ml | 6 +++--- src/supermin_cmdline.ml | 13 ++++++++++--- src/supermin_cmdline.mli | 10

Hello, I have some jails running on ZFS, so I have to mount devfs's into them. For this purpose, I have some similar lines in /etc/fstab: devfs /pool/jail/ldap/dev devfs rw 0 0 Where /pool is a ZFS filesystem. This has worked until today -when I upgraded from a previous 7-STABLE (FreeBSD 7.0-STABLE #16: Fri Mar 7 14:30:08 CET 2008) to today's STABLE- but not

https://bugzilla.mindrot.org/show_bug.cgi?id=1615 Summary: the pathname length of home directory is limited to less than 256 chars Product: Portable OpenSSH Version: 5.2p1 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo:

Hello, if compiling the driver for my ralink wlan card or compiling the driver for my 5-1 card reader, I get the following error message. ./include/linux/kernel.h:10:20: error: stdarg.h: No such file or directory Is there something broken on my system? # rpm -qa | grep kernel kernel-devel-2.6.18-53.1.14.el5 kernel-headers-2.6.18-53.1.14.el5 kernel-2.6.18-53.1.14.el5 # uname -a Linux hobbingen

Hi, building current git fails with gcc -std=gnu99 -std=gnu99 -I.. -I/usr/lib/ocaml -I../ocaml -I../src -I../src -g -O2 -fPIC -Wall -c guestfs_c_actions.c In file included from ../src/guestfs.h:84, from guestfs_c_actions.c:35: ../src/guestfs-actions.h:28: error: expected declaration specifiers or '...' before 'va_list' This is fixed by an #include

Hi, When I try to use va_start(ptr), I got the following problem : Type *Tys = PointerType::get(IntegerType::get(8), 0); return Intrinsic::getDeclaration(llvm_module,Intrinsic::vastart,&Tys,1); ............... The Name generated is "llvm.va_start.p0i8", so, it's not found, abending the process. and Len = 18 In intrinsics.gen : if (Len == 13 && !memcmp(Name,

Hi, When I try to use va_start(ptr), I got the following problem : Type *Tys = Type::VoidTy; Or Type *Tys = PointerType::get(IntegerType::get(8), 0); return Intrinsic::getDeclaration(llvm_module,Intrinsic::vastart,&Tys,1); ............... The Name generated is "llvm.va_start.p0i8", so, it's not found, abending the process. and Len = 18 In intrinsics.gen : if (Len == 13

https://bugzilla.mindrot.org/show_bug.cgi?id=2410 Bug ID: 2410 Summary: auth-chall.c - "<stdarg.h>" #included twice Product: Portable OpenSSH Version: 6.8p1 Hardware: Other OS: Other Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous

Having an absolute path in a #include confuses distcc''s pump mode. Since AFAICS OpenBSD''s stdarg handling uses the builtins, I think we should just treat it like we do NetBSD. I don''t have an OpenBSD box to test on, though. :( Any OpenBSD enthusiasts care to comment? Tim. diff --git a/xen/include/xen/stdarg.h b/xen/include/xen/stdarg.h index 57e2c0e..cb870ac 100644

Hi, The problem is resolved. I try the svn trunk, llc work fine to generate the MIPS assembly. Also, I try both llvm-gcc and clang, they work fine at my current project, though I will use clang to instead of llvm-gcc. Thanks, everyone. Regards, Leo 2011/8/16 Akira Hatanaka <ahatanak at gmail.com>: > You might want to use clang instead of llvm-gcc: I think there are > still bugs

On Mon, Aug 15, 2011 at 2:18 AM, Leo Chen. <leo.q.chen at gmail.com> wrote: > Hi, > > I am using llc (llvm 2.9) to generate the MIPS assembly I would suggest trying trunk; there have been a lot of improvements recently to the MIPS backend. -Eli > but failed > when compile any codes > with va_start()/va_end()/va_arg(). > > Here is the minimal step to reproduce the

Hi all, I think there is a typo in TargetLowering.cpp where Names[RTLIB::SYNC_FETCH_AND_XOR_4] = "__sync_fetch_and-xor_4"; is given, and it looks like it should be "__sync_fetch_and_xor_4"; This was added here: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/TargetLowering.cpp?view=diff&r1=106320&r2=106321

Hi, I am using llc (llvm 2.9) to generate the MIPS assembly, but failed when compile any codes with va_start()/va_end()/va_arg(). Here is the minimal step to reproduce the failure: llvm-gcc-4.2 -emit-llvm hello.c -c -o hello.bc llc -march=mips hello.bc -o hello.s llc show this erroe message: LLVM ERROR: Cannot select: 0xa1873a0: ch = vaend 0xa187290:1, 0xa185ae0, 0xa187318 [ID=38] 0xa185ae0:

On Aug 15, 2011, at 9:42 AM, Eli Friedman wrote: > On Mon, Aug 15, 2011 at 2:18 AM, Leo Chen. <leo.q.chen at gmail.com> wrote: >> Hi, >> >> I am using llc (llvm 2.9) to generate the MIPS assembly > > I would suggest trying trunk; there have been a lot of improvements > recently to the MIPS backend. > I agree. Also, make sure you're using a MIPS

Hi, I think there are a set of typos in the ATOMIC_LOAD_UMIN_I* and ATOMIC_LOAD_UMAX_I* pseudo-instructions . Specifically, def ATOMIC_LOAD_MIN_I32 : PseudoInst< (outs GPR:$dst), (ins GPR:$ptr, GPR:$val), NoItinerary, [(set GPR:$dst, (atomic_load_min_32 GPR:$ptr, GPR:$val))]>; and def ATOMIC_LOAD_UMIN_I32 : PseudoInst< (outs

Wayne, i like the diff -u idea. I find -c awkward. It seems to me that the shell script could test for support of -u and if present use it instead of -c. ala if [ -n "`diff -u /dev/null /dev/null 2>&1`" ] then difftype="-c" else difftype="-u" fi diff $difftype "$2"/"$f" "$3"/"$f" || failed=YES or something

I'm unsure why this is failing this week, but when I build for FreeBSD HEAD, I now get a failure to find <stdarg.h>. Very strange. Maybe its missing a -I /usr/include somewhere? [1950/2811] Building CXX object projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_interceptors.cc.o FAILED: /usr/bin/CC -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS

Thanks. Fixed with r147032. Evan On Dec 16, 2011, at 1:50 AM, George Russell wrote: > Hi, > > I think there are a set of typos in the ATOMIC_LOAD_UMIN_I* and > ATOMIC_LOAD_UMAX_I* > pseudo-instructions . > > Specifically, > > def ATOMIC_LOAD_MIN_I32 : PseudoInst< > (outs GPR:$dst), (ins GPR:$ptr, GPR:$val), NoItinerary, >

Hi Evan, The problem repeats with the i8 and i16 variants, as well. Cheers, George On 21/12/2011 04:07, Evan Cheng wrote: > Thanks. Fixed with r147032. > > Evan > > On Dec 16, 2011, at 1:50 AM, George Russell wrote: > >> Hi, >> >> I think there are a set of typos in the ATOMIC_LOAD_UMIN_I* and >> ATOMIC_LOAD_UMAX_I* >> pseudo-instructions .