R devel - May 2019 - Possible bug when finding shared libraries during staged installation

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 git at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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
into this!

On Fri, May 24, 2019 at 5:58 AM Tomas Kalibera <tomas.kalibera at
gmail.com>
wrote:
> 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 git at 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 at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
	[[alternative HTML version deleted]]

Fixed in R-devel and R-patched.

Best,
Tomas

On 5/24/19 6:56 PM, Kara Woo wrote:
> 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 into this!
>
> On Fri, May 24, 2019 at 5:58 AM Tomas Kalibera 
> <tomas.kalibera at gmail.com <mailto:tomas.kalibera at
gmail.com>> wrote:
>
>     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 git at 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 at r-project.org <mailto:R-devel at r-project.org>
mailing list
>     > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

	[[alternative HTML version deleted]]