[gentoo-science] Testing with GCC 4

[gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

Hi all,

GCC 4.1 will be unmasked this week. A major consequence for scientific
users is the switch from g77 to gfortran.

Things you can do to help make the switch easier for everyone:

Developers: Check all your Fortran packages to ensure they work with
gfortran from sys-devel/gcc-4.1.1_pre20060517. If they're C/C++, it's
also worth testing your packages because GCC 4 is tougher on compliance
than GCC 3.

Users/Testers: Unmask and install GCC 4.1 with `echo
"=sys-devel/gcc-4.1*" >> /etc/portage/package.unmask` and `emerge gcc`.
Switch to it with gcc-config (Use `gcc-config -l` to list available
compilers). Install portage-utils and run `emerge --oneshot $(qlist -I
-C sci*/)`. This will reinstall all your sci-* packages using your new gcc.


When you come across a broken package, file a bug for it.

Packages I know don't work:
{blas,cblas,lapack}-reference -- I have patches for these
apbs
numarray

Thanks,
Donnie

1. http://www.gentoo.org/news/en/gwn/20060522-newsletter.xml#doc_chap1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Adam Piątyszek]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

Hi Donnie,

* Donnie Berkholz [2006-05-23 18:04]:
[...]
> Packages I know don't work:
> {blas,cblas,lapack}-reference -- I have patches for these

Could you post these patches to bugs.gentoo.org?

BR,

/ediap



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

Adam Piątyszek wrote:
> Hi Donnie,
> 
> * Donnie Berkholz [2006-05-23 18:04]:
> [...]
>> Packages I know don't work:
>> {blas,cblas,lapack}-reference -- I have patches for these
> 
> Could you post these patches to bugs.gentoo.org?

I will commit them when I have time. Dealing with Bugzilla takes even
more time, so no.. but they'll show up eventually.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

Donnie Berkholz wrote:
> Users/Testers: Unmask and install GCC 4.1 with `echo
> "=sys-devel/gcc-4.1*" >> /etc/portage/package.unmask` and `emerge gcc`.
> Switch to it with gcc-config (Use `gcc-config -l` to list available
> compilers). Install portage-utils and run `emerge --oneshot $(qlist -I
> -C sci*/)`. This will reinstall all your sci-* packages using your new gcc.

Instead of sci*/ try sci-.*/

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Markus Dittrich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 23 May 2006, Donnie Berkholz wrote:
> Packages I know don't work:
> apbs

I just fixed apbs-0.4.0 and it works for me now 
with gcc-4.1.1_pre20060517.

best,
Markus

- -- 
Markus Dittrich (markusle)
Gentoo Linux Developer
Scientific applications
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEc4zwxlRwCwb7k40RAsJKAJ9Y0n8z/oN1ivKUCOkl13cnv/6O1wCeLy34
Bwj9NkzR/I4GLPuCLIQV3WQ=
=mZm8
-----END PGP SIGNATURE-----
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

Donnie Berkholz wrote:
> Hi all,
> 
> GCC 4.1 will be unmasked this week. A major consequence for scientific
> users is the switch from g77 to gfortran.

I've run a quick grep to see what packages clearly won't work. The
command, which only checks for packages in sci-* and dev-*:

grep -r -e 'FORTRAN=.*g77' -e 'need_fortran.*g77' sci-* dev-*
--include='*.ebuild' | grep -v gfort

Here's the results, with ebuilds pulled from the list if a newer version
supports gfortran.

I'll look at ortep3, platon, tinker, *-reference, pgplot. That just
leaves scipy, which already has
https://bugs.gentoo.org/show_bug.cgi?id=134248 open for it.

sci-chemistry/ortep3/ortep3-1.0.3.ebuild:FORTRAN="g77"
sci-chemistry/platon/platon-20051215.ebuild:FORTRAN="g77"
sci-chemistry/tinker/tinker-4.2.ebuild:FORTRAN="ifc g77"
sci-libs/blas-reference/blas-reference-19940131-r2.ebuild:FORTRAN="g77
ifc" || FORTRAN="g77 f2c ifc" # No f2c on 64-bit systems yet :-/

This line ^^^ looks distinctly weird and I don't understand how it would
ever work as desired.

sci-libs/blas/blas-19980702.ebuild:FORTRAN="g77"
sci-libs/blas/blas-19980702-r1.ebuild:FORTRAN="g77"
sci-libs/blas/blas-19980702-r2.ebuild:FORTRAN="g77"
sci-libs/scipy/scipy-0.4.8-r1.ebuild:FORTRAN="g77"
sci-libs/scipy/scipy-0.4.8.ebuild:FORTRAN="g77"
sci-libs/lapack-reference/lapack-reference-3.0-r1.ebuild:FORTRAN="g77 ifc"
sci-libs/lapack-reference/lapack-reference-3.0-r2.ebuild:FORTRAN="g77 ifc"
sci-libs/pgplot/pgplot-5.2.2.ebuild:FORTRAN="g77"


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Adam Piątyszek]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

