Skip to content

R-SIG-Mac Digest, Vol 255, Issue 11

2 messages · Christian Schulz, Bram Boeckx

#
Cancel subscription, please. 
Von meinem iPhone gesendet
#
Dear,

Thanks for your message,
I'm currently on paternity leave until 23th of July and cannot respond to your email. Please contact my colleagues if you have questions or need assistance.

Best Wishes,

Bram
On 30 Jun 2024, at 17:24, Christian Hoffmann via R-SIG-Mac <r-sig-mac at r-project.org> wrote:
Cancel subscription, please.
Von meinem iPhone gesendet

Am 27.06.2024 um 09:49 schrieb r-sig-mac-request at r-project.org:

?Send R-SIG-Mac mailing list submissions to
  r-sig-mac at r-project.org

To subscribe or unsubscribe via the World Wide Web, visit
  https://stat.ethz.ch/mailman/listinfo/r-sig-mac
or, via email, send a message with subject or body 'help' to
  r-sig-mac-request at r-project.org

You can reach the person managing the list at
  r-sig-mac-owner at r-project.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of R-SIG-Mac digest..."


Today's Topics:

 1. Re:   procedure to ship libomp.dylib run-time with package
    (Bram Boeckx)
 2. Re:   procedure to ship libomp.dylib run-time with package
    (Bram Boeckx)

----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Jun 2024 07:36:39 +0000
From: Bram Boeckx <bram.boeckx at kuleuven.be>
To: "Sparapani, Rodney via R-SIG-Mac" <R-SIG-Mac at r-project.org>
Subject: Re: [R-SIG-Mac]  procedure to ship libomp.dylib run-time with
  package
Message-ID: <72B3DAB6-6B6F-46BF-921E-6B4DE21307C3 at kuleuven.be>
Content-Type: text/plain; charset="utf-8"

Dear,

Thanks for your message,
I'm currently on paternity leave until 23th of July and cannot respond to your email. Please contact my colleagues if you have questions or need assistance.

Best Wishes,

Bram
On 25 Jun 2024, at 14:20, Sparapani, Rodney via R-SIG-Mac <R-SIG-Mac at r-project.org> wrote:
Hi Tim:

/usr/local/lib it seems.  See the following page
https://mac.r-project.org/openmp/

--
Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
Vice President, Wisconsin Chapter of the American Statistical Association
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus

If this is outside of working hours, then please respond when convenient.

From: R-SIG-Mac <r-sig-mac-bounces at r-project.org> on behalf of Timothy Bates <tim.bates at ed.ac.uk>
Date: Monday, June 24, 2024 at 4:00?PM
To: R list <R-SIG-Mac at r-project.org>
Subject: [R-SIG-Mac] procedure to ship libomp.dylib run-time with package
ATTENTION: This email originated from a sender outside of MCW. Use caution when clicking on links or opening attachments.
________________________________

At https://urldefense.com/v3/__https://mac.r-project.org/openmp/__;!!H8mHWRdzp34!4HZ0uFxJQ121gF_TnX99OuMlgIXM600pq8wCbWruoLsdLTtaFgRB5_gMopCtxD0N9M4tUOO-7hBGADHx1sk$<https://urldefense.com/v3/__https:/mac.r-project.org/openmp/__;!!H8mHWRdzp34!4HZ0uFxJQ121gF_TnX99OuMlgIXM600pq8wCbWruoLsdLTtaFgRB5_gMopCtxD0N9M4tUOO-7hBGADHx1sk$>  it  says
"any package you compile against libomp.dylib will need that run-time so you have to ship it with your package or have users install it?

Are there  any  instructions on what to do/where to put libomp.dylib so it will be found?

I?ve compiled a package (OpenMx) in which OpenMP is working locally but other users get the error:

require(OpenMx)
Error: package or namespace load failed for ?OpenMx? in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/Users/***/Library/R/x86_64/4.4/library/OpenMx/libs/OpenMx.so':

dlopen(/Users/***/Library/R/x86_64/4.4/library/OpenMx/libs/OpenMx.so, 0x0006): Library not loaded: /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libomp.dylib


