emerging sci-libs/lapack-atlas-3.9.23-r3 fails Reproducible: Always Steps to Reproduce: 1.emerge sci-libs/lapack-atlas 2. 3. Actual Results: libtool: link: x86_64-pc-linux-gnu-ranlib .libs/liblapack.a libtool: link: rm -fr .libs/liblapack.lax libtool: link: ( cd ".libs" && rm -f "liblapack.la" && ln -s "../liblapack.la" "liblapack.la" ) make[1]: Leaving directory `/var/tmp/portage/sci-libs/lapack-atlas-3.9.23-r3/work/lapack-lite-3.1.1/SRC' make[1]: Entering directory `/var/tmp/portage/sci-libs/lapack-atlas-3.9.23-r3/work/lapack-lite-3.1.1' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/var/tmp/portage/sci-libs/lapack-atlas-3.9.23-r3/work/lapack-lite-3.1.1' [32;01m*[0m Copying liblapack.a/*.o to /var/tmp/portage/sci-libs/lapack-atlas-3.9.23-r3/work/lapack-lite-3.1.1/SRC [32;01m*[0m Copying liblapack.a/*.lo to /var/tmp/portage/sci-libs/lapack-atlas-3.9.23-r3/work/lapack-lite-3.1.1/SRC [32;01m*[0m Copying liblapack.a/.libs/*.o to /var/tmp/portage/sci-libs/lapack-atlas-3.9.23-r3/work/lapack-lite-3.1.1/SRC ../libtool: line 6413: cd: 64: No such file or directory libtool: link: warning: cannot determine absolute directory name of `64' /bin/grep: 64/libatlas.la: No such file or directory /bin/sed: can't read 64/libatlas.la: No such file or directory libtool: link: `64/libatlas.la' is not a valid libtool archive [31;01m*[0m ERROR: sci-libs/lapack-atlas-3.9.23-r3 failed: [31;01m*[0m Failed to create liblapack.la [31;01m*[0m [31;01m*[0m Call stack: [31;01m*[0m ebuild.sh, line 54: Called src_compile [31;01m*[0m environment, line 3741: Called die [31;01m*[0m The specific snippet of code: [31;01m*[0m ../libtool --mode=link --tag=F77 ${FORTRANC} ${LDFLAGS} "${BLAS_LIBS}" -latlas ${flibs} -o "${S_LAPACK}"/SRC/liblapack.la *.lo -rpath "${EPREFIX}/${RPATH}" || die "Failed to create liblapack.la"; [31;01m*[0m [31;01m*[0m If you need support, post the output of 'emerge --info =sci-libs/lapack-atlas-3.9.23-r3', [31;01m*[0m the complete build log and the output of 'emerge -pqv =sci-libs/lapack-atlas-3.9.23-r3'. [31;01m*[0m The complete build log is located at '/var/tmp/portage/sci-libs/lapack-atlas-3.9.23-r3/temp/build.log'. [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/sci-libs/lapack-atlas-3.9.23-r3/temp/environment'. [31;01m*[0m S: '/var/tmp/portage/sci-libs/lapack-atlas-3.9.23-r3/work/ATLAS' Expected Results: emerge successful Portage 2.1.8.3 (default/linux/amd64/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-gentoo-r6 x86_64) ================================================================= System uname: Linux-2.6.31-gentoo-r6-x86_64-Dual-Core_AMD_Opteron-tm-_Processor_2216-with-gentoo-1.12.13 Timestamp of tree: Fri, 23 Apr 2010 21:25:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p37 dev-java/java-config: 1.3.7-r1, 2.1.10 dev-lang/python: 2.5.4-r3, 2.6.4-r99 dev-python/pycrypto: 2.1.0_beta1 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.1.2, 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=opteron -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests ccache collision-protect distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="C" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--delete-after --timeout=500" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/desktop-effects /usr/local/portage/layman/science /usr/local/portage/layman/sunrise /usr/local/portage/layman/x11 /usr/local/portage/layman/sage-on-gentoo /usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d a52 aac aalib acl acpi alsa amd64 apache2 audiofile bash-completion berkdb bluetooth branding bzip2 cairo cdr cli consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr emboss encode exif fam firefox flac fortran gdbm gif gphoto2 gpm gstreamer gtk hal iconv ieee1394 imlib ipv6 java jpeg lcms ldap lesstif libnotify lm_sensors mad midi mikmod mmx mng modules motif mozilla mp3 mp4 mpeg mudflap multilib ncurses nls nptl nptlonly nsplugin ogg opengl openmp oss pam pango pcre pdf perl png ppds pppd python qt3support qt4 radius readline reflection sdl session spell spl sse sse2 ssl startup-notification svg sysfs tcl tcpd tiff tk truetype unicode usb vorbis x264 xcb xml xorg xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia fbdev vesa vga nv" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS --- I have the build log if needed. It is quite large. lapack-atlas-3.23-r2 builds just fine.
I have the same problem in amd64 too, and lapack-atlas-3.9.23-r2 compiles fine. It looks like a typo or something like that (because of the " cannot determine absolute directory name of `64'" error), so the solution might be easy, but I haven't look at it. And a little OT complain: blas-atlas and lapack-atlas are packages with a very long compilation time, because they have to do a lot of tests to tune the library. Even more, they need a preparation, because the frequency throttling must be disabled, and some services like the X server, mysql daemon and some others are better disabled too, for better performance. My complain is that recently there have been some bumps with only cosmetic changes, "forcing" every user to upgrade the library unnecessarily and walking through all that hassle or masking revisions. Please, stop doing that and silently bump if something that affect a couple of guys needs to be fixed, just like openoffice does.
Same problem here.
Please attach the full build.log.
(In reply to comment #1) > And a little OT complain: blas-atlas and lapack-atlas are packages with a very > long compilation time, because they have to do a lot of tests to tune the > library. Even more, they need a preparation, because the frequency throttling > must be disabled, and some services like the X server, mysql daemon and some > others are better disabled too, for better performance. My complain is that > recently there have been some bumps with only cosmetic changes, "forcing" every > user to upgrade the library unnecessarily and walking through all that hassle > or masking revisions. > > Please, stop doing that and silently bump if something that affect a couple of > guys needs to be fixed, just like openoffice does. Just to give an excuse, I am new to the business and still trying to find out what really needs a bump and what not. But sure, I will not bump it that much in the future. The reason I did was, that all those "cosmetic changes" broken the ebuild on different platforms and I just wanted to give one working solution to everyone. But truly that is not the correct way. I hope you won't kill me for that.
Created attachment 229195 [details] The full build log
Could you please attach /usr/lib64/blas/atlas/libblas.la?
(In reply to comment #6) > Could you please attach /usr/lib64/blas/atlas/libblas.la? Good catch. The libblas.la file from lapack-atlas-3.9.23 that I had installed previously contains the line dependency_libs=' -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/gcc/x86_64-pc-linux-gnu/4.5.0/libgfortran.la64/libatlas.la -lpthread -lm' I have no idea how that could have happened. A bug in fix_libtool_files.sh? But in any case, a corrupt .la file that was installed by a previous version of the library should not prevent the user from rebuilding the library; the build process should completely ignore files from the lapack-atlas that was already installed.
(In reply to comment #7) > (In reply to comment #6) > > Could you please attach /usr/lib64/blas/atlas/libblas.la? > > Good catch. The libblas.la file from lapack-atlas-3.9.23 that I had installed > previously contains the line > > dependency_libs=' > -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/gcc/x86_64-pc-linux-gnu/4.5.0/libgfortran.la64/libatlas.la > -lpthread -lm' > > I have no idea how that could have happened. A bug in fix_libtool_files.sh? > > But in any case, a corrupt .la file that was installed by a previous version of > the library should not prevent the user from rebuilding the library; the build > process should completely ignore files from the lapack-atlas that was already > installed. > But that one is from blas-atlas and not from lapack. I am not sure whether it is a problem with the PREFIX fix for or something else. Could you please fix the corrupted .la file by hand and see whether it fixes your lapack problem?
(In reply to comment #8) > > But that one is from blas-atlas and not from lapack. I am not sure whether it > is a problem with the PREFIX fix for or something else. Could you please fix > the corrupted .la file by hand and see whether it fixes your lapack problem? > Running lafilefixer --justfixit seemed to resolve the issue. I believe I recall reading a cryptic bug report suggesting this as a solution?
Created attachment 229259 [details] full build log for blas-atlas-3.9.23-r3 The corrupt /usr/lib64/blas/atlas/libblas.la file that causes this bug is generated directly by blas-atlas-3.9.23-r3 (tested on two different machines after uninstalling blas-atlas and lapack-atlas); fix_libtool_files.sh is not at fault. The build log for blas-atlas-3.9.23-r3 is attached. (In reply to comment #9) > Running lafilefixer --justfixit seemed to resolve the issue. Not for me. Here, lafilefixer turns the corrupt line into a different, but equally corrupt line: dependency_libs=' -L-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/gcc/x86_64-pc-linux-gnu/4.5.0/libgfortran.la64 -latlas -lpthread -lm'
(In reply to comment #10) > Created an attachment (id=229259) [details] > full build log for blas-atlas-3.9.23-r3 > > The corrupt /usr/lib64/blas/atlas/libblas.la file that causes this bug is > generated directly by blas-atlas-3.9.23-r3 (tested on two different machines > after uninstalling blas-atlas and lapack-atlas); fix_libtool_files.sh is not at > fault. > > The build log for blas-atlas-3.9.23-r3 is attached. > > (In reply to comment #9) > > Running lafilefixer --justfixit seemed to resolve the issue. > > Not for me. Here, lafilefixer turns the corrupt line into a different, but > equally corrupt line: > > dependency_libs=' > -L-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/gcc/x86_64-pc-linux-gnu/4.5.0/libgfortran.la64 > -latlas -lpthread -lm' > You are correct. That's what I get as well; although lapack-atlas does install here. At least if I don't install blas-atlas again.
Does it work with gcc-4.* which is not masked, because I cannot reproduce this bug.
(In reply to comment #12) > Does it work with gcc-4.* which is not masked, because I cannot reproduce this > bug. > OK, I started from scratch. I installed version 3.9.23-r2 of both blas-atlas and lapack-atlas. Both installed and blas-atlas installs the file /usr/lib64/blas/threaded-atlas/libblas.la that has the line dependency_libs=' -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libgfortran.la /usr/lib64/libatlas.la -lpthread -lm' I then installed blas-atlas-3.9.23-r3 which installed libblas.la with the line dependency_libs=' -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/gcc/x86_64-pc-linux-gnu/4.3.4/libgfortran.la64/libatlas.la -lpthread -lm' and lapack-atlas-3.9.23-r3 will not build. The issue is the same as that of the initial post of this bug. Now blas-atlas-3.9.23-r3 also installs /usr/lib64/blas/threaded-atlas/libcblas.la which has the line dependency_libs='64/libatlas.la -lpthread -lm' I don't know what blas-atlas-3.9.23-r2 installs in libcblas.la. When I run lafilefixer --justfixit the dependency_libs line in libblas.la gets mangled to dependency_libs=' -L-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/gcc/x86_64-pc-linux-gnu/4.3.4/libgfortran.la64 -latlas -lpthread -lm' and the dependency line in libcblas.la gets changed to dependency_libs=' -L64 -latlas -lpthread -lm' and lapack-atlas will build; although runtime linking may be messed up. Perhaps the problem is with libcblas.la? Note: my gcc is 4.3.4 (see my emerge --info at the beginning of this bug)
(In reply to comment #12) > Does it work with gcc-4.* which is not masked I just emerged blas-atlas-3.9.23-r3 with gcc-4.4.3-r2 and got the same corrupt libblas.la file: # Libraries that this one depends upon. dependency_libs=' -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/gcc/x86_64-pc-linux-gnu/4.4.3/libgfortran.la64/libatlas.la -lpthread -lm'
Okay, I see what I broke. I will not mask nor remove the blas-atlas -r3 to not force recompile, but it is broken. Thanks for the detailed debugging. Give me a day I will fix that.
I just commited a fix for the broken .la. could you sync later and test it. I didn't do a rev bump so please wait until you can be sure your server is in sync with the dev tree (approx. 2h).
*** Bug 317093 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > I just commited a fix for the broken .la. could you sync later and test it. I > didn't do a rev bump so please wait until you can be sure your server is in > sync with the dev tree (approx. 2h). > Things look good here. Both blas-atlas and lapack-atlas (3.9.23-r3) install and the .la files (libblas.la && libcblas.la) look correct. Thanks.
(In reply to comment #16) > I just commited a fix for the broken .la. could you sync later and test it. I > didn't do a rev bump so please wait until you can be sure your server is in > sync with the dev tree (approx. 2h). Thank you, everything works now! PS. I know some people have said they don't like frequent revision number bumps, but whenever you make a change the ebuild, could you please at least add an entry to the changelog? Otherwise, people who have encountered a problem and aren't on the bug's CC list will have no idea that anything has been done to address it.
(In reply to comment #19) > (In reply to comment #16) > > I just commited a fix for the broken .la. could you sync later and test it. I > > didn't do a rev bump so please wait until you can be sure your server is in > > sync with the dev tree (approx. 2h). > > Thank you, everything works now! > > PS. I know some people have said they don't like frequent revision number > bumps, but whenever you make a change the ebuild, could you please at least add > an entry to the changelog? Otherwise, people who have encountered a problem and > aren't on the bug's CC list will have no idea that anything has been done to > address it. > I am sorry, but we will have another bump. And with that a ChangeLog entry for the fix.
+*blas-atlas-3.9.23-r4 (28 Apr 2010) + + 28 Apr 2010; Justin Lecher <jlec@gentoo.org> -blas-atlas-3.9.23-r3.ebuild, + +blas-atlas-3.9.23-r4.ebuild: + Fixes installation of broken .la files, #316863 +
Seems to be fixed in -r4