Hi!

I have successfuly emerged the following packages:
* blas-atlas-3.7.11
* lapack-atlas-3.7.11
* fftw-3.1.1
* itpp-3.10.2


After some fixes in the ebuilds and patches, I managed to emerge:
* blas-reference-19940131-r2
* cblas-reference-20030223
* lapack-reference-3.0-r2

BTW, all the reference ebuild and related patches require review and
testing campaing, especially when using "ifc" compiler. I propose to
open/reopen bug-reports at b.g.o and start the discussion there...

BR,

/ediap


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

Adam Piątyszek wrote:
> After some fixes in the ebuilds and patches, I managed to emerge:
> * blas-reference-19940131-r2
> * cblas-reference-20030223
> * lapack-reference-3.0-r2
> 
> BTW, all the reference ebuild and related patches require review and
> testing campaing, especially when using "ifc" compiler. I propose to
> open/reopen bug-reports at b.g.o and start the discussion there...

I autotooled all of the *-reference ebuilds so they should work cleanly
with pretty much any compiler or architecture. There will be a revision
bump at some point soon.

The ebuilds are currently accessible in my overlay [1], and they also
make use of new eselect modules for blas, cblas and lapack that I
haven't announced yet.

Thanks,
Donnie

1. http://dev.gentoo.org/~spyderous/overlay/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Adam Piątyszek]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

* Donnie Berkholz [2006-05-25 11:46]:
> I autotooled all of the *-reference ebuilds so they should work cleanly
> with pretty much any compiler or architecture. There will be a revision
> bump at some point soon.

Sounds great!

> The ebuilds are currently accessible in my overlay [1], and they also
> make use of new eselect modules for blas, cblas and lapack that I
> haven't announced yet.
> 
[...]
> 1. http://dev.gentoo.org/~spyderous/overlay/

Thanks for the link and a good piece of work done!

BR,
/ediap



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-science] Testing with GCC 4

[M. Edward (Ed) Borasky]

By a strange coincidence, I'm beta testing R 2.3.1 this weekend. I have
a "corner case" that usually fails -- use lapack-atlas on an Athlon
Tbird and run "make check-all" in R. Of course, the R folks won't accept
a bug because they deprecate use of external Lapack in general. Anyhow,
I might as well throw gcc 4.1 into the mix. Do I need to do anything
special with the libraries?



Donnie Berkholz wrote:
> Hi all,
>
> GCC 4.1 will be unmasked this week. A major consequence for scientific
> users is the switch from g77 to gfortran.
>
> Things you can do to help make the switch easier for everyone:
>
> Developers: Check all your Fortran packages to ensure they work with
> gfortran from sys-devel/gcc-4.1.1_pre20060517. If they're C/C++, it's
> also worth testing your packages because GCC 4 is tougher on compliance
> than GCC 3.
>
> Users/Testers: Unmask and install GCC 4.1 with `echo
> "=sys-devel/gcc-4.1*" >> /etc/portage/package.unmask` and `emerge gcc`.
> Switch to it with gcc-config (Use `gcc-config -l` to list available
> compilers). Install portage-utils and run `emerge --oneshot $(qlist -I
> -C sci*/)`. This will reinstall all your sci-* packages using your new gcc.
>
>
> When you come across a broken package, file a bug for it.
>
> Packages I know don't work:
> {blas,cblas,lapack}-reference -- I have patches for these
> apbs
> numarray
>
> Thanks,
> Donnie
>
> 1. http://www.gentoo.org/news/en/gwn/20060522-newsletter.xml#doc_chap1
>
>   

