bug#17590: [PATCH] build: libstdbuf.so: avoid new OS X link failure

2014-05-25 Thread Jim Meyering
On Sun, May 25, 2014 at 1:31 PM, Pádraig Brady wrote: > On 05/25/2014 08:48 PM, Jim Meyering wrote: >> Without the attached patch, I'd get this new link failure on OS X: >> >> Undefined symbols for architecture x86_64: >> "_libintl_gettext", referenced from: >> _apply_mode in src_libstdbuf

bug#17590: [PATCH] build: libstdbuf.so: avoid new OS X link failure

2014-05-25 Thread Pádraig Brady
On 05/25/2014 08:48 PM, Jim Meyering wrote: > Without the attached patch, I'd get this new link failure on OS X: > > Undefined symbols for architecture x86_64: > "_libintl_gettext", referenced from: > _apply_mode in src_libstdbuf_so-libstdbuf.o > ld: symbol(s) not found for architecture x8

bug#17578: cp(1) man page: behavior of "cp -R dir target" on symbolic links is unclear

2014-05-25 Thread Paul Eggert
Pádraig Brady wrote: - -R, -r, --recursive copy directories recursively + -R, -r, --recursive copy directories recursively (implies -P) Unfortunately it's not that simple, as -R doesn't always imply -P.

bug#17590: [PATCH] build: libstdbuf.so: avoid new OS X link failure

2014-05-25 Thread Jim Meyering
Without the attached patch, I'd get this new link failure on OS X: Undefined symbols for architecture x86_64: "_libintl_gettext", referenced from: _apply_mode in src_libstdbuf_so-libstdbuf.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status make[2]:

bug#17578: cp(1) man page: behavior of "cp -R dir target" on symbolic links is unclear

2014-05-25 Thread Pádraig Brady
On 05/24/2014 04:07 PM, Vincent Lefevre wrote: > The cp(1) man page does not describe the behavior on symbolic links > when copying recursively. It appears that in such a case, cp does not > dereference the links (this is also what the info file says: "When > copying from a symbolic link, `cp' norm