Bug 1389719

Summary: trying to set internal library path isn't effective
Product: [Fedora] Fedora EPEL Reporter: Dave Love <dave.love>
Component: RAssignee: Tom "spot" Callaway <spotrh>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: el6   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-30 15:07:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Dave Love 2016-10-28 10:07:31 UTC
Description of problem:

The package installs an ldconfig file pointing to %libdir/R/lib, but it doesn't take effect because R/etc/ldpaths sets LD_LIBRARY_PATH unconditionally to override it and user setting via the environment, which I think is wrong.  It's relevant if you want to override libRblas cleanly.

I think something like this does the right thing:

if [ -n "$R_LD_LIBRARY_PATH" ]; then
  if [ -z "$LD_LIBRARY_PATH" ]; then
    LD_LIBRARY_PATH="$R_LD_LIBRARY_PATH"
  else
    LD_LIBRARY_PATH="$R_LD_LIBRARY_PATH:$LD_LIBRARY_PATH"
  fi
  export LD_LIBRARY_PATH
fi

Version-Release number of selected component (if applicable):

R-core-3.3.1-2.el6.x86_64

Comment 1 Tom "spot" Callaway 2016-10-28 15:19:32 UTC
Just trying to wrap my brain around this, but it looks like LD_LIBRARY_PATH only gets overridden entirely if LD_LIBRARY_PATH is empty.

This is what currently exists at the end of R/etc/ldpaths:

if test -z "${LD_LIBRARY_PATH}"; then
  LD_LIBRARY_PATH="${R_LD_LIBRARY_PATH}"
else
  LD_LIBRARY_PATH="${R_LD_LIBRARY_PATH}:${LD_LIBRARY_PATH}"
fi
export LD_LIBRARY_PATH

It seems to me that if the problem is that you want your libRblas.so to be loaded before the R libRblas in R_LD_LIBRARY_PATH, you'd want this instead:

if test -z "${LD_LIBRARY_PATH}"; then
  LD_LIBRARY_PATH="${R_LD_LIBRARY_PATH}"
else
  LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${R_LD_LIBRARY_PATH}"
fi
export LD_LIBRARY_PATH

(I think that the ld.so.conf file doesn't really come into play here, because this is execution-time, not linking.)

Comment 2 Dave Love 2016-10-31 11:38:04 UTC
(In reply to Tom "spot" Callaway from comment #1)
> Just trying to wrap my brain around this, but it looks like LD_LIBRARY_PATH
> only gets overridden entirely if LD_LIBRARY_PATH is empty.

It gets overridden by R_LD_LIBRARY_PATH in either case, and it's set unconditionally higher up -- that's the problem.

> (I think that the ld.so.conf file doesn't really come into play here,
> because this is execution-time, not linking.)

It determines the default runtime behaviour via the cache; see ldconfig(8).

Comment 3 Tom "spot" Callaway 2016-10-31 14:07:46 UTC
(In reply to Dave Love from comment #2)
> (In reply to Tom "spot" Callaway from comment #1)
> > Just trying to wrap my brain around this, but it looks like LD_LIBRARY_PATH
> > only gets overridden entirely if LD_LIBRARY_PATH is empty.
> 
> It gets overridden by R_LD_LIBRARY_PATH in either case, and it's set
> unconditionally higher up -- that's the problem.

I'm not sure this is true. This is the current behavior:

If LD_LIBRARY_PATH is empty, it sets it to R_LD_LIBRARY_PATH.
If LD_LIBRARY_PATH is not empty, it prepends R_LD_LIBRARY_PATH in front of the existing LD_LIBRARY_PATH.

*****

Now, I think the problem is that because you are trying to set LD_LIBRARY_PATH to a value containing a library that you want R to use instead of the one in R_LD_LIBRARY_PATH, this never happens because R_LD_LIBRARY_PATH is checked before LD_LIBRARY_PATH. I suggested that swapping the order to check the existing LD_LIBRARY_PATH before R_LD_LIBRARY_PATH would resolve this.

Am I understanding the problem correctly? I apologize for being a bit slow here.

Comment 4 Dave Love 2016-11-07 11:33:37 UTC
(In reply to Tom "spot" Callaway from comment #3)

> Now, I think the problem is that because you are trying to set
> LD_LIBRARY_PATH to a value containing a library that you want R to use
> instead of the one in R_LD_LIBRARY_PATH, this never happens because
> R_LD_LIBRARY_PATH is checked before LD_LIBRARY_PATH. I suggested that
> swapping the order to check the existing LD_LIBRARY_PATH before
> R_LD_LIBRARY_PATH would resolve this.

This is probably moot if an efficient BLAS is used anyhow, but it's still apparently redundant with ld.so.conf.  However, I think the order is correct -- it's just that R_LD_LIBRARY_PATH is set unconditionally (the same in two conditional branches), and overrides anything you try to configure through the environment.

Comment 5 Tom "spot" Callaway 2016-11-07 14:45:54 UTC
Oh, I see, you're trying to override R_LD_LIBRARY_PATH. It is unclear to me if the upstream R intends for that to be supported or not. Perhaps you should bring this issue up with them and see what they prefer?

Comment 6 Fedora Admin user for bugzilla script actions 2020-06-03 02:45:56 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 7 Ben Cotton 2020-11-05 16:47:37 UTC
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged  change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.

Comment 8 Ben Cotton 2020-11-30 15:07:03 UTC
EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
EPEL please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.