-- 
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Testing with GCC 4

[Adam Piątyszek]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

Dear Donnie,

* Donnie Berkholz [2006-05-25 11:46]:
> I autotooled all of the *-reference ebuilds so they should work cleanly
> with pretty much any compiler or architecture. There will be a revision
> bump at some point soon.
> 
> The ebuilds are currently accessible in my overlay [1], and they also
> make use of new eselect modules for blas, cblas and lapack that I
> haven't announced yet.

I have just tested your autotooled *-reference ebuilds, and it seems that
there are some problems with the lapack library. I linked the IT++ library
with a shared version of liblapack and noticed that cholesky decomposition
does not work (cholesky_test from IT++ package goes into an endless loop).
The previous lapack-reference ebuild, which is in the official Gentoo
portage tree, creates correct libraries.

I haven't found time to have a look into your new patches yet, but just
wanted to report this problem.

BR,
/ediap


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

Adam Piątyszek wrote:
> I have just tested your autotooled *-reference ebuilds, and it seems that
> there are some problems with the lapack library. I linked the IT++ library
> with a shared version of liblapack and noticed that cholesky decomposition
> does not work (cholesky_test from IT++ package goes into an endless loop).
> The previous lapack-reference ebuild, which is in the official Gentoo
> portage tree, creates correct libraries.

That's an odd problem. I'd expect at least undefined functions or
something obvious, not a random loop. I'll take a look at it soon, maybe
I missed something obvious.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[M. Edward (Ed) Borasky]

Good news! R-2.3.1 beta compiled and installed successfully with both
3.4.5 and 4.1.1!! I also recompiled most of the library packages. I
haven't seen any failures that would have been compiler-related, so I'm
tempted to leave gcc 4.1.1 as the default for a while.

I don't have much more Fortran-based software, but I do think it's worth
recompiling blas-atlas and lapack-atlas with gcc 4.1.1.

M. Edward (Ed) Borasky wrote:
> By a strange coincidence, I'm beta testing R 2.3.1 this weekend. I have
> a "corner case" that usually fails -- use lapack-atlas on an Athlon
> Tbird and run "make check-all" in R. Of course, the R folks won't accept
> a bug because they deprecate use of external Lapack in general. Anyhow,
> I might as well throw gcc 4.1 into the mix. Do I need to do anything
> special with the libraries?
>
>
>
> Donnie Berkholz wrote:
>   
>> Hi all,
>>
>> GCC 4.1 will be unmasked this week. A major consequence for scientific
>> users is the switch from g77 to gfortran.
>>
>> Things you can do to help make the switch easier for everyone:
>>
>> Developers: Check all your Fortran packages to ensure they work with
>> gfortran from sys-devel/gcc-4.1.1_pre20060517. If they're C/C++, it's
>> also worth testing your packages because GCC 4 is tougher on compliance
>> than GCC 3.
>>
>> Users/Testers: Unmask and install GCC 4.1 with `echo
>> "=sys-devel/gcc-4.1*" >> /etc/portage/package.unmask` and `emerge gcc`.
>> Switch to it with gcc-config (Use `gcc-config -l` to list available
>> compilers). Install portage-utils and run `emerge --oneshot $(qlist -I
>> -C sci*/)`. This will reinstall all your sci-* packages using your new gcc.
>>
>>
>> When you come across a broken package, file a bug for it.
>>
>> Packages I know don't work:
>> {blas,cblas,lapack}-reference -- I have patches for these
>> apbs
>> numarray
>>
>> Thanks,
>> Donnie
>>
>> 1. http://www.gentoo.org/news/en/gwn/20060522-newsletter.xml#doc_chap1
>>
>>   
>>     
>
>   

-- 
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Testing with GCC 4

[Honza Macháček]

Donnie Berkholz wrote:

