search

MichaelChirico / r-bugs

A ⚠️read-only⚠️mirror of https://bugs.r-project.org/
20 stars 0 forks source link

[BUGZILLA #14815] Compile issue with ld.gold #4404

Closed MichaelChirico closed 4 years ago

MichaelChirico commented 4 years ago

On a clean install of Ubuntu 11.10 x86_64 using ld.gold, the compile fails with:

.... byte-compiling package 'grDevices' Warning in solve.default(rgb) : unable to load shared object '/home/bghill/Downloads/R-2.14.1/modules//lapack.so': /home/bghill/Downloads/R-2.14.1/lib/libRlapack.so: undefined symbol: _gfortran_compare_string Error in solve.default(rgb) : lapack routines cannot be loaded Error: unable to load R code in package 'grDevices' Execution halted make[4]: [../../../library/grDevices/R/grDevices.rdb] Error 1 make[4]: Leaving directory `/home/bghill/Downloads/R-2.14.1/src/library/grDevices' make[3]: [all] Error 2 make[3]: Leaving directory /home/bghill/Downloads/R-2.14.1/src/library/grDevices' make[2]: *** [R] Error 1 make[2]: Leaving directory/home/bghill/Downloads/R-2.14.1/src/library' make[1]: [R] Error 1 make[1]: Leaving directory `/home/bghill/Downloads/R-2.14.1/src' make: [R] Error 1

ldd reports: $ ldd lib/libRlapack.so linux-vdso.so.1 => (0x00007fff7e9ff000) libRblas.so => not found libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa2cf8a2000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa2cf502000) /lib64/ld-linux-x86-64.so.2 (0x00007fa2cfc56000) $ ldd lib/libRblas.so linux-vdso.so.1 => (0x00007fff049ff000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcd5e131000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcd5df14000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcd5db74000) /lib64/ld-linux-x86-64.so.2 (0x00007fcd5e3ff000) $ ldd modules/lapack.so linux-vdso.so.1 => (0x00007fff54bff000) libR.so => not found libRlapack.so => not found libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe913f02000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe913b63000) /lib64/ld-linux-x86-64.so.2 (0x00007fe9141ae000)

So clearly, libgfortran did not get linked in. Looking at why not, it seems that libRblas.so has no calls to gfortran sub-routines, but

$ nm lib/libRlapack.so | grep gfortran_ U _gfortran_compare_string U _gfortran_concat_string U _gfortran_pow_i4_i4

ld.bfd does allow libRblas.so or lapack.so to have libgfortran as a dependency even if it isn't used directly. With ld.gold, that dependency is dropped even though the libRblas.so and lapack.so files are created with -lgfortran. The make system relies on this behavior in ld.bdf because in src/modules/lapack/Makefile.in:

... Rlapack_la_LIBADD = @DYLIB_UNDEFINED_ALLOWED_FALSE@ $(FLIBS) $(LIBR) ...

And on this system DYLIB_UNDEFINED_ALLOWED_FALSE=#

While this isn't critical, some build systems now rely on ld.gold and most users won't know which ld their system links to.

METADATA

MichaelChirico commented 4 years ago

On 15/02/2012 22:44, r-bugs@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::>-project.org wrote:

https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14815

Summary: Compile issue with ld.gold
Product: R
Version: R 2.14.1
Platform: x86_64/x64/amd64 (64-bit)
OS/Version: Linux-Ubuntu
Status: NEW
Severity: enhancement
Priority: P5
Component: Installation
AssignedTo: R-core@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::>-project.org
ReportedBy: bghill@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::>
Estimated Hours: 0.0

On a clean install of Ubuntu 11.10 x86_64 using ld.gold, the compile fails
with:

