Opened 12 years ago

Closed 12 years ago

#33044 closed defect (fixed)

port can't find R dylibs and repeatedly rebuilds

Reported by: yaseppochi (Stephen J. Turnbull) Owned by: neverpanic (Clemens Lang)
Priority: Normal Milestone:
Component: ports Version: 2.0.4
Keywords: rev-upgrade Cc: kjell.konis@…, neverpanic (Clemens Lang)
Port: R

Description

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.

Attachments (1)

Portfile.diff (927 bytes) - added by kjell.konis@… 12 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 12 years ago by neverpanic (Clemens Lang)

Cc: kjell.konis@… cal@… added
Component: baseports
Keywords: rev-upgrade added
Port: R added

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?

comment:2 Changed 12 years ago by 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.

comment:3 Changed 12 years ago by kjell.konis@…

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

comment:4 Changed 12 years ago by 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.

Changed 12 years ago by kjell.konis@…

Attachment: Portfile.diff added

comment:5 Changed 12 years ago by 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.

comment:6 Changed 12 years ago by neverpanic (Clemens Lang)

Owner: changed from macports-tickets@… to cal@…
Status: newassigned

comment:7 Changed 12 years ago by kjell.konis@…

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

comment:8 Changed 12 years ago by yaseppochi (Stephen J. Turnbull)

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

comment:9 Changed 12 years ago by neverpanic (Clemens Lang)

Resolution: fixed
Status: assignedclosed
Version: 2.0.32.0.4

Fixed with #33512 in r91157.

Note: See TracTickets for help on using tickets.