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

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

slibs[are_shared] then fails with invalid subscript type 'list'.

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.

Thanks for considering,
Kara

[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

>>>>> 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?

    > 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

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

I'll have a look at the code - I don't think I actually reviewed all
those macOS modifications - I wasn't even aware that they were added to the
code.

> On May 24, 2019, at 08:52, Martin Maechler <maechler at
stat.math.ethz.ch> 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?
> 
>> 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
>