Per the summary: install .libs/libcblas.so.0.0.0 /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.so.0.0.0 x86_64-pc-linux-gnu-strip --strip-unneeded /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.so.0.0.0 (cd /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs && { ln -s -f libcblas.so.0.0.0 libcblas.so.0 || { rm -f libcblas.so.0 && ln -s libcblas.so.0.0.0 libcblas.so.0; }; }) (cd /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs && { ln -s -f libcblas.so.0.0.0 libcblas.so || { rm -f libcblas.so && ln -s libcblas.so.0.0.0 libcblas.so; }; }) install .libs/libcblas.lai /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.la install .libs/libcblas.a /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.a x86_64-pc-linux-gnu-strip --strip-debug /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.a x86_64-pc-linux-gnu-ranlib /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.a chmod 644 /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.a libtool: install: warning: remember to run `libtool --finish /usr/lib/blas/atlas' make[1]: Leaving directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS' >>> Test phase [not enabled]: sci-libs/blas-atlas-3.6.0 >>> Install blas-atlas-3.6.0 into /var/tmp/portage/blas-atlas-3.6.0/image/ category sci-libs man: prepallstrip: strip: x86_64-pc-linux-gnu-strip --strip-unneeded usr/lib/blas/atlas/libcblas.so.0.0.0 usr/lib/blas/atlas/libblas.so.0.0.0 usr/lib/libatlas.so.0.0.0 making executable: /usr/lib/libatlas.so.0.0.0 QA Notice: the following files contain insecure RUNPATH's Please file a bug about this at http://bugs.gentoo.org/ For more information on this issue, kindly review: http://bugs.gentoo.org/81745 /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs usr/lib/blas/atlas/libcblas.so.0.0.0 /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs usr/lib/blas/atlas/libblas.so.0.0.0 !!! ERROR: sci-libs/blas-atlas-3.6.0 failed. !!! Function dyn_install, Line 1057, Exitcode 0 !!! Insecure binaries detected !!! If you need support, post the topmost build error, NOT this status message. Portage 2.0.53 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r3, 2.6.14-gentoo-r3 x86_64) ================================================================= System uname: 2.6.14-gentoo-r3 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.12.0_pre11 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe -fweb -ftracer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=k8 -O2 -pipe -fweb -ftracer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks multilib-strict sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/etc/portage/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X alsa apache2 audiofile avi berkdb bitmap-fonts bzip2 cddb cdr cli crypt cups dba directfb dts dv dvd dvdr dvdread eds emacs emboss encode esd exif expat fam fame fbcon ffmpeg firefox foomaticdb fortran gcj gd gdbm gif glut gpm gstreamer gtk gtk2 idn ieee1394 imagemagick imlib ipv6 java jikes jpeg junit lcms ldap libwww lirc live lzw lzw-tiff mad mjpeg mng motif mozilla mp3 mpeg ncurses nls nptl nptlonly nsplugin nvidia ogg oggvorbis opengl pam pcre pdflib perl png python qt quicktime readline real rtc sdl spell ssl tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales v4l v4l2 vorbis xine xml2 xmms xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
*** Bug 116000 has been marked as a duplicate of this bug. ***
I don't have a solution to the problem but some comments and a workaround that worked for me. I. Affected systems # My system: Portage 2.0.53 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-gentoo-r5 i686) sys-devel/libtool: 1.5.20 # reporter: Portage 2.0.53 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r3, 2.6.14-gentoo-r3 x86_64) sys-devel/libtool: 1.5.20-r1 # http://bugs.gentoo.org/show_bug.cgi?id=81745 gentoo ppc (g4) running latest portage and emerge to this day: 15/12/2005 Interestingly, blas-atlas was installed on my system, without problems, on Dec 19 after gcc upgrade and emerge -e world about 2 days earlier that is 17 Dec. Now if I follow procedure described below it fails. I have observed the bug (Dec 26) on other machine that I have upgraded gcc and emerged -e world on 23 Dec. So one can guess that the bug was introduced between 17 and 26 Dec for stable brach of x86. II. How to reproduce You can not reproduce this bug if you have blas-atlas already installed in the system, thus: 0. update your system... 1. quickpkg blas-atlas # back up the version you have 2. emerge -C blas-atlas # this will break dependencies so do this only on development machines! 3. emerge blas-atlas # should fail 4. emerge --usepkg blas-atlas # reinstall binary package 5. emerge blas-atlas # should go without problem III. Workaround If you don't have a binary package try: touch /usr/lib/libatlas.so before emerging blas-atlas. IV. Bug The bug is a result of the improper result of execution of the following line in the src_compile function in blas-atlas-3.6.0.ebuild: make shared-strip arch=${ATLAS_ARCH} RPATH=${RPATH}/atlas || die The relevant sections of Make.top are: shared-strip: INSTALLER = install -s shared-strip: RPATH = /usr/lib/blas/atlas shared-strip: libatlas.so libblas.so libcblas.so libatlas.so: mkdir -p gentoo/libs @echo @echo Linking a really big library, please be patient... @echo cd gentoo/libatlas.a ; \ libtool --mode=link --tag=CC $(CC) -o libatlas.la *.lo -rpath /usr/lib ; \ libtool --mode=install $(INSTALLER) libatlas.la $(TOPdir)/gentoo/libs libblas.so: cd gentoo/libf77blas.a ; \ libtool --mode=link --tag=CC $(CC) -o libblas.la ../libs/libatlas.la *.lo \ -rpath $(RPATH) -lg2c ; \ libtool --mode=install $(INSTALLER) libblas.la $(TOPdir)/gentoo/libs Below is a fragment of portage log: [...] Linking a really big library, please be patient... cd gentoo/libatlas.a ; \ libtool --mode=link --tag=CC /usr/bin/gcc -o libatlas.la *.lo -rpath /usr/lib ; \ libtool --mode=install install -s libatlas.la /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs creating reloadable object files... creating a temporary reloadable object file: .libs/libatlas.la-3.o /usr/i686-pc-linux-gnu/bin/ld -r -o .libs/libatlas.la-1.o .libs/ATL_buildinfo.o [...] .libs/ATL_dtrsmKLUNU.o /usr/i686-pc-linux-gnu/bin/ld -r -o .libs/libatlas.la-2.o .libs/ATL_dtrsmKRLNN.o [...] .libs/libatlas.la-1.o /usr/i686-pc-linux-gnu/bin/ld -r -o .libs/libatlas.la-3.o .libs/ATL_zrefsyr2kLT.o [...] .libs/libatlas.la-2.o i686-pc-linux-gnu-gcc -shared .libs/libatlas.la-3.o -Wl,-soname -Wl,libatlas.so.0 -o .libs/libatlas.so.0.0.0 rm -f .libs/libatlas.la-1.o .libs/libatlas.la-2.o .libs/libatlas.la-3.o (cd .libs && rm -f libatlas.so.0 && ln -s libatlas.so.0.0.0 libatlas.so.0) (cd .libs && rm -f libatlas.so && ln -s libatlas.so.0.0.0 libatlas.so) using piecewise archive linking... i686-pc-linux-gnu-ar cru .libs/libatlas.a ATL_buildinfo.o [...] ATL_sreftpmvUTN.o : .libs/libatlas.a i686-pc-linux-gnu-ar cru .libs/libatlas.a ATL_sreftpmvUTU.o [...] ATL_zupNBmm_bX.o i686-pc-linux-gnu-ranlib .libs/libatlas.a creating libatlas.la (cd .libs && rm -f libatlas.la && ln -s ../libatlas.la libatlas.la) install .libs/libatlas.so.0.0.0 /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.so.0.0.0 i686-pc-linux-gnu-strip --strip-unneeded /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.so.0.0.0 (cd /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs && { ln -s -f libatlas.so.0.0.0 libatlas.so.0 || { rm -f libatlas.so.0 && ln -s libatlas.so.0.0.0 libatlas.so.0; }; }) (cd /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs && { ln -s -f libatlas.so.0.0.0 libatlas.so || { rm -f libatlas.so && ln -s libatlas.so.0.0.0 libatlas.so; }; }) install .libs/libatlas.lai /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.la install .libs/libatlas.a /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.a i686-pc-linux-gnu-strip --strip-debug /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.a i686-pc-linux-gnu-ranlib /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.a chmod 644 /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.a libtool: install: warning: remember to run `libtool --finish /usr/lib' cd gentoo/libf77blas.a ; \ libtool --mode=link --tag=CC /usr/bin/gcc -o libblas.la ../libs/libatlas.la *.lo \ -rpath /usr/lib/blas/atlas -lg2c ; \ # # Here is the problem: libtool adds incorrect rpath: # libtool --mode=install install -s libblas.la /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs libtool: link: warning: library `../libs/libatlas.la' was moved. i686-pc-linux-gnu-gcc -shared .libs/ATL_F77wrap_caxpy.o [...] .libs/ztrsv.o -Wl,--rpath -Wl,/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs -Wl,--rpath -Wl,/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs ../libs/libatlas.so -lg2c -Wl,-soname -Wl,libblas.so.0 -o .libs/libblas.so.0.0.0 # # # (cd .libs && rm -f libblas.so.0 && ln -s libblas.so.0.0.0 libblas.so.0) (cd .libs && rm -f libblas.so && ln -s libblas.so.0.0.0 libblas.so) i686-pc-linux-gnu-ar cru .libs/libblas.a ATL_F77wrap_caxpy.o [...] ztrsv.o i686-pc-linux-gnu-ranlib .libs/libblas.a creating libblas.la (cd .libs && rm -f libblas.la && ln -s ../libblas.la libblas.la) install .libs/libblas.so.0.0.0 /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libblas.so.0.0.0 i686-pc-linux-gnu-strip --strip-unneeded /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libblas.so.0.0.0 (cd /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs && { ln -s -f libblas.so.0.0.0 libblas.so.0 || { rm -f libblas.so.0 && ln -s libblas.so.0.0.0 libblas.so.0; }; }) (cd /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs && { ln -s -f libblas.so.0.0.0 libblas.so || { rm -f libblas.so && ln -s libblas.so.0.0.0 libblas.so; }; }) install .libs/libblas.lai /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libblas.la install .libs/libblas.a /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libblas.a i686-pc-linux-gnu-strip --strip-debug /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libblas.a i686-pc-linux-gnu-ranlib /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libblas.a chmod 644 /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libblas.a libtool: install: warning: remember to run `libtool --finish /usr/lib/blas/atlas' cd gentoo/libcblas.a ; \ [...] # similar problem for cblas This is the fragment of /usr/bin/libtool that prints the warning: # Find the relevant object directory and library name. if test "X$installed" = Xyes; then if test ! -f "$libdir/$linklib" && test -f "$abs_ladir/$linklib"; then $echo "$modename: warning: library \`$lib' was moved." 1>&2 dir="$ladir" absdir="$abs_ladir" libdir="$abs_ladir" else dir="$libdir" absdir="$libdir" fi test "X$hardcode_automatic" = Xyes && avoidtemprpath=yes else and corresponding output of libtool --debug which explains that workaround is working by making test ! -f "$libdir/$linklib" fail: + laname=libatlas.la + test Xyes = Xyes + test '!' -f /usr/lib/libatlas.so + test -f /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libatlas.so + echo 'libtool: link: warning: library `../libs/libatlas.la'\'' was moved.' libtool: link: warning: library `../libs/libatlas.la' was moved. + dir=../libs + absdir=/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs + libdir=/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs V. Status I think that this bug should get some more attention and maybe be marked as such. blas-atlas is an important dependence for many scientific applications. From my point of view, system without working BLAS and LAPACK is useless. One could install blas-reference instead but this is not the right solution and blas-atlas is a default for virtual/blas in current profile. I am not sure if security@gentoo.org is a correct assignment either. My system: Portage 2.0.53 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-gentoo-r5 i686) ================================================================= System uname: 2.6.14-gentoo-r5 i686 AMD Sempron(tm) 3000+ Gentoo Base System version 1.6.13 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=athlon-xp -mfpmath=sse -mmmx -msse -m3dnow -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -mfpmath=sse -mmmx -msse -m3dnow -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://src.gentoo.pl http://gentoo.prz.rzeszow.pl http://gentoo.zie.pg.gda.pl http://gentoo.po.opole.pl ftp://gentoo.po.opole.pl http://stoofo.math.uni.lodz.pl/gentoo/ ftp://stoofo.math.uni.lodz.pl/" LINGUAS="pl en de fr it ru ar" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow X Xaw3d a52 aac alsa apm arts audiofile avi berkdb bidi bitmap-fonts blas bonobo bzip2 cdparanoia cdr crypt cscope ctype cups curl dbm dts dv dvb dvd dvdr dvdread eds emacs emboss encode esd exif expat fam fbcon ffmpeg fftw flac foomaticdb fortran gb gdbm gif ginac glut gmp gnome gphoto2 gpm gps gstreamer gtk gtk2 gtkhtml guile idn ieee1394 imagemagick imlib ipv6 jack java jpeg kde lapack lcms libg++ libgda libwww lm_sensors mad matroska mbox mhash mikmod mime mmx mng mnogosearch mono motif mozilla mp3 mpeg msql mule ncurses netcdf nis nls nsplugin ocaml odbc ogg oggvorbis openal opengl oss pam pcre pdflib perl php plotutils png portaudio postgres python qt quicktime readline recode ruby samba scanner sdl sndfile speex spell spl sse ssl svg szip tcltk tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vhosts vorbis win32codecs wmf wxwindows xine xinerama xml2 xmms xosd xpm xv zeo zlib linguas_pl linguas_en linguas_de linguas_fr linguas_it linguas_ru linguas_ar userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS
*** Bug 117746 has been marked as a duplicate of this bug. ***
I just compiled blas-atlas-3.6.0 on my P4 using gcc-3.4.5 and I do not have any insecure runpaths and the package installs just fine. Just to make sure, could you please try recompiling with somewhat more conservative CFLAGS, e.g. "-O2 -march=athlon-xp". Thanks, Markus
(In reply to comment #4) > I just compiled blas-atlas-3.6.0 on my P4 using gcc-3.4.5 and I do not have any > insecure runpaths and the package installs just fine. Was it your first instalation of blas-atlas? (See Comment 2 above) > Just to make sure, could you please try recompiling with somewhat more > conservative CFLAGS, e.g. "-O2 -march=athlon-xp". I think CFLAGS are not a problem, but I can try. It will take several hours...
> > Just to make sure, could you please try recompiling with somewhat more > > conservative CFLAGS, e.g. "-O2 -march=athlon-xp". > > I think CFLAGS are not a problem, but I can try. It will take several hours... Emerge finished with: [...] install .libs/libcblas.lai /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.la install .libs/libcblas.a /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.a i686-pc-linux-gnu-strip --strip-debug /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.a i686-pc-linux-gnu-ranlib /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.a chmod 644 /var/tmp/portage/blas-atlas-3.6.0/work/ATLAS/gentoo/libs/libcblas.a libtool: install: warning: remember to run `libtool --finish /usr/lib/blas/atlas' make[1]: Leaving directory `/var/tmp/portage/blas-atlas-3.6.0/work/ATLAS' >>> Test phase [not enabled]: sci-libs/blas-atlas-3.6.0 >>> Install blas-atlas-3.6.0 into /var/tmp/portage/blas-atlas-3.6.0/image/ category sci-libs man: prepallstrip: strip: i686-pc-linux-gnu-strip --strip-unneeded usr/lib/blas/atlas/libcblas.so.0.0.0 usr/lib/blas/atlas/libblas.so.0.0.0 usr/lib/libatlas.so.0.0.0 Then I tried: alkor ~ # ebuild /usr/portage/sci-libs/blas-atlas/blas-atlas-3.6.0.ebuild install Which gave the insecure RUNPATH's error. The problem seems to be rather in an incorrect behavior/calling of libtool which adds -Wl,--rpath -Wl,/var/tmp/portage to gcc invocation. This has nothing to do with optimisation flags. I repeat: YOU NEED TO UNMERGE blas-atlas TO REPRODUCE THIS BUG. If you have one, of course. This is unfortunate because this big hits only new users...
Created attachment 76342 [details, diff] updated patch to avoid insecure runpaths in shared libs Hi Jaroslaw, The attached updated patch fixes these RUNAPTH issues on my box. Unfortunately, libtool insists on adding /var/tmp/... to RPATH if libatlas.so isn't already present in /usr/lib. Hence, the updated patch currently re-links the shared libraries with the proper rpaths after libtool is finished, circumventing this problem. Please give it a shot and report back. Thanks, Markus
(In reply to comment #7) Hi Markus, Compilation and merging on my system were successful. I got ussual QA warning about executable stack in usr/lib/libatlas.so.0.0.0, but library seems to be working nonetheless. Thanks for fixing, Jaroslaw Kalinowski
Hi Jaroslaw, Thanks for testing! I just committed blas-atlas-3.6.0-r1 to portage which includes the updated patch and should take care of the insecure RUNPATH issues. security@g.o folks, is it ok to close this bug?
arches, please test and mark stable, thx. markusle: as you see, we first need to mark the fixed packages stable and decide if we issue a glsa about this or not - but you can relax now, since your job is probably done here, thx for the efforts.
x86 done
Fails to compile on PPC with the following error message: libtool --mode=link --tag=CC /usr/bin/gcc -o libblas.la ../libs/libatlas.la *.lo \ -rpath /usr/lib/blas/atlas -lg2c ; \ rm -f .libs/libblas.so.0.0.0; \ /usr/bin/gcc --shared .libs/*.o -lg2c /var/tmp/portage/blas-atlas-3.6.0-r1/work/ATLAS/gentoo/libs/libatlas.so -Wl,-soname -Wl,libblas.so.0 -o .libs/libblas.so.0.0.0; \ libtool --mode=install install -s libblas.la /var/tmp/portage/blas-atlas-3.6.0-r1/work/ATLAS/gentoo/libs /bin/sh: line 0: cd: gentoo/libf77blas.a: No such file or directory libtool: link: `*.lo' is not a valid libtool object gcc: .libs/*.o: No such file or directory libtool: install: `libblas.la' is not a valid libtool archive Try `libtool --help --mode=install' for more information. make[1]: *** [libblas.so] Error 1 make[1]: Leaving directory `/var/tmp/portage/blas-atlas-3.6.0-r1/work/ATLAS' make: *** [shared-strip] Error 2
Back to ebuild status, we need a fix for ppc.
(In reply to comment #12) > Fails to compile on PPC with the following error message: > /bin/sh: line 0: cd: gentoo/libf77blas.a: No such file or directory Unfortunately, I can't test on ppc but it looks like the ebuild doesn't build the fortran blas routines for some reason. If so, this shouldn't be caused by the updated patch which doesn't touch this part at all. Would the ppc folks please be able to confirm that the current stable version (blas-atlas-3.6.0) compiles properly so I can pin down the cause of the problem? Thanks a lot, Markus
(In reply to comment #14) > Would the ppc folks please be able to confirm that the current stable > version (blas-atlas-3.6.0) compiles properly so I can pin down the cause of the > problem? blas-atlas-3.6.0 also doesn't compile (breaks with exactly the same error message), I'll try to get this tested by another ppc developer.
One more thing: currently the latest ~x86 version of blas-atlas is 3.7.11, however in the same time latest lapack-atlas requires =blas-atlas-3.6.0. I think that the bug that prevented correct linking of blas-atlas in the first place, is not in the an ebuild issue but a problem somewhere in the toolchain. It would be nice to know what was the cause...
(In reply to comment #15) > > blas-atlas-3.6.0 also doesn't compile (breaks with exactly the same error > message), I'll try to get this tested by another ppc developer. > Hi Tobias, Thanks a lot for testing and now I at least know that there's a problem even with the stable branch. If this is at all possible for you, it would be great if you could tarball your /var/tmp/portage/blas-atlas-3.6.0 directory and make it available for me somewhere to download. blas-atlas has assembly routines that have been broken for me in the past and it could be that it fails somewhere during building libf77blas but continues anyway such that these files are missing during linking in the end. I'll post to sci@g.o and see if somebody there has a ppc machine and can test. @ Jaroslaw: Thanks for noting the dependency issues with lapack-atlas. I (hope) I resolved them all yesterday. Please have a look at bug #118521. Thanks, Markus
It'll be available at http://www.scherbaum.info/~tobias/gentoo/gentoo/ppc/blas-atlas-failure.tar.bz2 in about an hour, still uploading atm ...
on Tobias' request i've emerged it also on ppc here is the output: libtool --mode=install install -s libblas.la /var/tmp/portage/blas-atlas-3.7.11/work/ATLAS/gentoo/libs /bin/sh: line 0: cd: gentoo/libf77blas.a: No such file or directory libtool: link: `*.lo' is not a valid libtool object gcc: .libs/*.o: No such file or directory distcc[16607] ERROR: compile (null) on localhost failed libtool: install: `libblas.la' is not a valid libtool archive Try `libtool --help --mode=install' for more information. make[1]: *** [libblas.so] Error 1 make[1]: Leaving directory `/var/tmp/portage/blas-atlas-3.7.11/work/ATLAS' make: *** [shared-strip] Error 2 !!! ERROR: sci-libs/blas-atlas-3.7.11 failed. !!! Function src_compile, Line 107, Exitcode 2 !!! Failed to build shared libraries !!! If you need support, post the topmost build error, NOT this status message. sudo emerge blas-atlas 14198.08s user 1718.58s system 61% cpu 7:08:08.15 total this is my emerge info: SeJo@powke % emerge info ~ Portage 2.0.53_rc7 (default-linux/ppc/2005.0, gcc-3.4.4, glibc-2.3.5-r3, 2.6.15-gentoo ppc) ================================================================= System uname: 2.6.15-gentoo ppc 7447/7457, altivec supported Gentoo Base System version 1.12.0_pre10 distcc 2.18.3 powerpc-unknown-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.6.3, 1.7.9-r1, 1.8.5-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="ppc ~ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -pipe -mcpu=7400 -maltivec -mabi=altivec " CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -fno-strict-aliasing -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect cvs keeptemp keepwork sandbox sfperms sign strict" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/gentoo-x86" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="ppc X aalib alsa altivec apache2 audiofile berkdb bitmap-fonts browserplugin bzip2 ccache cdr crypt cups curl dba debug dts emboss esd ethereal exif expat fam fbcon ffmpeg flac foomaticdb fortran gd gdbm gif glut gmp gpm gstreamer gtk gtk2 idn imagemagick imlib insecure-drivers ipv6 java jpeg junit lcms ldap libwww mad mbox mhash mikmod mng motif mozilla mp3 mpeg mysql ncurses nls nptl nptlonly ogg oggvorbis openal opengl pam pcre pdflib perl php png postgres ppds python qt radeon readline recode samba sdl spell sqlite ssh ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis xine xml2 xmms xv zlib video_cards_radeon userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
(In reply to comment #18) > It'll be available at > http://www.scherbaum.info/~tobias/gentoo/gentoo/ppc/blas-atlas-failure.tar.bz2 > in about an hour, still uploading atm ... Ups, its http://www.scherbaum.info/~tobias/gentoo/ppc/blas-atlas-failure.tar.bz2 Anyways .. whats next? Do we drop our stable keyword or is there enough time to wait until this problem is fixed?
(In reply to comment #20) > (In reply to comment #18) > > It'll be available at > > http://www.scherbaum.info/~tobias/gentoo/gentoo/ppc/blas-atlas-failure.tar.bz2 > > in about an hour, still uploading atm ... > > Ups, its > http://www.scherbaum.info/~tobias/gentoo/ppc/blas-atlas-failure.tar.bz2 > > Anyways .. whats next? Do we drop our stable keyword or is there enough time to > wait until this problem is fixed? > Hi Tobias, Thank you very much for the tarball. I had a look and, indeed, one of the files didn't compile. More specifically ---------------- snip ------------------------------------------------- /usr/bin/gcc -DL2SIZE=4194304 -I/var/tmp/portage/blas-atlas-3.6.0-r1/work/ATLAS/include -I/var/tmp/portage/blas-atlas-3.6.0-r1/work/ATLAS/include/Linux_UNKNOWNAltiVec -I/var/tmp/portage/blas-atlas-3.6.0-r1/work/ATLAS/include/contrib -DAdd__ -DStringSunStyle -DATL_OS_Linux -DATL_AltiVec -DATL_AVgcc -DATL_GAS_LINUX_PPC -DATL_UCLEANM -DATL_UCLEANN -DATL_UCLEANK -c -Os -mcpu=7450 -maltivec -mabi=altivec -mpowerpc-gfxopt -pipe ATL_zupKBmm_b0.c -fPIC -DPIC -o .libs/ATL_zupKBmm_b0.o ATL_zupKBmm_b0.c: In function `ATL_zpKBmm_b0': ATL_zupKBmm_b0.c:65: error: parse error before "else" ATL_zupKBmm_b0.c: At top level: ATL_zupKBmm_b0.c:68: error: parse error before '}' token ATL_zupKBmm_b0.c:71: error: parse error before '(' token ATL_zupKBmm_b0.c:71: error: parse error before '(' token ATL_zupKBmm_b0.c:71: error: parse error before '(' token ------------------------------------------------------------------------------ the reason being an improperly expanded macro giving rise to the following bad piece of code --------------------------- snip ---------------------------------------------- void ATL_zpKBmm_b0 (const int M, const int N, const int K, const double alpha, const double *A, const int lda, const double *B, const int ldb, const double beta, double *C, const int ldc) { else { ATL_ZupKBmm1_1_1_b0(M, N, K, alpha, A, lda, B, ldb, beta, C, ldc); } else if (K == (((((K) >> 1)) << 1))) { ATL_ZupKBmm0_2_0_b0(M, N, K, alpha, A, lda, B, ldb, beta, C, ldc); } } -------------------------------------------------------------------------------------------- Unfortunately, I haven't been able to track down yet, where this comes from. Maybe I can catch it. Furthermore, I noticed that you compiled blas-atlas with -Os. Even though I do not think that this has anything to do with the compile failure, it would be great if you could try it with -O, just to make sure. Regarding dropping the stable keyword, I'd personally prefer to wait some more, particularly since blas-atlas is a dependency for quite a few sci related packages. @ Jochen Maes: Thank you very much for testing. It looks like you compiled the unstable branch (3.7.11) instead of 3.6.0. In any case, the error looks similar, but it would be great if you could 3.6.0 a shot. Thank you both very much for your help, Markus
(In reply to comment #21) > Furthermore, I noticed that you compiled blas-atlas with -Os. Even though > I do not think that this has anything to do with the compile failure, it would > be great if you could try it with -O, just to make sure. I'll try that overnight ...
Ok ... it was a long night :P Using -O instead of -Os it also fails to build, but at another point with a different error message. Shall I upload the tempdir once again?
(In reply to comment #23) > Shall I upload the tempdir once again? > Thanks a lot and that would be great. I'll have another look and maybe I can figure out where things go wrong. If not, I'm afraid we'll have to go ~ppc and I'll file a bug upstream since it seems to be a problem with blas' configuration procedure.
(In reply to comment #24) > Thanks a lot and that would be great. I'll have another look and maybe > I can figure out where things go wrong. http://www.scherbaum.info/~tobias/gentoo/ppc/blas-atlas-failure-2.tar.bz2
Hi Tobias, I had a look at the files and it is pretty much the same problem as before: some bad compile time generated piece of code that bombs the build. Even though I know what routine is responsible for it I don't think I can debug this without a ppc machine at hand. Hence I suggest that I file a bug with upstream regarding ppc and I leave it up to you ppc folks to package mask blas-atlas on ppc for now or whatever you deem appropriate. In this respect it would be great if you could recompile blas-atlas one more time with the default blas-atlas CFLAGS, otherwise upstream will complain. To do this, simply comment the "reconfigure" step in line 105 of the blas-atlas-3.6.0.ebuild. Thank you very much for your help. @security.g.o: Could we proceed stabilizing blas-atlas-3.6.0-r1 on the other arches since ppc seems to be broken at the moment.
sparc, alpha and amd64 should test and mark 3.6.0-r1 stable
And now without forgetting to add the cc:
All ebuilds marked as -ppc. @Markus: You open a new bug if you have feedback from upstream or need us for testing?
(In reply to comment #29) > All ebuilds marked as -ppc. > > @Markus: > You open a new bug if you have feedback from upstream or need us for testing? > Thanks Tobias! I'll open a new bug once I've heard from upstream. Before I contact them it would be great, however, if you could recompile blas-atlas without the reconfigure step in the ebuild (see comment 26) to build it with the native settings and provide me with the compile tarball. Thanks again, Markus.
(In reply to comment #29) > All ebuilds marked as -ppc. I had installed version 3.7.11 just before during octave install. blas-atlas compiled with no problems on ppc and octave appears to operate correctly. Portage 2.0.53 (default-linux/ppc/2005.0, gcc-3.4.4, glibc-2.3.5-r3, 2.6.14-gentoo-r2 ppc) The only problem I've had is during world update with 3.7.11 being marked '-ppc'.
sparc stable.
amd64 stable
(In reply to comment #30) > I'll open a new bug once I've heard from upstream. Before I contact them it > would > be great, however, if you could recompile blas-atlas without the reconfigure > step > in the ebuild (see comment 26) to build it with the native settings and provide > me with the compile tarball. Thanks again, Markus. http://www.scherbaum.info/~tobias/gentoo/ppc/blas-atlas-failure-3.tar.bz2 Until this problem is fixed there are several broken deps caused by the blas-atlas de-keywording on ppc. As blas-atlas seems to work for some people on ppc I'm not sure if we should de-keyword the packages depending on blas-atlas or reconstruct the blas-atlas keywords like they were before the de-keywording. Any suggestions, Markus?
(In reply to comment #34) > > http://www.scherbaum.info/~tobias/gentoo/ppc/blas-atlas-failure-3.tar.bz2 > Thank you very much Tobias! I'll file a bug with upstream this weekend. > Until this problem is fixed there are several broken deps caused by the > blas-atlas de-keywording on ppc. As blas-atlas seems to work for some people on > ppc I'm not sure if we should de-keyword the packages depending on blas-atlas > or reconstruct the blas-atlas keywords like they were before the de-keywording. > Any suggestions, Markus? > Tough call since it looks like a weird error that is triggered on some ppc machines and not others. Given the fact that this is the first time I've seen a bug for this on ppc I'd assume that blas-atlas has emerged so far for most people on ppc. Hence we might consider leaving things as they were before the de-keywording and attempt to move -r1 into stable once we've heard back from upstream. Would it be a good idea to open a separate bug for this and continue to fix this issue there? Thanks, Markus
Ok, all versions re-keyworded. (In reply to comment #35) > Would it be a good idea to open a separate bug for this and continue to fix > this > issue there? Sure, it is.
(In reply to comment #36) > > Would it be a good idea to open a separate bug for this and continue to fix > > this > > issue there? > > Sure, it is. > I've filed this as bug #120775. Thanks, Markus
Stable on alpha.
The next ~arch portage revision will auto repair evil rpaths and not bail. Maintainers should still fix the packages they maintain as portage will only die with FEATURES=stricter (but that is a maintainer & QA problem) no longer security@ http://bugs.gentoo.org/show_bug.cgi?id=124962
stable on ppc64 since some weeks.. sorry for being soooo late. :-/
someone please s/[stable]/[noglsa] and close
Here you go Raphael.
