On 5/24/19 2:52 PM, Martin Maechler wrote:
Kara Woo
on Thu, 23 May 2019 14:24:26 -0700 writes:
> Hi all,
> With the new staged installation, it seems that R CMD INSTALL sometimes
> fails on macOS due to these lines [1] when sapply() returns a list. The
> x13binary package has an example [2], reproducible with the following
steps:
> $ git clone g...@github.com:x13org/x13binary.git && cd x13binary
> $ git checkout 663ad7122
> $ R CMD INSTALL .
> (We've also run into it in an internal package, but it's easier to
> reproduce with x13binary)
> In this case the file command returns multiple results for one of the
> dynamic libraries, so are_shared looks like this:
>> are_shared
> $`/Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib`
> [1] TRUE TRUE TRUE
> $`/Users/Kara/projects/forks/x13binary/inst//lib/libgfortran.3.dylib`
> [1] TRUE
> $`/Users/Kara/projects/forks/x13binary/inst//lib/libquadmath.0.dylib`
> [1] TRUE
Thank you, Kara.
Just for curiosity, what does
file /Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib
produce on your Mac?
I can reproduce, it is something like
/usr/lib/libgcc_s.1.dylib: Mach-O universal binary with 2 architectures:
[x86_64:Mach-O 64-bit dynamically linked shared library x86_64]
[i386:Mach-O dynamically linked shared library i386]
/usr/lib/libgcc_s.1.dylib (for architecture x86_64): Mach-O 64-bit
dynamically linked shared library x86_64
/usr/lib/libgcc_s.1.dylib (for architecture i386): Mach-O dynamically
linked shared library i386
Thanks for the report, I will fix.
Tomas
> slibs[are_shared] then fails with invalid subscript type 'list'.
yes, "of course".
> I believe this may be a bug and I have included a patch that uses any()
and
> vapply() to ensure that only one value is returned for each library and
the
> result is an atomic vector. This is my first time submitting a bug report
> or patch here; I'm happy to make any changes if needed.
Your patch was not attached with MIME type text/plain and so
was filtered out by the mailing list software.
OTOH, I could relatively easily guess how to fix the bug,
notably when seeing the above "file ...dylib" result.
What we *meant* to say in https://www.r-project.org/bugs.html
is that in such a situation
1) you send your finding / suspicion / diagnosis
to the R-devel mailing list, in order to get confirmation etc
if what you see is a bug;
2) then ideally, you'd do a formal bug report at
https://bugs.r-project.org/
(for which you need to get an "account" there to be created
once only by a bugzilla admin, typically an R core member).
In this case, that (2) may not be necessary, but you may want
that anyway (and let some of us know).
> Thanks for considering,
> Kara
Thank *you* indeed for the report,
Martin
> [1]
>
https://github.com/wch/r-source/blob/3fe2bb01e9ec1b268803a437c308742775c2442d/src/library/tools/R/install.R#L594-L597
> [2] https://github.com/x13org/x13binary/issues/46
> R version 3.6.0 Patched (2019-05-22 r76579)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: macOS Mojave 10.14.4
--
Martin Maechler
ETH Zurich and R Core Team
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
