port can't find R dylibs and repeatedly rebuilds

[yaseppochi (Stephen J. Turnbull)]

R keeps certain R-specific dylibs in its own library directory -- on my system it's

/opt/local/lib/R/lib/x86_64/

-- and port repeatedly rebuilds R, apparently failing with

--->  Computing dependencies for R
--->  Fetching R
--->  Verifying checksum(s) for R
--->  Extracting R
--->  Configuring R
--->  Building R
--->  Staging R into destroot
--->  Installing R @2.14.1_0+gcc44+recommended
--->  Activating R @2.14.1_0+gcc44+recommended
--->  Cleaning R
--->  Updating database of binaries: 100%
--->  Scanning binaries for linking errors: 98%
Warning: Could not open libRblas.dylib: Error opening or reading file

Warning: Could not open libR.dylib: Error opening or reading file
--->  Scanning binaries for linking errors: 100%
--->  Found 2 broken file(s), matching files to ports
Error: Port R is still broken after rebuiling it more than 3 times. You might want to file a bug for this.
Port R still broken after rebuilding 3 time(s)
    while executing
"error "Port [$port name] still broken after rebuilding [expr $broken_port_counts([$port name]) - 1] time(s)""
    (procedure "revupgrade_scanandrebuild" line 230)
    invoked from within
"revupgrade_scanandrebuild broken_port_counts $opts"
    (procedure "macports::revupgrade" line 5)
    invoked from within
"macports::revupgrade $opts"
    (procedure "action_revupgrade" line 2)
    invoked from within
"action_revupgrade $action $portlist $opts"
    (procedure "action_upgrade" line 24)
    invoked from within
"$action_proc $action $portlist [array get global_options]"
    (procedure "process_cmd" line 95)
    invoked from within
"process_cmd $remaining_args"
    invoked from within
"if { [llength $remaining_args] > 0 } {

    # If there are remaining arguments, process those as a command
    set exit_status [process_cmd $remaining..."
    (file "/opt/local/bin/port" line 4766)

R works fine, as far as I can tell in light testing.

[neverpanic (Clemens Lang)]

R should probably be linking against the absolute paths of these libraries, but I'll look into it.

Can you please run port -d rev-upgrade and paste/attach the output?

[neverpanic (Clemens Lang)]

Running

sudo install_name_tool -change libR.dylib /opt/local/lib/R/lib/x86_64/libR.dylib /opt/local/lib/R/bin/exec/x86_64/R
sudo install_name_tool -change libR.dylib /opt/local/lib/R/lib/x86_64/libR.dylib /opt/local/lib/R/bin/exec/x86_64/R

fixes this. This should probably be added to the Portfile in a post-destroot phase.

[kjell.konis@…]

Why not just run R using ${prefix}/bin/R?

[neverpanic (Clemens Lang)]

The problem is not about not being able to execute R through ${prefix}/bin/R, which sets DYLD_LIBRARY_PATH to the appropriate paths so the R binary will find it's libraries, but about our new check routine rev-upgrade in trunk, which tries to find binaries that have broken linkage. Since we cannot automatically determine whether DYLD_LIBRARY_PATH is set before starting a binary (we can't *know* automatically that R is supposed to be run through the script setting DYLD_LIBRARY_PATH) it thinks ${prefix}/lib/R/bin/exec/x86_64/R is broken, since it references a non-existant file and marks it for rebuild, which *usually* fixes this kind of problems, however in this case does not, because it's by design.

The problem can be easily fixed by running the two lines I posted above in a post-destroot phase, though, and this is why I think we should add this.

[kjell.konis@…]

The attached patch set the install names for the executables in bin/exec/${build-arch}/ during post-destroot as suggested. Please let me know if this solves the problem.

[kjell.konis@…]

The updated R port in bug #33512 includes the fix for this issue.

[yaseppochi (Stephen J. Turnbull)]

Confirmed -- fixes for me. Thank you very much!

[neverpanic (Clemens Lang)]

Fixed with #33512 in r91157.