> Adam Piątyszek wrote:
> 
>>I have just tested your autotooled *-reference ebuilds...
>>does not work (cholesky_test from IT++ package goes into an endless loop).
>
> ...
> 
> That's an odd problem. I'd expect at least undefined functions or
> something obvious, not a random loop. I'll take a look at it soon, maybe
> I missed something obvious.

  May that be related to the DLAMC3 problem reported at
http://www.theochem.kth.se/dalton/faq.html near the end of the page? The
links to the Fedora bugzilla work no more, but as far as I remember the
infinite loop arises somehow from incorrect machine precision
assumptions due to excessive precision of numbers in registers, not
complient to the IEEE standard. So I try (althoug rather with the atlas
libraries than with the reference ones) using -mieee-fp compiler flag
rather than -ffloat-store recomended at the Dalton page (and -O1 rather
than -O2 on my AMD machines -- both athlon xp and k8 architectures --
due to other problem, that is too obscure to me so far for me to be even
able to file a reasonable bugzilla entry).
  If that is the case, than the key to the malfunction may be in the
compiler flags, and the ebuilds could be improved by some flags checking
and mangling, otherwise being OK.

						Honza Macháček
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Testing with GCC 4

[Michele Mattioni]

Il giorno gio, 25/05/2006 alle 10.58 +0200, Adam Piątyszek ha scritto:
> Hi!
> 
> I have successfuly emerged the following packages:
> * blas-atlas-3.7.11
> * lapack-atlas-3.7.11
> * fftw-3.1.1
> * itpp-3.10.2

Hi.. I'm trying to emerge ghemical . I've get an error in blas-atlas
package and lapack-atlas package :

>>emerge output

Are you ready to continue? [y]: Probing to make operating system
determination:
Operating system configured as Linux

archinfo_x86.c: In function ‘PrintUsage’:
archinfo_x86.c:106: warning: incompatible implicit declaration of
built-in function ‘exit’
archinfo_x86.c: In function ‘main’:
archinfo_x86.c:211: warning: incompatible implicit declaration of
built-in function ‘exit’
make[2]: *** [atlas_run] Error 21
make[1]: *** [IRunx8664] Error 2
Probing for architecture:
make[2]: *** [atlas_run] Error 21
make[1]: *** [IRunx86Info] Error 2
make: *** [config] Error 255
 *
 * ATLAS auto-config failed.
 * Please run 'interactive=1 emerge blas-atlas' to configure manually.
 *
<<emerge output.

I've tried with the gcc-4.1 and gcc-3.4.6 and I get the same error. 

I have to report a bug ?


this my emerge --info

