Hide Forgot
Description of problem: When built on %{?rhel} == 6 the spec file requires to install static libraries for pcre, xz, ... because version of them in %{?rhel} == 6 are not high enough. The compilation with them works fine but they are never included in the final packages. They are linked in the %{_libdir}/R/etc/Makeconf but cannot be found because not in the final packages. (The paths of those static libraries in %{_libdir}/R/etc/Makeconf are also related to build time, not to installed time). I have also an issue with %{openblas} but it could be linked to our special installation: %{_libdir}/libopenblas.so.0 (line 717 of spec file R 3.3.2-2) does not exist. Version-Release number of selected component (if applicable): R 3.3.2-2 How reproducible: - About static libraries in %{?rhel} == 6, update the mgcv R library with R 3.3.2-2 installed. - About %{openblas} ls -l %{_libdir}/R/lib/libRblas.so Steps to Reproduce: 1. wget https://cran.r-project.org/src/contrib/mgcv_1.8-16.tar.gz 2. sudo R CMD INSTALL mgcv_1.8-16.tar.gz Actual results: - mgcv cannot be updated - %{_libdir}/R/lib/libRblas.so links to nothing. Expected results: - mgcv can be installed - %{_libdir}/R/lib/libRblas.so links a real file Additional info:
Do you _need_ those static libraries for any reason? They are intentionally excluded. Also, the package has a BuildRequires (and Requires) on openblas now. If you're overriding that, that's not a bug.
(In reply to Tom "spot" Callaway from comment #1) > Do you _need_ those static libraries for any reason? They are intentionally > excluded. > > Also, the package has a BuildRequires (and Requires) on openblas now. If > you're overriding that, that's not a bug. Don't know really if static libraries are required at running time. I expect e.g. pcre and xz will require the same versions than in the spec file at some point when libpcre and libzma will be needed at running time. No? If they are intentionally excluded, I still find paths pointing to them in %{_libdir}/R/etc/Makeconf About openblas, I think its our local specific installation that tries to link /usr/lib64/libopenblas.so.0 to /usr/lib64/R/lib/libRblas.so But for us %{_libdir} for libopenblas.so.0 is not the same than %{_libdir} for R/lib/libRblas.so
(In reply to smoretti from comment #2) > (In reply to Tom "spot" Callaway from comment #1) > > Do you _need_ those static libraries for any reason? They are intentionally > > excluded. > > > > Also, the package has a BuildRequires (and Requires) on openblas now. If > > you're overriding that, that's not a bug. > > > Don't know really if static libraries are required at running time. I expect > e.g. pcre and xz will require the same versions than in the spec file at > some point when libpcre and libzma will be needed at running time. No? > If they are intentionally excluded, I still find paths pointing to them in > %{_libdir}/R/etc/Makeconf They should not, because they're statically linked into R. I suppose it is hypothetically possible that something in CRAN will assume more modern libpcre and lzma libraries, inherit LIBS from Makeconf, and fail to build properly as a result. If we remove the -lpcre and -lzma lines from LIBS in Makeconf, I think there is a much greater chance that CRAN modules will stop building because they assume the presence of _some version_ of pcre/lzma. Honestly, the correct answer here is to upgrade to EL7 as soon as possible. RHEL 6 is 6 years old now. I'm doing what I can to keep things going, but this rabbit hole goes deep. :/ > About openblas, I think its our local specific installation that tries to > link > /usr/lib64/libopenblas.so.0 to /usr/lib64/R/lib/libRblas.so > But for us %{_libdir} for libopenblas.so.0 is not the same than %{_libdir} > for R/lib/libRblas.so I'm not sure I understand this at all. The R package makes the symlink to libopenblas because it is so much faster _and_ adds a hard Requires to the openblas package to ensure it is present. If you're using a custom openblas package that does not use the same pathing, you're going to have to correct the symlink on your end (or just make a link to /usr/lib64/libopenblas.so.0 from wherever you put it).
(In reply to Tom "spot" Callaway from comment #3) > (In reply to smoretti from comment #2) > > (In reply to Tom "spot" Callaway from comment #1) > > > Do you _need_ those static libraries for any reason? They are intentionally > > > excluded. > > > > > > Also, the package has a BuildRequires (and Requires) on openblas now. If > > > you're overriding that, that's not a bug. > > > > > > Don't know really if static libraries are required at running time. I expect > > e.g. pcre and xz will require the same versions than in the spec file at > > some point when libpcre and libzma will be needed at running time. No? > > If they are intentionally excluded, I still find paths pointing to them in > > %{_libdir}/R/etc/Makeconf > > They should not, because they're statically linked into R. I suppose it is > hypothetically possible that something in CRAN will assume more modern > libpcre and lzma libraries, inherit LIBS from Makeconf, and fail to build > properly as a result. > > If we remove the -lpcre and -lzma lines from LIBS in Makeconf, I think there > is a much greater chance that CRAN modules will stop building because they > assume the presence of _some version_ of pcre/lzma. > > Honestly, the correct answer here is to upgrade to EL7 as soon as possible. > RHEL 6 is 6 years old now. I'm doing what I can to keep things going, but > this rabbit hole goes deep. :/ It is planned to move to EL7 in January. In the meantime - and following our user urgency - I have patched the paths in Makeconf to use properly static libraries. It looks to work properly. Thanks > > About openblas, I think its our local specific installation that tries to > > link > > /usr/lib64/libopenblas.so.0 to /usr/lib64/R/lib/libRblas.so > > But for us %{_libdir} for libopenblas.so.0 is not the same than %{_libdir} > > for R/lib/libRblas.so > > I'm not sure I understand this at all. The R package makes the symlink to > libopenblas because it is so much faster _and_ adds a hard Requires to the > openblas package to ensure it is present. If you're using a custom openblas > package that does not use the same pathing, you're going to have to correct > the symlink on your end (or just make a link to /usr/lib64/libopenblas.so.0 > from wherever you put it). We have different paths for libopenblas %{_libdir} and for R %{_libdir} because we maintain several R versions. I will use openblas in the future, when we will move to EL7. Thanks Regards
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
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.
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.