[Rd] Possible bug when finding shared libraries during staged installation
woo@k@r@ @end|ng |rom gm@||@com
Fri May 24 18:56:37 CEST 2019
Yes, that's the same result that I see as well.
If you still want the formal report I can create one if someone adds me to
bugzilla, but it sounds like that may not be necessary. Thanks for looking
On Fri, May 24, 2019 at 5:58 AM Tomas Kalibera <tomas.kalibera using gmail.com>
> 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
> > > fails on macOS due to these lines  when sapply() returns a
> list. The
> > > x13binary package has an example , reproducible with the
> following steps:
> > > $ git clone git using 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
> > > dynamic libraries, so are_shared looks like this:
> > >> are_shared
> > > $`/Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib`
> > >  TRUE TRUE TRUE
> > >
> > >  TRUE
> > >
> > >  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.
> > > 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
> > > 
> > >
> > >  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 using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
More information about the R-devel