similar to: Install locks up my server

On 06/26/17 14:42, Timo Sirainen wrote: > On 26 Jun 2017, at 23.19, Marc Perkel <marc at perkel.com> wrote: >> Ever since 2.26 I haven't been able to upgrade. In fact the install locks up my server. >> >> I get into and infinite recursive loop where the config-guess program calls itself until the server locks up from overload. >> >> I'm running Centos

This is still broken in the 2.2.32 release candidate. config.guess forks copies till the server dies. Running Centos 6.6 under OpenVZ. On 06/26/17 16:03, Marc Perkel wrote: > > > On 06/26/17 14:42, Timo Sirainen wrote: >> On 26 Jun 2017, at 23.19, Marc Perkel <marc at perkel.com> wrote: >>> Ever since 2.26 I haven't been able to upgrade. In fact the install

This is still broken in the 2.2.32. config.guess forks copies till the server dies. Running Centos 6.6 under OpenVZ. On 06/26/17 16:03, Marc Perkel wrote: > > > On 06/26/17 14:42, Timo Sirainen wrote: >> On 26 Jun 2017, at 23.19, Marc Perkel <marc at perkel.com> wrote: >>> Ever since 2.26 I haven't been able to upgrade. In fact the install >>> locks up

On Fri, Apr 08, 2011 at 08:28:27AM +0200, Duncan Sands wrote: > Hi Jack, > > > The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn > > (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the > > build fails as... > > what does the command > ./TargetInfo -p > return (the TargetInfo program

Hi Jack, > The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn > (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the > build fails as... what does the command ./TargetInfo -p return (the TargetInfo program is created during the dragonegg build). Some of your errors are consistent with this program failing to run.

Hello, would it be possible to update config.sub and config.guess to the latest versions (or at least version from automake-1.13.1) in order to support new architectures based on the ARM 64 bit CPU? Patch: http://plautrba.fedorapeople.org/openssh/openssh-latest-config.sub-config.guess.patch Related Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=926284 Thanks, Petr

The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the build fails as... GCC=/sw/lib/gcc4.5/bin/gcc-4 LLVM_CONFIG=/sw/bin/llvm-config make CPPFLAGS="-DENABLE_LTO -I/sw/include" Compiling utils/TargetInfo.cpp <command-line>: warning: "__STDC_LIMIT_MACROS"

Hi together, this is the second version of my cross-compilation patch serie. I'm sending it in the hope to get an honest review, and possibly see the patches integrated upstream. Those patches allow to build syslinux using a toolchain different from the host one by explicitely using the host toolchain for the utilities that are required at build-time / on the build machine. I am using the

Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Matt Wilson <msw@amazon.com> --- Makefile | 2 +- Makefile.target | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 37c7066..594f0ef 100644 --- a/Makefile +++ b/Makefile @@ -243,7 +243,7 @@ endif install: all $(if $(BUILD_DOCS),install-doc) mkdir -p

some files depend on nodes.h, but there is no dependency for that fact. olaf@mandarine:~/klibc-0.87> grep -Er 'include.*nodes.h' ash/ | sed 's-^[^/]\+/\([^.]*\).*-\1.o-' | xargs echo OBJ_NODES = OBJ_NODES = cd.o eval.o exec.o expand.o jobs.o main.o nodes.o options.o parser.o redir.o show.o trap.o var.o make spotless doesnt work reliable, the patch adds a few more targets. Is

Hello, running 0.99.10.6 (but seen it before that, too). Also (quite obviously) running 5 auth processes, given the fact that this is a pretty busy box and I didn't want to introduce any artificial bottlenecks. Alas with them eating up half of the free memory (which would go to a much better use as FS cache) I'm getting sorta concerned. If it's not a leak, it's caching something

Hi All, I recently ran into an issue that was posted several years back on LLVMdev [1]. A brief recap of the problem is that when cross-compiling LLVM itself the configure/make scripts get confused when creating the needed build host tools. For example, building and configuring like: CC_FOR_BUILD='i686-pc-linux-gnu-gcc' CXX_FOR_BUILD='i686-pc-linux-gnu-g++'

In case a repository of virt-builder references files (e.g. the index) that cannot be downloaded (network issues, 404, etc) then virt-builder errors out on this situation. This is not a nice situation, from an user POV. This series does some refactoring to allow to better handle downloading failures, and handle the failures gracefully in virt-builder. RFC because I'm not yet too convinced

Gentlepersons: A long time ago I used to be able to start R (version 2.6.1) from a Delphi 7 program and run a script by using a procedure like the following: function StartRAndWait (CommandLine : string) : Boolean; var Proc_info: TProcessInformation; Startinfo: TStartupInfo; ExitCode: longword; CreateOK : Boolean; begin Result := False; { Initialize the structures }

On Fri, Apr 08, 2011 at 07:37:39AM -0400, Jack Howarth wrote: > On Fri, Apr 08, 2011 at 08:28:27AM +0200, Duncan Sands wrote: > > Hi Jack, > > > > > The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn > > > (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the > > > build fails as...

Hello all Was wondering if someone could help or advise where i''m going wrong i''m trying to install Windows 2008 R2 Remote Desktop Services via Puppet using either DISM or Powershell modules from the forge and getting the same error When using DISM class roles::trm::remote_desktop_services { dism { ''AppServer'': ensure => present, } dism {

> + > +/* The exitcode is in native SVM/VMX format. The forced exitcode > + * is in generic format. > + */ Introducing a 3rd format of exitcode is over-complicated IMO. > +enum nestedhvm_vmexits > +nestedhvm_vcpu_vmexit(struct vcpu *v, struct cpu_user_regs *regs, > + uint64_t exitcode) > +{ I doubt about the necessary of this kind of wrapper. In single layer

Hi, A feature I've wanted in lit for a while is a having a timeout per test. Attached are patches that implement this idea. I'm e-mailing llvm-dev rather than llvm-commits because I want to gather more feedback on my initial implementation and hopefully some answers to some unresolved issues with my implementation. Currently in lit you can set a global timeout for all of the tests but

Hi, I'm experimenting with using LLVM to generate dynamic FFI bridges in VisualWorks Smalltalk. LLVM is an amazing thing! I'm going from dynamically generated assembler source to machine code, and I have that all working, copied from the llc tool and the JIT example. I have two questions: 1. What optimization passes, if any, should I run on the module before I pass it to the

When we are valgrinding we don't really care about the child processes, which might be qemu, libvirtd, etc. So disable tracing into children (at least, as far as is possible with valgrind, which is not entirely disabling it, but suppressing it). --- m4/guestfs_progs.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/guestfs_progs.m4 b/m4/guestfs_progs.m4 index