similar to: extlinux VPATH build issue

I have put a compile hack in for older distros and pushed it out as syslinux-3.62-pre16; for those who have reported compilation problem on older distros I would greatly appreciate if you could confirm if it works now (it worked for me on a CentOS 3.9 VM.) -hpa

Hello, c/s 17138 introduced the use of VPATH instead of symlinks to access to libelf files. However, that not only provides access to .c files, but also to .o files. That means that if one compiles the hypervisor before the tools, libxenguest.a contains .o files intended to the hypervisor, containing references to printk, etc. and thus is unusable. Is there a good reason against reverting to

I am trying to do VPATH builds of R3.1.3, i.e. binaries built outside the source directory. It works just fine on Linux but on Mac OSX (Mavericks) I get the following trace from make, after a successful configure step. Any insights gratefully received. make is GNU make 3.81 on both systems. bash-3.2$ make make make[1]: Nothing to be done for `R'. make[1]: Nothing to be done for `R'.

The ocaml.opt compiler defaults to building things in the same directory as its input; we need explicit -o options to build in a VPATH $(builddir) when $(srcdir) is read-only (as is the case during 'make distcheck'). We also have to build any side effect files explicitly in cases where we can't directly use -o to control those outputs alongside the final product. Thanks: Richard W.M.

# HG changeset patch # User Matthias Andree <matthias.andree at gmx.de> # Date 1246993296 -7200 # Branch HEAD # Node ID c884491cb1a61ef50e227fcf4bb77d2e449c1e3a # Parent dff7312629a72f6ee90ab470ad0d50dfa68e6f71 Fix VPATH build of RQUOTA support. Some rpcgen derive #include "..." paths from the infile argument. This will be off for VPATH builds, as the generated rquota_xdr.c code

Roland Mainz wrote: > April Chin wrote: > > I''m in the process of filing manpage bugs for ksh93 to include > > changes to existing pages and new manpages for ksh93(1) and its > > builtins (builtin(1), disown(1)). > > > > CR 6457823 New manpages needed for ksh93 > > > > However, I do not see any manpages for vmap(1), alarm(1), or vpath(1). >

I was fiddling around to get VPATH builds working again, and the only nontrivial fix was for ordinals.h. Because it is auto-generated, it goes in the build directory, not the source directory, and thus requires some fiddling to get included properly. After looking at it, I don't see why it needs to be auto-generated. Rather than substituting in these values with autoconf, they can just be

# HG changeset patch # User Bastian Blank <waldi@debian.org> # Date 1201284962 -3600 # Node ID 11b2e8baa6bf93b8ec4b3b4fe0256d2ce34f2699 # Parent 31adb5c972d03e45cb746cd2305126ea2571282f Use VPATH instead of symlinks for libelf inclusion into libxenctrl. Signed-off-by: Bastian Blank <waldi@debian.org> diff -r 31adb5c972d0 -r 11b2e8baa6bf tools/libxc/Makefile ---

2008/12/31 Chris Lattner <clattner at apple.com> > On Dec 30, 2008, at 2:54 PM, Talin wrote: > > OK changes made and new patch attached. > > +++ utils/unittest/Makefile (revision 0) > > ... > +# This has to come after Makefile.common, since it doesn't allow us to > +# override the VPATH value unless we set PROJECT_NAME, which we don't want > +# to do.

On 12/3/18 1:01 PM, Richard W.M. Jones wrote: > >>> passthru ("--error-exitcode=119"); >>> - passthru_format ("--suppressions=%s/valgrind-suppressions", srcdir); >>> + passthru_format ("--suppressions=%s/valgrind/suppressions", builddir); >> >> Is this still right under VPATH? > > I believe so ...? Note

On Dec 30, 2008, at 2:54 PM, Talin wrote: > OK changes made and new patch attached. Nice +++ utils/unittest/Makefile (revision 0) ... +# This has to come after Makefile.common, since it doesn't allow us to +# override the VPATH value unless we set PROJECT_NAME, which we don't want +# to do. +VPATH = $(LLVM_SRC_ROOT)/utils/unittest/googletest/src/ Why play with VPATH here? What

I've got a tough to track down problem that seems to be samba related. I've got a directory structure like this: topdir/ lib1/src lib1/include lib2/src lib2/include etc. Each src directory has a makefile in it. VPATH is set to ../include. I'm running cygwin bash and make. In some directories, make can't find files in ../include. In other directories, make finds

I have 6 zfs pools and after rebooting init 6 the vpath device path names have changed for some unknown reason. But I can''t detach, remove and reattach to the new device names....ANY HELP! please pjde43m01 - - - - FAULTED - pjde43m02 - - - - FAULTED - pjde43m03 - - - - FAULTED - poas43m01 - - - -

Hello, I am trying to configure ZFS with IBM sdd. IBM sdd is like powerpath, MPXIO or VxDMP. Here is the error message when I try to create my pool: bash-3.00# zpool create tank /dev/dsk/vpath1a warning: device in use checking failed: No such device internal error: unexpected error 22 at line 446 of ../common/libzfs_pool.c bash-3.00# zpool create tank /dev/dsk/vpath1c cannot open

Hallo, trying to compile the current 1.1 git snapshot under Debian Wheezy gives me: configure.ac:7: option `info-in-builddir' not recognized autoreconf: automake failed with exit status: 1 Do I now need a specific newer version of automake? Seems to be the result of commit 13f9bc1ff199bea46 "Add support for out-of-tree ("VPATH") builds." Undoing the change to

On Thu, Dec 05, 2013 at 07:02:28PM +0100, Pino Toscano wrote: > On Thursday 05 December 2013 15:53:58 Richard W.M. Jones wrote: > > On Thu, Dec 05, 2013 at 04:30:05PM +0100, Pino Toscano wrote: > > > Fix the dependencies of the libguestfs.pot target: other than using > > > the right make variables holding the contents of the POTFILES, > > > depend also on the

On 12/2/18 10:39 AM, Richard W.M. Jones wrote: > By default valgrind suppresses many leaks. I'm not even sure exactly > how it decides which ones to suppress, but certainly global variables > pointing to malloc’d data are suppressed, which is not useful > behaviour. Here's my understanding of why that is the default - if you assign malloc()d storage into a global, then that

OK changes made and new patch attached. Comments below: On Tue, Dec 30, 2008 at 2:40 PM, Misha Brukman <brukman at gmail.com> wrote: > +++ unittests/TestMain.cpp (revision 0) > +//===--- unittest.cpp - unittest driver > -----------------------------------===// > > +++ unittests/ADT/DenseMapTest.cpp (revision 0) > +//===- llvm/unittest/DenseMapMap.h - DenseMap unit

(I'm not subscribed; Mail-Followup-To set.) Contrary to the claim in the output of ./configure --help, $CPPFLAGS is in fact not influential. --- rsync-2.5.5/Makefile.in~ 2002-03-24 23:36:34.000000000 -0500 +++ rsync-2.5.5/Makefile.in 2002-11-12 17:52:04.000000000 -0500 @@ -9,6 +9,7 @@ LIBS=@LIBS@ CC=@CC@ CFLAGS=@CFLAGS@ +CPPFLAGS=@CPPFLAGS@ LDFLAGS=@LDFLAGS@

+++ unittests/TestMain.cpp (revision 0) +//===--- unittest.cpp - unittest driver -----------------------------------===// +++ unittests/ADT/DenseMapTest.cpp (revision 0) +//===- llvm/unittest/DenseMapMap.h - DenseMap unit tests --------*- C++ -*-===// You probably want to update these file headers to match their real names. 2008/12/30 Misha Brukman <brukman at gmail.com> >