Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 114587 - sci-libs/blas-atlas-3.6.0 fails to build due to insecure RUNPATHs / multilib should always be fixed
Summary: sci-libs/blas-atlas-3.6.0 fails to build due to insecure RUNPATHs / multilib ...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Runpath Issues (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B? [noglsa] DerCorny
Keywords:
: 116000 117746 (view as bug list)
Depends on:
Blocks: 81745 109722 111406
  Show dependency tree
 
Reported: 2005-12-05 18:47 UTC by AJ Armstrong
Modified: 2006-06-08 05:05 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
updated patch to avoid insecure runpaths in shared libs (atlas3.6.0-shared-libs.1.patch,30.40 KB, patch)
2006-01-06 07:09 UTC, Markus Dittrich (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description AJ Armstrong 2005-12-05 18:47:21 UTC
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
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2005-12-18 23:26:19 UTC
*** Bug 116000 has been marked as a duplicate of this bug. ***
Comment 2 Jaroslaw Kalinowski 2006-01-03 10:19:39 UTC
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
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-01-04 08:27:12 UTC
*** Bug 117746 has been marked as a duplicate of this bug. ***
Comment 4 Markus Dittrich (RETIRED) gentoo-dev 2006-01-04 15:08:10 UTC
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 
Comment 5 Jaroslaw Kalinowski 2006-01-04 15:18:19 UTC
(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...
Comment 6 Jaroslaw Kalinowski 2006-01-04 16:48:49 UTC
> > 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...
Comment 7 Markus Dittrich (RETIRED) gentoo-dev 2006-01-06 07:09:57 UTC
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
Comment 8 Jaroslaw Kalinowski 2006-01-06 16:21:59 UTC
(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
Comment 9 Markus Dittrich (RETIRED) gentoo-dev 2006-01-09 18:55:59 UTC
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?
Comment 10 Stefan Cornelius (RETIRED) gentoo-dev 2006-01-09 19:07:11 UTC
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.
Comment 11 Mark Loeser (RETIRED) gentoo-dev 2006-01-10 20:06:25 UTC
x86 done
Comment 12 Tobias Scherbaum (RETIRED) gentoo-dev 2006-01-11 04:49:55 UTC
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
Comment 13 Stefan Cornelius (RETIRED) gentoo-dev 2006-01-11 05:07:51 UTC
Back to ebuild status, we need a fix for ppc.
Comment 14 Markus Dittrich (RETIRED) gentoo-dev 2006-01-11 07:10:32 UTC
(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 
Comment 15 Tobias Scherbaum (RETIRED) gentoo-dev 2006-01-12 06:20:35 UTC
(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.
Comment 16 Jaroslaw Kalinowski 2006-01-12 07:36:11 UTC
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...
Comment 17 Markus Dittrich (RETIRED) gentoo-dev 2006-01-12 07:56:07 UTC
(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

Comment 18 Tobias Scherbaum (RETIRED) gentoo-dev 2006-01-12 21:35:32 UTC
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 ...
Comment 19 Jochen Maes (RETIRED) gentoo-dev 2006-01-12 22:43:29 UTC
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
Comment 20 Tobias Scherbaum (RETIRED) gentoo-dev 2006-01-13 07:02:33 UTC
(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?
Comment 21 Markus Dittrich (RETIRED) gentoo-dev 2006-01-13 10:03:46 UTC
(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

Comment 22 Tobias Scherbaum (RETIRED) gentoo-dev 2006-01-13 10:22:49 UTC
(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 ...
Comment 23 Tobias Scherbaum (RETIRED) gentoo-dev 2006-01-16 06:27:52 UTC
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?
Comment 24 Markus Dittrich (RETIRED) gentoo-dev 2006-01-16 06:56:12 UTC
(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.
Comment 25 Tobias Scherbaum (RETIRED) gentoo-dev 2006-01-16 07:21:47 UTC
(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
Comment 26 Markus Dittrich (RETIRED) gentoo-dev 2006-01-19 20:19:57 UTC
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.
Comment 27 Thierry Carrez (RETIRED) gentoo-dev 2006-01-20 09:38:27 UTC
sparc, alpha and amd64 should test and mark 3.6.0-r1 stable
Comment 28 Thierry Carrez (RETIRED) gentoo-dev 2006-01-20 09:43:50 UTC
And now without forgetting to add the cc:
Comment 29 Tobias Scherbaum (RETIRED) gentoo-dev 2006-01-21 08:57:21 UTC
All ebuilds marked as -ppc. 

@Markus:
You open a new bug if you have feedback from upstream or need us for testing?
Comment 30 Markus Dittrich (RETIRED) gentoo-dev 2006-01-22 05:12:03 UTC
(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.
Comment 31 David Gurvich 2006-01-22 20:30:14 UTC
(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'. 
Comment 32 Gustavo Zacarias (RETIRED) gentoo-dev 2006-01-24 13:39:05 UTC
sparc stable.
Comment 33 Simon Stelling (RETIRED) gentoo-dev 2006-01-24 15:18:09 UTC
amd64 stable
Comment 34 Tobias Scherbaum (RETIRED) gentoo-dev 2006-01-27 13:06:11 UTC
(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?
Comment 35 Markus Dittrich (RETIRED) gentoo-dev 2006-01-28 03:41:16 UTC
(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
Comment 36 Tobias Scherbaum (RETIRED) gentoo-dev 2006-01-28 07:35:42 UTC
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.
Comment 37 Markus Dittrich (RETIRED) gentoo-dev 2006-01-28 16:27:00 UTC
(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
Comment 38 Bryan Østergaard (RETIRED) gentoo-dev 2006-01-30 02:49:20 UTC
Stable on alpha.
Comment 39 solar (RETIRED) gentoo-dev 2006-03-05 08:02:43 UTC
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
Comment 40 Markus Rothe (RETIRED) gentoo-dev 2006-06-02 06:00:18 UTC
stable on ppc64 since some weeks.. sorry for being soooo late. :-/
Comment 41 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-06-08 03:37:27 UTC
someone please s/[stable]/[noglsa] and close
Comment 42 Sune Kloppenborg Jeppesen gentoo-dev 2006-06-08 05:05:25 UTC
Here you go Raphael.