| Summary: | sci-mathematics/octave-3.6.2 fails to emerge due to undefined reference to `_gfortran_transfer_real_write@GFORTRAN_1.4' in sci-mathematics/octave-3.6.2/work/octave-3.6.2_build/libcruft/.libs/libcruft.so | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
| Component: | Current packages | Assignee: | Gentoo Science Mathematics related packages <sci-mathematics> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | dark |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | The result of 'emerge -uvDNep system' | ||
|
Description
Juergen Rose
2012-06-08 20:14:39 UTC
(In reply to comment #0) > 'emerge octave' fails with: > ... > creating .DOCSTRINGS from .cc source files > /var/tmp/portage/sci-mathematics/octave-3.6.2/work/octave-3.6.2/build-aux/ > move-if-change .DOCSTRINGS DOCSTRINGS > DOCSTRINGS is unchanged > touch .DOCSTRINGS > /var/tmp/portage/sci-mathematics/octave-3.6.2/work/octave-3.6.2_build/ > libcruft/.libs/libcruft.so: undefined reference to > `_gfortran_transfer_real_write@GFORTRAN_1.4' > /var/tmp/portage/sci-mathematics/octave-3.6.2/work/octave-3.6.2_build/ > libcruft/.libs/libcruft.so: undefined reference to > `_gfortran_transfer_character_write@GFORTRAN_1.4' > /var/tmp/portage/sci-mathematics/octave-3.6.2/work/octave-3.6.2_build/ > libcruft/.libs/libcruft.so: undefined reference to > `_gfortran_transfer_integer_write@GFORTRAN_1.4' > collect2: ld returned 1 exit status > make[3]: *** [octave] Error 1 > I found that both 3.6.1 and 3.6.2 failed with gcc-4.6.3 but emerged OK with 4.5.3. I have here at least five systems, where I was able to emerge octave-3.6.2 with x86_64-pc-linux-gnu-4.6.3 and three systems with the undefined reference to _gfortran_transfer_integer_write@GFORTRAN_1.4. It looks like the undefined reference to _gfortran_transfer_integer_write@GFORTRAN_1.4 occurs on all systems, where I did not 'emerge -uvDNe system' after gcc-upgrade. This is not really an octave bug. IT is a sort of gcc bug in combination with gentoo's slotting etc. . I assume toolchain needs to look into this, because knowledge of the whole toolchain etc. will be needed. Here is what I found, did and what I think causes the whole problem: The error message about the undefined reference usually implies there's a lib linking problem, well at least some linkign issue. The named symbol is in libgfortran and as can be observed the symbol is versioned. Now while there are several slots of gcc installed, there are multiple libgfortran instances. On the system I inspeced the named versioned symbol only existed in the 4.6.x branch of gcc. Now here's the fun part: Even though the ABI changed, the actual version of the .so did not change. Because of this, I assume this is what happens: During the build of octave, when linking is done, the libgfortran of the active gcc is used. This version includes the symbol though. But other libs, that were linked to an older version ob libgfortran don't 'know' anything about this 'new' versioned symbol. What is a little weird though is this: When LD resolves the libs and links gfortran, it would resolve to the newest libgfortran (or the one active due to compiler selection). This libgfortran would then be used. That would work perfectly well, as long as the API and ABI are the same. The fact it does not work made me think it has to be an ABI problem. So I started rebuilding every package linked against gfortran and then reemerge octave after each of the packages. In my case arpack was the package that made the difference, if I am right, it could be any package linked against gfortran for others. It might even be, that the problem only occurs with libs linked against gfortran using some specific linker flags, that I cannot tell. So, revdep cannot solve the problem right now, since gfortran has the same versioning info and revdep itselfg cannot 'see' the ABI change. gcc-config needs to switch libgfortran otherwise different linker problems might occur in other cases. That's what makes me believe this needs to be investigated by toolchain, to find a work around that works for average users, except telling them to reemerge everything linked against libgfortran. I hope this can help in fixing this error, after switching to gcc-4.6 do a revdep-rebuild on libgfortran and you should be good to go as a temporary workaround. For the time being it might be wise to add an informational message to the ebuild. (In reply to comment #2) > I have here at least five systems, where I was able to emerge octave-3.6.2 > with x86_64-pc-linux-gnu-4.6.3 and three systems with the undefined > reference to _gfortran_transfer_integer_write@GFORTRAN_1.4. It looks like > the undefined reference to _gfortran_transfer_integer_write@GFORTRAN_1.4 > occurs on all systems, where I did not 'emerge -uvDNe system' after > gcc-upgrade. I would be interested in this: On the systems where octave does not build, what packages are listed for 'emerge -uvDNep system' and also for a revdep-rebuild libgfortran. Does only reemerging these packages that match both conditions fix the octave build issue? At "lynx", where I found the bug, 'emerge -uvDNe systems' just runs for several hours. At a second affected system ("grizzly") 'revdep-rebuild --library libgfortran' does not reemerge any package:
root@grizzly:/root(28)# revdep-rebuild --library libgfortran
* Configuring search environment for revdep-rebuild
* Environment mismatch from previous run, deleting temporary files...
* Checking reverse dependencies
* Packages containing binaries and libraries using libgfortran
* will be emerged.
* Collecting system binaries and libraries
* Generated new 1_files.rr
* Checking dynamic linking
[ 100% ]
* There are no dynamic links to libgfortran... All done.
I will attach the result of 'emerge -uvDNep system'
Created attachment 314969 [details]
The result of 'emerge -uvDNep system'
MY fault, I guess. Here's the exct command I used: revdep-rebuild -L libgfortran.so.3 -- -ptv For me this yields: [ebuild R ] sci-mathematics/octave-3.6.2 USE="X curl glpk gnuplot imagemagick opengl qhull qrupdate readline sparse zlib -doc -fftw -static-libs" 0 kB [ebuild R ] dev-lang/R-2.15.0 USE="X cairo java jpeg lapack nls openmp png readline tiff -bash-completion -doc -icu -minimal -perl -profile -static-libs -tk" 23,629 kB [ebuild R ] sci-libs/qrupdate-1.1.2 USE="-static-libs" 0 kB [ebuild R ] sci-libs/arpack-96-r3 USE="-doc -examples -mpi -static-libs" 0 kB [ebuild R ] sci-libs/lapack-reference-3.2.1-r1 USE="-doc" 0 kB [ebuild R ] sci-libs/blas-reference-20070226-r2 USE="-doc" 0 kB [ebuild R ] sci-libs/amd-2.2.3 USE="-doc -static-libs" 256 kB Where (of course) the interesting packages for a rebuild are: qrupdate, arpack, lapack, blas and amd. Looking at your system output, it might be, that rebuilding blas+lapack already worked in your case (on your systems where you rebuilt system with emptytree)h. (In reply to comment #5) > At "lynx", where I found the bug, 'emerge -uvDNe systems' just runs for > several hours. At a second affected system ("grizzly") 'revdep-rebuild > --library libgfortran' does not reemerge any package: > > root@grizzly:/root(28)# revdep-rebuild --library libgfortran > * Configuring search environment for revdep-rebuild > * Environment mismatch from previous run, deleting temporary files... > * Checking reverse dependencies > * Packages containing binaries and libraries using libgfortran > * will be emerged. > * Collecting system binaries and libraries > * Generated new 1_files.rr > * Checking dynamic linking > [ 100% ] > * There are no dynamic links to libgfortran... All done. > > > I will attach the result of 'emerge -uvDNep system' 'revdep-rebuild -L libgfortran.so.3 -- -ptv' yields: emerge --complete-graph=y --oneshot -ptv dev-lang/R:0 dev-perl/PDL:0 sci-chemistry/apbs:0 sci-chemistry/molrep:0 sci-chemistry/pdb2pqr:0 sci-libs/amd:0 sci-libs/arpack:0 sci-libs/atlas:0 sci-libs/cbflib:0 sci-libs/ccp4-libs:0 sci-libs/hdf5:0 sci-libs/pgplot:0 sci-libs/plplot:0 sci-libs/qrupdate:0 sci-libs/scipy:0 sci-mathematics/dataplot:0 sci-mathematics/octave:0 sci-physics/root:0 sys-cluster/openmpi:0 .......... These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild R ] sci-physics/root-5.32.03-r2::science USE="X doc emacs examples fftw fits graphviz kerberos ldap math mpi mysql odbc opengl openmp postgres python qt4 reflex ssl xft xml -afs -avahi -clarens -htmldoc -oracle (-prefix) -pythia6 -pythia8 -ruby -test -xinetd -xrootd" 0 kB [ebuild R ] sci-mathematics/dataplot-20090821 USE="X examples gd opengl" 0 kB [ebuild R ] sci-libs/scipy-0.10.1 USE="doc -test -umfpack" 0 kB [ebuild R ] sci-libs/pgplot-5.2.2-r4 USE="doc motif tk" 0 kB [ebuild R ] sci-chemistry/pdb2pqr-1.7.0-r2 USE="doc examples pdb2pka -opal" 0 kB [ebuild R ] sci-chemistry/molrep-11.0.03-r1 0 kB [ebuild R ] dev-lang/R-2.15.0 USE="X bash-completion cairo doc icu java jpeg lapack nls openmp perl png readline tiff tk -minimal -profile -static-libs" 0 kB [ebuild R ] sci-libs/plplot-5.9.9 USE="X cairo cxx doc examples fortran gd java jpeg latex lua ocaml octave pdf perl png python qhull qt4 svg tcl threads tk truetype wxwidgets -ada -d -dynamic -test" 0 kB [ebuild U ] sci-mathematics/octave-3.6.2 [3.6.1] USE="X curl doc fftw glpk gnuplot imagemagick opengl qhull qrupdate readline sparse zlib -static-libs" 0 kB [ebuild R ] sci-libs/qrupdate-1.1.2 USE="-static-libs" 0 kB [ebuild R ] sci-libs/ccp4-libs-6.1.3-r11 0 kB [ebuild R ] sci-chemistry/apbs-1.3-r2 USE="arpack doc examples openmp python tools -fetk -mpi -static-libs" 0 kB [ebuild R ] dev-perl/PDL-2.4.7 USE="fftw gsl -badval" 0 kB [ebuild R ] sci-libs/arpack-96-r3 USE="doc examples mpi -static-libs" 0 kB [ebuild R ] sci-libs/atlas-3.8.4::science USE="doc fortran lapack threads -static-libs" 0 kB [ebuild R ] sci-libs/hdf5-1.8.9-r1 USE="examples fortran mpi szip zlib -cxx -debug -fortran2003 -static-libs -threads" 0 kB [ebuild R ] sci-libs/cbflib-0.9.2.4 USE="doc -test" 0 kB [ebuild R ] sci-libs/amd-2.2.3 USE="doc -static-libs" 0 kB [ebuild R ] sys-cluster/openmpi-1.6-r1 USE="cxx fortran ipv6 romio threads -heterogeneous -mpi-threads -vt" OPENMPI_FABRICS="-dapl -knem -ofed -open-mx -psm -sctp" OPENMPI_OFED_FEATURES="-connectx-xrc -control-hdr-padding -dynamic-sl -failover -rdmacm" OPENMPI_RM="-pbs -slurm" 0 kB If I than run 'revdep-rebuild -L libgfortran.so.3 -- -tv', octave-3.6.2 is successfully emerged. But one day later octave-3.6.2-r1 fails to compile. I will file a separate bug for this. *** This bug has been marked as a duplicate of bug 420409 *** |