Portage 2.1_rc3 (default-linux/x86/2005.1, gcc-4.1.1, glibc-2.4-r3,
2.6.16-suspend2-r5 i686)
=================================================================
System uname: 2.6.16-suspend2-r5 i686 Intel(R) Pentium(R) M processor
1600MHz
Gentoo Base System version 1.12.0
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.4 [enabled]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r1
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18.1
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-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -march=pentium-m -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-O3 -march=pentium-m -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms
strict"
GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/
ftp://mirror.switch.ch/mirror/gentoo/ ftp://ftp.solnet.ch/mirror/Gentoo
http://gentoo.mirror.solnet.ch http://gentoo.prz.rzeszow.pl"
LANG="it_IT@euro"
LC_ALL="it_IT.UTF-8"
LDFLAGS="-Wl,-O1"
LINGUAS="it"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_EXTRA_OPTS="180"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--compress --force --whole-file --delete --delete-after --stats
--timeout=180 --exclude='/distfiles' --exclude='/local'
--exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/overlay/portage /usr/local/overlay/gentopia /usr/local/overlay/gnome-experimental /usr/local/overlay/xgl-coffee /usr/local/overlay/initng-portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X acpi alsa apache2 avi bash-completion beagle berkdb
bitmap-fonts bluetooth bzip2 cairo cdr cdrom cjk cli crypt cups dbus dri
dts dvd dvdr eds emboss encode esd evolution fam firefox foomaticdb
fortran gdbm gif gimp gmime gnome gpm gstreamer gtk gtk2 gtkhtml hal
howl imlib ipv6 irmci isdnlog jack jpeg libg++ libwww mad mikmod mmx
mono motif mp3 mpeg mpi mysql nautilus ncurses nls nntp nptl nptlonly
ogg oggvorbis opengl oss pam pcre pdflib perl php png pppd python
quicktime readline real reflection samba sdl session spell spl sse sse2
ssl svg tcpd tetex truetype truetype-fonts type1-fonts udev unicode
userlocales utf8 vorbis win32codecs xml xml2 xorg xv zlib elibc_glibc
initng_plugins_also initng_plugins_bash_launcher initng_plugins_chdir
initng_plugins_chroot initng_plugins_conflict initng_plugins_cpout
initng_plugins_critical initng_plugins_cron initng_plugins_daemon
initng_plugins_dev initng_plugins_dllaunch initng_plugins_envparser
initng_plugins_find initng_plugins_fstat initng_plugins_history
initng_plugins_idleprobe initng_plugins_initctl
initng_plugins_interactive initng_plugins_iparser initng_plugins_last
initng_plugins_limit initng_plugins_logfile initng_plugins_netprobe
initng_plugins_ngc4 initng_plugins_pause initng_plugins_pidfile
initng_plugins_reload initng_plugins_renice initng_plugins_rlparser
initng_plugins_simple_launcher initng_plugins_stcmd
initng_plugins_stdout initng_plugins_suid initng_plugins_syncron
initng_plugins_syslog initng_plugins_unneeded initng_plugins_provide
input_devices_keyboard input_devices_mouse input_devices_joystick
kernel_linux linguas_it userland_GNU video_cards_ati video_cards_radeon"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK


-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Testing with GCC 4

[Adam Piątyszek]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

* Donnie Berkholz [2006-05-28 05:33]:
> That's an odd problem. I'd expect at least undefined functions or
> something obvious, not a random loop. I'll take a look at it soon, maybe
> I missed something obvious.

I think the problem might be related to this part of the LAPACK's
SRC/Makefile:

slamch.o: slamch.f
        $(FORTRAN) $(NOOPT) -c $<
dlamch.o: dlamch.f
        $(FORTRAN) $(NOOPT) -c $<

.f.o:
        $(FORTRAN) $(OPTS) -c $<

In the previous ebuild, NOOPT is not set for g77 compiler (no flags at
all), whereas OPTS is set to the default CFLAGS. In my opinion this
exception in compilation flags might be important.

BR,
/ediap



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Adam Piątyszek]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

* Adam Piątyszek [2006-05-28 16:00]:
> I think the problem might be related to this part of the LAPACK's
> SRC/Makefile:
> 
> slamch.o: slamch.f
>         $(FORTRAN) $(NOOPT) -c $<
> dlamch.o: dlamch.f
>         $(FORTRAN) $(NOOPT) -c $<
> 
> .f.o:
>         $(FORTRAN) $(OPTS) -c $<
> 
> In the previous ebuild, NOOPT is not set for g77 compiler (no flags at
> all), whereas OPTS is set to the default CFLAGS. In my opinion this
> exception in compilation flags might be important.

It seems that I guessed the source of the problem right. Here is what I
found in the LAPACK FAQ:

"NOTE: Be careful. Many PC compilers often perform optimization by default
at compile time! Thus, for routines such as LAPACK/SRC/slamch.f and
LAPACK/SRC/dlamch.f, you will need to explicitly set a compile flag to
turn OFF optimization."

Donnie. Could you update your autotool patch with a proper flag settings
for these two source files? Thanks!

/ediap


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Adam Piątyszek wrote:
> "NOTE: Be careful. Many PC compilers often perform optimization by default
> at compile time! Thus, for routines such as LAPACK/SRC/slamch.f and
> LAPACK/SRC/dlamch.f, you will need to explicitly set a compile flag to
> turn OFF optimization."
> 
> Donnie. Could you update your autotool patch with a proper flag settings
> for these two source files? Thanks!

Indeed, thanks for doing the research on this! I will add them next time
I'm working on this!

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 243 bytes --]

