search for: dirs

...9; side and Linux (2.6.32, possibly fedora but unsure) on the 'receiver' side. Both with rsync 3.0.9. If I run the following command from the command line: /usr/local/bin/rsync -av -e "ssh -i \ /Users/pedrofortunyayuso/.ssh/backup_pfortuny_net" \ --filter ': rsync.dirs' ~/ pfortuny at pfortuny.net:"~/backup_mbpro/" Everything works OK. However, if I run it as a cron task, I receive the following mail: [headers stripped] X-Cron-Env: <SHELL=/bin/bash> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=pedrofortunyayuso> X-Cron-E...

Hi Folks, I am building LLVM 3.9.1 using the Yocto build system for a cross build. The compiled bins/libs work totally fine on the target machine however there seems to be an intermittent race condition during the build which causes a build failure. On the failed builds I usually see things being linking/compiling twice e.g. Linking CXX static library ../libLLVMSupport.a cd

On Sat, Oct 14, 2017 at 10:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Looks like I missed this one in my recent change. > > Please let me know if this solves your problem: > > $ git diff > diff --git a/utils/TableGen/InfoByHwMode.cpp > b/utils/TableGen/InfoByHwMode.cpp > index 7e1e1864356..8d3636432aa 100644 > ---

Hello LLVM developers, Following some hints on this mailing list earlier this year on how to make clang faster than stock llvm.org builds I have implemented a script that builds a PGO optimized version of clang by following the guide here: http://llvm.org/docs/HowToBuildWithPGO.html This works great on macOS and Linux - we gained almost 15% in our project with this technique. I am now looking at

Is anyone else seeing this bootstrap failure on current svn trunk? [ 6%] Linking CXX executable ../../bin/llvm-tblgen cd /sw/src/fink.build/llvm60-6.0.0-1/build/stage1/utils/TableGen && /sw/bin/cmake -E cmake_link_script CMakeFiles/llvm-tblgen.dir/link.txt --verbose=1 /sw/src/fink.build/llvm60-6.0.0-1/opt-bin/ccclang++ -fno-common -fPIC -fvisibility-inlines-hidden -Werror=date-time

Hello! I have problems compiling zaptel (tried 1.2.11, 1.2.10 and 1.4.0-beta2 -- all give the same error) with 2.6.19 kernel CC [M] /home/roman/install/asterisk/zaptel-1.4.0-beta2/xpp/card_fxo.o In file included from /home/roman/install/asterisk/zaptel-1.4.0-beta2/xpp/xpd.h:26, from /home/roman/install/asterisk/zaptel-1.4.0-beta2/xpp/card_fxo.c:28:

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along > with the rest of llvm. I'll work up a complete patch shortly. > > Btw, I'm curious how this happened. Do you have a stale CMakeCache.txt by > any chance? You might check the value for

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along with > the rest of llvm. I'll work up a complete patch shortly. This also broke the build for MSVC when doing a debug build (though no builder seems to be picking up the failure!). After

I'm having a strange problem compiling with VS 2013. It's not finding a header file that's there in one of the header file search dirs. Here's the compile command (with the names changed to protect the innocent ;-) 1> C:\Program Files (x86)\LLVM\msbuild-bin\CL.exe /c /IC:\[top-level-dir]\[source-dir]\ /IC:\[top-level-dir]\[source-dir]\[sub-dir-1] /IC:\[top-level-dir]\[source-dir]\[sub-dir-2] /IC:\[top-level-dir]\[de...

Hi, We did some performance test and found the create/delete files performance of btrfs is very poor. The test is that we create 50000 files and measure the file-create time first, and then delete these 50000 files and measure the file-delete time. (The attached file is the reproduce program) The result is following: (Unit: second) Create file performance BtrFS Ext4 Total times:

On Sat, Oct 14, 2017 at 11:38 AM, Don Hinton <hintonda at gmail.com> wrote: > Sorry, LLVM_FORCE_ENABLE_DUMP is the variable, which is used along with > LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP. > > Again, I'm working on a fix, but could you also provide your cmake > command? Looks like we aren't handling your use case correctly. > > thanks.. > don >

On Sun, Oct 15, 2017 at 10:58 AM, Don Hinton <hintonda at gmail.com> wrote: > Thanks Aaron. > > I don't have a Windows system, and haven't seen any buildbot failures, so I > it's difficult to come up with a patch for something I can't reproduce > locally or see any actual failures. Could you send me the commands you used > that uncovered the failure? This

On Sun, Oct 15, 2017 at 11:19 AM, Don Hinton <hintonda at gmail.com> wrote: > On Sun, Oct 15, 2017 at 8:06 AM, Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> On Sun, Oct 15, 2017 at 10:58 AM, Don Hinton <hintonda at gmail.com> wrote: >> > Thanks Aaron. >> > >> > I don't have a Windows system, and haven't seen any

On Sat, Oct 14, 2017 at 4:22 PM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > The only way I could reproduce the problem you are seeing was to rerun > cmake with -DCMAKE_BUILD_TYPE=Debug in a build directory previously > configured with -DCMAKE_BUILD_TYPE=Release. I can fix that, but not sure > if it's what you are seeing. > > If this isn't your

Hi all, this series removes most users of the write_one_page API. These helpers internally call ->writepage which we are gradually removing from the kernel. Changes since v2: - more minix error handling fixes Changes since v1: - drop the btrfs changes (queue up in the btrfs tree) - drop the finaly move to jfs (can't be done without the btrfs patches) - fix the existing minix code to

Hi all, this is the tenth version of the patch series to introduce upstream qemu and seabios in the xen-unstable build system. Changes to v9: - rename QEMU_UPSTREAM_TAG to QEMU_UPSTREAM_REVISION: we are going to use it with a branch name by default; - set QEMU_UPSTREAM_REVISION to "master" by default; - set SEABIOS_UPSTREAM_URL to git://xenbits.xen.org/seabios.git by default; - add

On Sun, Oct 15, 2017 at 12:40 PM, Don Hinton <hintonda at gmail.com> wrote: > On Sun, Oct 15, 2017 at 8:34 AM, Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> FWIW, most of the ones I was fixing up were guarded by NDEBUG instead >> of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link >> errors for me -- the only one I struggled with

Since snapshot rsync-HEAD-20090220-0710GMT.tar.gz make check is successful but sudo make check fails ------------------------------------------------------------ ----- overall results: 29 passed 3 failed 6 skipped ------------------------------------------------------------ failed FAIL batch-mode FAIL chmod-option FAIL daemon-gzip-upload

I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain. The configuration is the following: LIBCXX_HAS_MUSL_LIBC=ON LIBCXX_HAS_GCC_S_LIB=OFF CLANG_DEFAULT_CXX_STDLIB=libc++ CLANG_DEFAULT_LINKER=lld CLANG_DEFAULT_RTLIB=compiler-rt LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl LLVM_TARGET_ARCH=x86_64

With the following patch kbuild now supports: make usr/dash/arith_yylex.i make usr/klibc/umount.o make usr/klibc/umount.s Patch does also fix indention of CPP command Signed-off-by: Sam Ravnborg <sam at ravnborg.org> Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit a36102c485caf951294301425ee8e87aa6ab4d92 tree 88d3e4aebe253cb3d6c417eac3cd2c1fa14db694 parent