Skip to content

Need for `-headerpad_max_install_names` with `--enable-R-framework`

6 messages · Peter Dalgaard, Simon Urbanek, Heather Turner

Original
Heather Turner
# 
Dear All,

I have been building R (on Apple M1 Pro) with `--enable-R-framework` so that I can use the built version of R in RStudio/Positron. My set up was working fine back in February or so, then in April (with the alpha version) I started to hit errors with `make install`:

Creating R framework ...
  libRlapack
  libRblas
error: /Library/Developer/CommandLineTools/usr/bin/install_name_tool: changing install names or rpaths can't be redone for: /Library/Frameworks/R.framework/Versions/R-devel/Resources/bin/exec/R <http://r.framework/Versions/R-devel/Resources/bin/exec/R> (for architecture arm64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
<similar error for libR, snipped>

I only just got round to exploring further. I can fix the issue by adding 

MAIN_LDFLAGS="-Wl,-headerpad_max_install_names"

to my config.site, but I wonder why I didn't need to set this in the past. Also I wonder if this should be set by default, at least with `--enable-R-framework`?

Let me know if I can provide any information that might be helpful about my configuration/setup.

Best wishes,
Heather
Simon Urbanek
# 
Heather,

yes, please, since we cannot reproduce it, please provide your complete configure flags, full info about your macOS version, tools used (toolchain version and SDK). We are adding -Wl,-headerpad_max_install_names for libraries (see etc/Makeconf, added by configure.ac for darwin), but the binary itself has never caused issues, so I wonder what makes your system produce smaller header that won?t fit the paths.

Thanks,
Simon
Heather Turner
# 
Hi Simon,

I am configuring with 

$TOP_SRCDIR/configure --enable-R-framework --disable-java FW_VERSION=R-devel

and config.site

CC=clang
OBJC=$CC
FC="/opt/gfortran/bin/gfortran -mtune=native"
CPPFLAGS='-isystem /opt/R/arm64/include'
CXX=clang++
PKG_CONFIG_PATH=/opt/R/arm64/lib/pkgconfig:/usr/lib/pkgconfig
CFLAGS="-falign-functions=8 -g -O0"
FFLAGS="-g -O2 -mmacosx-version-min=11.0"
FCFLAGS="-g -O2 -mmacosx-version-min=11.0"
LDFLAGS="-L/opt/R/arm64/lib -L/opt/gfortran/lib"
CPPFLAGS="-isystem /opt/R/arm64/include -I/opt/R/arm64/include"

[this is the version before adding MAIN_LDFLAGS="-Wl,-headerpad_max_install_names"]

I'm using Command Line Tools only (no full Xcode installed).

macOS version: Sequoia 15.4.1 (24E263)
CLT version: 16.3.0.0.1.1742442376
Clang: Apple clang version 17.0.0 (clang-1700.0.13.3)
Fortran: GNU Fortran (GCC) 8.2.0 (from https://mac.r-project.org/tools/gfortran-14.2-universal.pkg)
SDK version: 15.4
SDK path: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

and could reproduce the issue on my side with an SVN checkout of R-devel 2025-05-15 r88204.

Hope that helps,

Heather
On Fri, May 16, 2025, at 4:43 AM, Simon Urbanek wrote:
Peter Dalgaard
# 
CLT 16.3 could be the issue. I also got caught by that not-so-trivial point upgrade, and it broke standalone nmath. Simon hasn't upgraded, so the nightly builds are a version ahead of him for once, but they do not test framework installs, so stuff like this is not detected (fodder for the sustainability project...)

- Peter

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
Heather,

thanks, I can reproduce it with CTL 16.3, so it is caused by the toolchain. Although both (16.2 and 16.3) actually have pretty much identical headers and the same local commands, the 16.3 toolchain inserts one small block right behind the load commands thus preventing them to grow. Interestingly, using -Wl,-headerpad_max_install_names just shifts that block back without using any extra space (i.e the file size is the same), so it seems like a reasonable work-around, although it is very perplexing why CLT 16.3 doesn't do that automatically - it looks like a regression in the toolchain. I have now added the work-around to R-devel as r88214.

Cheers,
Simon

PS: FWIW as noted before, CLT 16.3 despite looking like a minor update is actually a very major breaking change jumping from llvm 17 to 19.

PPS: unrelated to the issue here, but you seem to have a problem in your system: you are picking up some ancient Fortran since you show 8.2 while you should see 14.2.0. Also you are adding /opt/gfortran/lib which shouldn't be in flags as it doesn't have any libraries in the 14.2.0 binary, so it all looks suspicious. If in doubt, remove /opt/gfortran completely and re-install. FWIW the official flags used for CRAN builds are at
https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4/conf.big-sur-arm64

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    
2 days later

    

      
      

        


  

        

      Heather Turner
    

    

      
      #
    

  


  

      
Thanks for the update and explanation.

Thanks also for pointing out the Fortran issue - I'm not going to mess with things now as I don't want to break anything before R Dev Day @ Rencontres R, but I'll certainly come back to that and hopefully get my setup sorted out.

Best wishes,
Heather

        
On Sat, May 17, 2025, at 2:49 AM, Simon Urbanek wrote: