Possible bug when finding shared libraries during staged installation

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible bug when finding shared libraries during staged installation

Kara Woo
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 [hidden email]: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
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug when finding shared libraries during staged installation

Martin Maechler
>>>>> 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 [hidden email]: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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug when finding shared libraries during staged installation

Tomas Kalibera
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 [hidden email]: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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug when finding shared libraries during staged installation

Simon Urbanek
In reply to this post by Martin Maechler
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 <[hidden email]> 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 [hidden email]: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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug when finding shared libraries during staged installation

Kara Woo
In reply to this post by Tomas Kalibera
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 <[hidden email]>
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 [hidden email]: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
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug when finding shared libraries during staged installation

Tomas Kalibera
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
> <[hidden email] <mailto:[hidden email]>> 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 [hidden email]: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
>     >
>     > ______________________________________________
>     > [hidden email] <mailto:[hidden email]> mailing list
>     > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>


        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel