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
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
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.
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]:
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