Michele Mattioni wrote:
> Hi.. I'm trying to emerge ghemical . I've get an error in blas-atlas
> package and lapack-atlas package :

Thanks for your report, Michele, but could you file it at
bugs.gentoo.org instead?

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

Donnie Berkholz wrote:
> Adam Piątyszek wrote:
>> "NOTE: Be careful. Many PC compilers often perform optimization by default
>> at compile time! Thus, for routines such as LAPACK/SRC/slamch.f and
>> LAPACK/SRC/dlamch.f, you will need to explicitly set a compile flag to
>> turn OFF optimization."
>>
>> Donnie. Could you update your autotool patch with a proper flag settings
>> for these two source files? Thanks!
> 
> Indeed, thanks for doing the research on this! I will add them next time
> I'm working on this!

Just fixed it up and pushed the changes. Works for me, give it a shot to
be sure it fixes your problems.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

Donnie Berkholz wrote:
> Just fixed it up and pushed the changes. Works for me, give it a shot to
> be sure it fixes your problems.

The autotooling is now in portage in revision bumps to blas, cblas,
lapack -reference ebuilds. The eselect migration, however, remains just
in my overlay.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[M. Edward (Ed) Borasky]

Speaking of testing and the overlay, where do bugs against "wxmaxima"
get filed?

>>> emerge (6 of 6) sci-mathematics/wxmaxima-0.6.4-r1 to /
!!! Security Violation: A file exists that is not in the manifest.
!!! File: files/wxmaxima-0.6.5-docfiles.patch

I've managed to recompile gcl, sbcl, cmucl, clisp and maxima (all the
latest testing level and mostly Lisp rather than C) successfully with
gcc 4.1.1. Unless there's a reason not to, I'm planning to do blas-atlas
and lapack-atlas next. I have little to no use for non-Atlas blas or
lapack. :)

Donnie Berkholz wrote:
> Donnie Berkholz wrote:
>   
>> Just fixed it up and pushed the changes. Works for me, give it a shot to
>> be sure it fixes your problems.
>>     
>
> The autotooling is now in portage in revision bumps to blas, cblas,
> lapack -reference ebuilds. The eselect migration, however, remains just
> in my overlay.
>
> Thanks,
> Donnie
>
>   

-- 
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Testing with GCC 4

[Adam Piątyszek]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

Donnie,

* Donnie Berkholz [2006-05-29 02:55]:
>> Just fixed it up and pushed the changes. Works for me, give it a shot to
>> be sure it fixes your problems.
> 
> The autotooling is now in portage in revision bumps to blas, cblas,
> lapack -reference ebuilds. The eselect migration, however, remains just
> in my overlay.

One more problem related to the new eselect modules from your overlay. I
have blas-atlas and lapack-atlas libraries selected using an old
blas-config and lapack-config mechanism:

  lespaul ~ # blas-config -p

  Current profiles:
  F77 BLAS: /usr/lib/blas/f77-ATLAS
  C BLAS: /usr/lib/blas/c-ATLAS

  lespaul ~ # lapack-config -p

  Current profile:
  F77 LAPACK: /usr/lib/lapack/f77-ATLAS

And after merging your updated eselect modules and *-reference packages, I
can not switch to them using neither eselect nor blas/lapack-config:

  lespaul ~ # eselect lapack set reference
  Implementation "reference" already active for libdir "lib"!
  Failed to switch to implementation "reference" for libdir "lib"!
  !!! Error: One or more actions have failed!
  exiting.

Eselect shows that current lapack and blas are the reference ones:

  lespaul ~ # eselect lapack show
  reference

However, this is not true:

  lespaul ~ # ls -l /usr/lib/liblapack.*
  lrwxrwxrwx 1 root root 24 maj 28 17:20 /usr/lib/liblapack.a ->
  lapack/atlas/liblapack.a
  lrwxrwxrwx 1 root root 25 maj 28 17:20 /usr/lib/liblapack.so ->
  lapack/atlas/liblapack.so
  lrwxrwxrwx 1 root root 27 maj 28 17:20 /usr/lib/liblapack.so.0 ->
  lapack/atlas/liblapack.so.0

Is it a bug?

BR,
/ediap




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 176 bytes --]

M. Edward (Ed) Borasky wrote:
> Speaking of testing and the overlay, where do bugs against "wxmaxima"
> get filed?

https://bugs.gentoo.org please =)

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

Adam Piątyszek wrote:
> One more problem related to the new eselect modules from your overlay. I
> have blas-atlas and lapack-atlas libraries selected using an old
> blas-config and lapack-config mechanism:
> 
>   lespaul ~ # blas-config -p
> 
>   Current profiles:
>   F77 BLAS: /usr/lib/blas/f77-ATLAS
>   C BLAS: /usr/lib/blas/c-ATLAS
> 
>   lespaul ~ # lapack-config -p
> 
>   Current profile:
>   F77 LAPACK: /usr/lib/lapack/f77-ATLAS
> 
> And after merging your updated eselect modules and *-reference packages, I
> can not switch to them using neither eselect nor blas/lapack-config:
> 
>   lespaul ~ # eselect lapack set reference
>   Implementation "reference" already active for libdir "lib"!
>   Failed to switch to implementation "reference" for libdir "lib"!
>   !!! Error: One or more actions have failed!
>   exiting.
> 
> Eselect shows that current lapack and blas are the reference ones:
> 
>   lespaul ~ # eselect lapack show
>   reference
> 
> However, this is not true:
> 
>   lespaul ~ # ls -l /usr/lib/liblapack.*
>   lrwxrwxrwx 1 root root 24 maj 28 17:20 /usr/lib/liblapack.a ->
>   lapack/atlas/liblapack.a
>   lrwxrwxrwx 1 root root 25 maj 28 17:20 /usr/lib/liblapack.so ->
>   lapack/atlas/liblapack.so
>   lrwxrwxrwx 1 root root 27 maj 28 17:20 /usr/lib/liblapack.so.0 ->
>   lapack/atlas/liblapack.so.0
> 
> Is it a bug?

This problem should only happen when you first use the eselect version,
then switch back to the *-config version, then switch to the eselect
version again. I don't consider it a real bug, because of this.

The deal is that /etc/env.d/lapack/config will specify the
CURRENT="$foo" setting, but it can't know about how things are set up
using *-config rather than the eselect modules.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Adam Piątyszek]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

* Donnie Berkholz [2006-05-29 10:26]:
 > This problem should only happen when you first use the eselect version,
> then switch back to the *-config version, then switch to the eselect
> version again. I don't consider it a real bug, because of this.
> 
> The deal is that /etc/env.d/lapack/config will specify the
> CURRENT="$foo" setting, but it can't know about how things are set up
> using *-config rather than the eselect modules.

So, it seems that the new eselect tool is not backward compatible with
previous approaches, which is in my opinion not a good idea. A user might
have mixed x86 and ~x86 packages installed and therefore some of them uses
old *-config scripts and others your new eselect tool. In such a situation
there is no convenient method to switch between libraries...

That is of course my point of view, from the user's perspective.

BR,
/ediap



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-science] Testing with GCC 4

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

Adam Piątyszek wrote:
> * Donnie Berkholz [2006-05-29 10:26]:
>  > This problem should only happen when you first use the eselect version,
>> then switch back to the *-config version, then switch to the eselect
>> version again. I don't consider it a real bug, because of this.
>>
>> The deal is that /etc/env.d/lapack/config will specify the
>> CURRENT="$foo" setting, but it can't know about how things are set up
>> using *-config rather than the eselect modules.
> 
> So, it seems that the new eselect tool is not backward compatible with
> previous approaches, which is in my opinion not a good idea. A user might
> have mixed x86 and ~x86 packages installed and therefore some of them uses
> old *-config scripts and others your new eselect tool. In such a situation
> there is no convenient method to switch between libraries...
> 
> That is of course my point of view, from the user's perspective.

In my opinion, adding extra code to deal with an old approach is a bad
idea and will quickly introduce cruft into a new replacement.

Supporting mixed testing-stable systems is not a goal. Supporting
all-~x86 and all-x86 systems is a goal.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]