Possible bug when finding shared libraries during staged installation

Kara Woo 
    on Thu, 23 May 2019 14:24:26 -0700 writes:

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

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

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