The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th? ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!4HZ0uFxJQ121gF_TnX99OuMlgIXM600pq8wCbWruoLsdLTtaFgRB5_gMopCtxD0N9M4tUOO-7hBGdICDldE$<https://urldefense.com/v3/__https:/stat.ethz.ch/mailman/listinfo/r-sig-mac__;!!H8mHWRdzp34!4HZ0uFxJQ121gF_TnX99OuMlgIXM600pq8wCbWruoLsdLTtaFgRB5_gMopCtxD0N9M4tUOO-7hBGdICDldE$>


_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac




------------------------------

Message: 2
Date: Wed, 26 Jun 2024 10:18:20 +0000
From: Bram Boeckx <bram.boeckx at kuleuven.be>
To: Prof Brian Ripley via R-SIG-Mac <R-SIG-Mac at r-project.org>
Subject: Re: [R-SIG-Mac]  procedure to ship libomp.dylib run-time with
  package
Message-ID: <9B5F82F3-B07B-4A05-9ED1-419CD6924D02 at kuleuven.be>
Content-Type: text/plain; charset="utf-8"

Dear,

Thanks for your message,
I'm currently on paternity leave until 23th of July and cannot respond to your email. Please contact my colleagues if you have questions or need assistance.

Best Wishes,

Bram
On 26 Jun 2024, at 11:57, Prof Brian Ripley via R-SIG-Mac <R-SIG-Mac at r-project.org> wrote:

        
On 26/06/2024 06:41, Balamuta, James wrote:
Tim,
Unfortunately, there isn't a nice way of including OpenMP for macOS within a package.  One potential avenue would be to use a `configure.ac` file to check for whether OpenMP headers are present on the macOS computer and, then, allow the correct OpenMP compilation flags to be set. However, this requires the user to compile from source instead of using a CRAN binary.

Package installation also requires the libomp.dylib, and to know where to find it both when linking and loading.

Unfortunately, there isn't going to be an easier way as OpenMP on macOS with R is experimental by nature.

Rather, macOS makes it deliberately hard, but those instructions are not current.

- The standard way for the macOS linker to record paths to a dependent dylib is as an absolute path.  E.g. (arm64)

% otool -L library/stats/libs/stats.so
library/stats/libs/stats.so:
      stats.so (compatibility version 0.0.0, current version 0.0.0)
      /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRlapack.dylib (compatibility version 4.4.0, current version 4.4.1)
...

That is a location that is not writeable to an end user.  However, it appears that R 4.4.1 for arm64 ships with a bi-arch libomp.dylib there.

auk2% file `R RHOME`/lib/libomp.dylib
/Library/Frameworks/R.framework/Resources/lib/libomp.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64]
/Library/Frameworks/R.framework/Resources/lib/libomp.dylib (for architecture x86_64):   Mach-O 64-bit dynamically linked shared library x86_64
/Library/Frameworks/R.framework/Resources/lib/libomp.dylib (for architecture arm64):    Mach-O 64-bit dynamically linked shared library arm64

So it is likely that libomp.dylib is already available somewhere that will be searched at both link and load times.  (omp.h needs to be put in a suitable place, e.g. /usr/local/include for Intel, but that needs admin privileges. That is only needed at compilation, so could be put anywhere and -I specified.)

- Another issue: That page provides multiple copies on libomp.dylib: how could package installation know which is appropriate?  I do not know which one was shipped with R, nor how find out.  But it suggests shipping one with a package would be unsafe.

It seems the OP asked the wrong question: apparently he distributed a package built with R 4.3.x, and someone tried to use it on 4.4.x.  R binary packages are tied to an R x.y series (as the manual would have told you).

I was able to build OpenMx with OpenMP on arch64 by using

PKG_CPPFLAGS = -Xclang -fopenmp -I/path/to/omp.h

PKG_LIBS= -lomp \
...

(Caveat: for OpenMx, <omp.h> is used so the -I adds to the system include path and there is danger of conflicts. Best to use a separate directory for the OpenMP headers.)

And please comply with the posting guide, not send HTML and not mangle URLs.

Best regards,
James