Bugzilla Bug 55386

emerge of R ends as follows:

   ztrmv:
   ztrsm:
   ztrsv:
gcc -I. -I../../../src/include -I../../../src/include -I/usr/local/include -DHAVE_CONFIG_H  -fPIC  -O3 -pipe -fomit-frame-pointer -funroll-loops -c cmplxblas.c -o cmplxblas.lo
gcc -shared -L/usr/local/lib  -o libRlapack.so dlapack0.lo dlapack1.lo dlapack2.lo dlapack3.lo cmplx.lo  cmplxblas.lo  -lf2c -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.0/../../../libf2c.a(z_div.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.0/../../../libf2c.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [libRlapack.so] Error 1
make[4]: Leaving directory `/var/tmp/portage/R-1.9.0-r1/work/R-1.9.0/src/modules/lapack'
make[3]: *** [R] Error 2
make[3]: Leaving directory `/var/tmp/portage/R-1.9.0-r1/work/R-1.9.0/src/modules/lapack'
make[2]: *** [R] Error 1
make[2]: Leaving directory `/var/tmp/portage/R-1.9.0-r1/work/R-1.9.0/src/modules'
make[1]: *** [R] Error 1
make[1]: Leaving directory `/var/tmp/portage/R-1.9.0-r1/work/R-1.9.0/src'
make: *** [R] Error 1

!!! ERROR: dev-lang/R-1.9.0-r1 failed.
!!! Function src_compile, Line 89, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.



Reproducible: Always
Steps to Reproduce:
1.emerge R
2.
3.

Actual Results:  
emerge R ends as follows:


   ztrmv:
   ztrsm:
   ztrsv:
gcc -I. -I../../../src/include -I../../../src/include -I/usr/local/include
-DHAVE_CONFIG_H  -fPIC  -O3 -pipe -fomit-frame-pointer -funroll-loops -c
cmplxblas.c -o cmplxblas.lo
gcc -shared -L/usr/local/lib  -o libRlapack.so dlapack0.lo dlapack1.lo
dlapack2.lo dlapack3.lo cmplx.lo  cmplxblas.lo  -lf2c -lm
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.0/../../../libf2c.a(z_div.o): relocation
R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.0/../../../libf2c.a: could not read
symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [libRlapack.so] Error 1
make[4]: Leaving directory
`/var/tmp/portage/R-1.9.0-r1/work/R-1.9.0/src/modules/lapack'
make[3]: *** [R] Error 2
make[3]: Leaving directory
`/var/tmp/portage/R-1.9.0-r1/work/R-1.9.0/src/modules/lapack'
make[2]: *** [R] Error 1
make[2]: Leaving directory `/var/tmp/portage/R-1.9.0-r1/work/R-1.9.0/src/modules'
make[1]: *** [R] Error 1
make[1]: Leaving directory `/var/tmp/portage/R-1.9.0-r1/work/R-1.9.0/src'
make: *** [R] Error 1

!!! ERROR: dev-lang/R-1.9.0-r1 failed.
!!! Function src_compile, Line 89, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

Expected Results:  
Something a little less explosive, like finish emerging

# emerge info
Portage 2.0.51_pre10 (gcc34-amd64-2004.1, gcc-3.4.0, glibc-2.3.4.20040605-r0, 2.6.5)
=================================================================
System uname: 2.6.5 x86_64 4
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r4
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.90.0.1.1-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CFLAGS="-O3 -pipe -fomit-frame-pointer -funroll-loops"
CHOST="x86_64-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.2/share/config /usr/kde/3/share/config /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 -pipe -fomit-frame-pointer -funroll-loops"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X alsa amd64 apm arts avi berkdb cdr crypt cups dvd dvdr encode esd
foomaticdb gdbm gif gnome gpm gtk gtk2 imagemagick imlib jpeg kde ldap libg++
libwww mikmod motif mozilla mpeg mysql ncurses nls odbc oggvorbis opengl oss pam
pcmcia pda pdflib perl png pnp postgres python qt quicktime readline ruby samba
sdl slang spell ssl tcpd tetex tiff truetype unicode usb wxwindows xinerama xml2
xmms xv xvid yahoo zlib"

# gcc --version
gcc (GCC) 3.4.0 20040601 (Gentoo Linux 3.4.0-r6, ssp-3.4-2, pie-8.7.6.3)

NOTE:  R is a dependency for app-misc/grass-5.0.3, which is why I'm emerging R
in the first place.

libf2c needs to be compiled with -fPIC 

Perhaps the guy who added libf2c to ~amd64 can comment on this bug?

-fPIC on amd64 is our buisness ;-) I will have a look now.

1) dev-libs/libf2c produced only static library w/o PIC. Fixed,
libf2c-20021004-r1
   produces now a static library and a shared object.

2) dev-lang/R depends on f2c in case that is built with USE="-ifc -f77". Fixed
for
   amd64. Reassigning to sci@g.o

Jeff: sync and remerge libf2c to test and report please.

sci-herd: Can someone try emerging f2c and libf2c-20021004-r1 on x86, sparc and
ppc ? If they work on these platform, we can tidy up the dependencies a bit.

Tested in 32 bit chroot
aldar work # uname -a
Linux aldar 2.6.5-gentoo-r1 #2 Sun May 30 19:56:37 MDT 2004 i686 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux

Compiles (both libf2c and f2c) and converts fine (tested on some blas files).

BTW, you can too setup 32bit scroot, which is essentially a standard x86 (i686 as reported above) for just such purposes ;).
http://www.gentoo.org/proj/en/base/amd64/technotes.xml?part=2&chap=4

George

I can report that libf2c-20021004-r1 appears to build just fine and so does R.

libf2c works on sparc as well... waiting for sparc to test virtual/blas &
virtual lapack. In case they work, i will remove the atlas USE flag from
dev-lang/R-1.9.0-r1 and set the dependencies on blas / lapack.

George: What do you think about going stable for 1.9.0-r1 ? I wanted to do it
before this bug popped up and i think that this is only a minor one...

Danny, you asked George but since he didn't reply so far and there are (as far
as I can see) no other bugs open for R 1.9, I'd say just go ahead.

Oops, sorry, slipped on this one (its pretty terse time for me now, setting up
interviews and trying to organize my graduation..). Yes, I think you can go
ahead on R as far as I am concerned. You should know the situation with R
better than me at this point :).

George

On sparc, R-1.9.0-r1 builds with and without:
USE=f2c
USE=blas (== blas-atlas-3.6.0)
USE=gnome
(Actually, the USEs were USE="" [which gets "+tcltk -blas -gnome -f2c..." for me]
  USE="f2c"          ["+f2c -gnome -blas ..." ]
  USE="blas gnome"  [and so, gets "+tcltk +blas +gnome -f2c ..." ]

The second was built with (default) gcc-3-3-3, glibc-2.3.2-r9;
The others were built with hardened gcc-3,3,4-r1, glibc-2.3.3.20040420 (but the
gcc hardened version was built with its silly-for-sparc 'filter-flags -O?' DISabled)

In each case, the build, install went exactly as expected, and the resulting R can
run all of its demo() examples to make impressive graphs, alphabets, or whatever.
As a quick check of some of what is being checked here, I verified from 'ldd R.bin'
that the "USE=blas ..." build does in fact require:
libblas.so.0 => /usr/lib/libblas.so.0
libatlas.so.0 => /usr/lib/libatlas.so.0

In any event, the specific problem mentioned here concerning "USE=f2c" is not
currently a problem on sparc, and there were no errors in the build not in the
demos.

I don't know anything about R, so I can't test it further without reading its documentation.  But it seems OK on
sparc with any reasonable set of USE choices, so I am taking sparc off the CC
list.  I am adding myself in case this bug is asking for something I have missed.

Regards,
Ferris

Ok, dev-libs/libf2c and dev-lang/f2c are stable on amd64, x86 and ppc now.
Ferris: Could you mark those stable on sparc too ?

However, i can't mark app-sci/blas-atlas stable on x86 and ppc, cause it depends on >=sys-devel/libtool-1.5. We have to wait until that get's marked stable on x86, ppc and sparc.

I'll rebuild f2c+f2clib & do a quick check.  Then, yes, I'll mark them stable
for sparc.

dev-libs/libf2c-20021004-r1, dev-lang/f2c-20030320 are now marked stable for
sparc.

removing ppc from cc

FIXED. blas-atlas is finally stable on ppc and x86.
R-1.8.1 is removed, cause R-1.9.0-r1 replaces it.