....
byte-compiling package 'grDevices'
Warning in solve.default(rgb) :
unable to load shared object
'/home/bghill/Downloads/R-2.14.1/modules//lapack.so':
/home/bghill/Downloads/R-2.14.1/lib/libRlapack.so: undefined symbol:
_gfortran_compare_string
Error in solve.default(rgb) : lapack routines cannot be loaded
Error: unable to load R code in package 'grDevices'
Execution halted
make[4]: *** [../../../library/grDevices/R/grDevices.rdb] Error 1
make[4]: Leaving directory
`/home/bghill/Downloads/R-2.14.1/src/library/grDevices'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/home/bghill/Downloads/R-2.14.1/src/library/grDevices'
make[2]: *** [R] Error 1
make[2]: Leaving directory `/home/bghill/Downloads/R-2.14.1/src/library'
make[1]: *** [R] Error 1
make[1]: Leaving directory `/home/bghill/Downloads/R-2.14.1/src'
make: *** [R] Error 1

ldd reports:
$ ldd lib/libRlapack.so
linux-vdso.so.1 =>   (0x00007fff7e9ff000)
libRblas.so =>  not found
libpthread.so.0 =>  /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fa2cf8a2000)
libc.so.6 =>  /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa2cf502000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa2cfc56000)
$ ldd lib/libRblas.so
linux-vdso.so.1 =>   (0x00007fff049ff000)
libm.so.6 =>  /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcd5e131000)
libpthread.so.0 =>  /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fcd5df14000)
libc.so.6 =>  /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcd5db74000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcd5e3ff000)
$ ldd modules/lapack.so
linux-vdso.so.1 =>   (0x00007fff54bff000)
libR.so =>  not found
libRlapack.so =>  not found
libm.so.6 =>  /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe913f02000)
libc.so.6 =>  /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe913b63000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe9141ae000)

So clearly, libgfortran did not get linked in.  Looking at why not, it seems
that libRblas.so has no calls to gfortran sub-routines, but

$ nm lib/libRlapack.so | grep gfortran_
U _gfortran_compare_string
U _gfortran_concat_string
U _gfortran_pow_i4_i4

ld.bfd does allow libRblas.so or lapack.so to have libgfortran as a
dependency
even if it isn't used directly.  With ld.gold, that dependency is dropped
even
though the libRblas.so and lapack.so files are created with -lgfortran.  The
make system relies on this behavior in ld.bdf because in
src/modules/lapack/Makefile.in:

...
Rlapack_la_LIBADD = @DYLIB_UNDEFINED_ALLOWED_FALSE@ $(FLIBS) $(LIBR)
...

And on this system DYLIB_UNDEFINED_ALLOWED_FALSE=#

While this isn't critical, some build systems now rely on ld.gold and most
users won't know which ld their system links to.

So please provide a patch to configure. We don't have such a system ....

-- Brian D. Ripley, ripley@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ <CENSORING FROM DETECTED PHONE NUMBER ONWARDS; SEE BUGZILLA>

METADATA

MichaelChirico commented 4 years ago

Please try R-devel (as we asked of you): most likely this has already been solved by the changes made there.

METADATA

MichaelChirico commented 4 years ago

Also, I was unable to reproduce this using ld.gold on x86_64 Fedora 16 in either R-devel or R 2.14.1.

METADATA

MichaelChirico commented 4 years ago

Just realised that r-devel still had configure built by autoconf-2.63, while the release branch is from -2.68. New version committed, you might want to retry the build.

On Feb 17, 2012, at 07:53 , <r-bugs@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::>-project.org> <r-bugs@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::>-project.org> wrote: [snip]


> While this isn't critical, some build systems now rely on ld.gold and most
> users won't know which ld their system links to.
> 
So please provide a patch to configure.  We don't have such a system ....

-- 
Brian D. Ripley,                  ripley@<::CENSORED -- SEE ORIGINAL ON BUGZILLA::>
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
<CENSORING FROM DETECTED PHONE NUMBER ONWARDS; SEE BUGZILLA>

-----------

#### METADATA
 - Comment author - Peter Dalgaard
 - Timestamp - 2012-02-18 14:37:10 UTC