Skip to content

[R-pkg-devel] portability question

6 messages · Dirk Eddelbuettel, Simon Urbanek, Steven Scott

#
The Boom package builds a library against which other packages link.  The
library is built using the Makevars mechanism using the line

${AR} rc $@ $^

A user has asked me to change 'rc' to 'rcs' so that 'ranlib' will be run on
the archive.  This is apparently needed for certain flavors of macs.  I'm
hoping someone on this list can comment on the portability of that change
and whether it would negatively affect other platforms.  Thank you.
#
On 20 December 2023 at 11:10, Steven Scott wrote:
| The Boom package builds a library against which other packages link.  The
| library is built using the Makevars mechanism using the line
| 
| ${AR} rc $@ $^
| 
| A user has asked me to change 'rc' to 'rcs' so that 'ranlib' will be run on
| the archive.  This is apparently needed for certain flavors of macs.  I'm
| hoping someone on this list can comment on the portability of that change
| and whether it would negatively affect other platforms.  Thank you.

Just branch for macOS.  Here is a line I 'borrowed' years ago from data.table
and still use for packages needed to call install_name_tool on macOS.  You
could have a simple 'true' branch of the test use 'rcs' and the 'false'
branch do what you have always done.  Without any portability concerns.
and indented here for clarity

        if [ "$(OS)" != "Windows_NT" ] && [ `uname -s` = 'Darwin' ]; then \
           install_name_tool -id data_table$(SHLIB_EXT) data_table$(SHLIB_EXT); \
        fi

Dirk
#
Steven,

no, I'm not aware of any negative effect, in fact having an index in the archive is always a good idea - some linkers require it, some work faster with it and at the worst the linker ignores it. And as far as I can tell all current system "ar" implementations support the -s flag (even though technically, it's only part of the XSI POSIX extension, but POSIX doesn't define ranlib so ar -s is better than using ranlib directly).

Cheers,
Simon
#
This has nothing to do with Steven's question since he is creating a *static* library whereas install_name_tool changes install name ID entry of a *dynamic* library. Also the data.table example is effectively a no-op, because changing the ID makes no difference as it can't be linked against directly anyway. [In general, taking advice from data.table regarding macOS doesn't strike me as wise given that the authors can't even get their package to work properly on macOS.]

Cheers,
Simon
#
The point of my email was that

   if [ `uname -s` = 'Darwin' ]; then ...

allows for a clean branch between the (new here) macOS behaviour and (old,
prior) behavior removing all concerns about 'portability' (per the Subject:).

You missed 100% of that.

Dirk
#
I think Dirk was just showing me an example of how to branch on OS, which
would be relevant in the event that adding the 's' was harmful.  In this
case it sounds like adding the 's' is the right path forward, which is the
advice I was hoping for.  Thank you both!

On Wed, Dec 20, 2023 at 12:51?PM Simon Urbanek <simon.urbanek at r-project.org>
wrote: