Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 46122 - atlas-ebuilds do not build posix threaded libraries
Summary: atlas-ebuilds do not build posix threaded libraries
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Science Related Packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-29 08:47 UTC by someone
Modified: 2004-05-17 04:18 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description someone 2004-03-29 08:47:43 UTC
Due to wrong answers in ebuilds (p.e. atlas-3.4.2.ebuild) atlas does not build the posix thread libs libptf77blas.a libptcblas.a (it sends a number representing the architecture when the config expects "y" or "n"), and secondly the ebuild would not install these libraries even if they were build- they are missing in the corresponding install lines.

Reproducible: Always
Steps to Reproduce:
1. emerge /usr/portage/dev-libs/atlas/atlas-3.4.2.ebuild
2. see that libptf77blas.a libptcblas.a are missing
-----------
3. Download atlas-3.4.2.tar.bz2 on your own
4. Extract and "make"
5. Compare your answers with whats given in atlas-3.4.2.ebuild
6. See that you can manually build the libptf77blas.a libptcblas.a (might depend on hardware configuration- if you have two processors or not)

Actual Results:  
posix threaded versions are missing after building from ebuild, they were
created when answering questions manually.

Expected Results:  
The ebuild should have answered the questions of the atlas-configuration
correctly and should install the posix thread versions as well. The expected
targets (libs) are mentioned on http://math-atlas.sourceforge.net/errata.html#LINK

This is how the configuration of atlas-3.4.2 looks on my machine:

---------
gcc -o xconfig config.c
/tmp/ccGcuvTm.o(.text+0x941): In function `CmndResults':
: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
./xconfig
cc1: unrecognized option `-faltivec'
make[1]: *** [xprobe_AltiVec] Error 1
cc1: unrecognized option `-fvec'
make[1]: *** [xprobe_AltiVec] Error 1
make[2]: *** [atlas_run] Error 132
make[1]: *** [IRun_SSE2] Error 2
ATLAS configure started.

160
159
158
[...]
003
002
001
Enter number at top left of screen [0]:
===============================================================================
                                  IMPORTANT
===============================================================================
Before going any further, check
   http://math-atlas.sourceforge.net/errata.html
This is the ATLAS errata file, which keeps a running count of all known
ATLAS bugs and system problems, with associated workarounds or fixes.
IF YOU DO NOT CHECK THIS FILE, YOU MAY BE COMPILING A LIBRARY WITH KNOWN BUGS.

Have you scoped the errata file? [y]:
Configure will ask a series of questions, in one of two forms.  The first form
of question is a menu of choices.  One option in almost all menus is
'Other/UNKNOWN'.  If you are unsure of the answer, always choose this option.
The second form of question is a single line, with a default answer shown in
square braces.  If you hit return without typing anything, this default answer
will be used.  Again, if you are unsure of the answer, simply accept the
default.

ATLAS can detect almost everything it needs to know, so choosing the default
or 'Other/UNKNOWN' will at worst simply extend the install time (if you tell
config the answer to something ATLAS can skip some tests).

Configure makes no changes to the state of things until all questions have
been asked and answered.  Therefore, if you get confused and want to start
over, feel free to break out of this program (CTRL-C, CTRL-BREAK, etc)
and start again.  Alternatively, if you make a mistake you can finish the
configure process, and then edit the created make include file by hand to fix
the mistake manually (the name and location of this file will be printed
out at the end of configure).

If you have problems during configure or installation, consult the file
'ATLAS/README/TroubleShoot.txt'.
---------- PRESS ENTER TO CONTINUE ----------
Are you ready to continue? [y]:

I need to know if you are using a cross-compiler (i.e., you are compiling on
a different architecture than you want the library built for).

Are you using a cross-compiler? [n]: Probing to make operating system determination:
Operating system configured as Linux

Probing for architecture:
Architecture is set to ATHLON


Probing for supported ISA extensions:
   AltiVec: NO.
   AltiVec: NO.
   SSE2: NO.
   SSE1: DETECTED!

ATLAS can provide SMP support for the Level 3 BLAS via Posix threads.
If you choose to build a threaded library, ATLAS will compile all
aspects of the library (including the serial components) with the
threaded compiler/link flags.  Most machines can use the serial
library even when it is compiled with threaded options, but this
is not guaranteed to work, so if you want a true serial library,
answer no to threading below.
   enable Posix threads support? [y]: 
Number of CPUs: 2

Required cache flush detected as : 524288 bytes
Looking for compilers:
   /bin/gcc  : v3.2.3
F77 = /usr/i686-pc-linux-gnu/gcc-bin/3.2/g77 -O
CC = /bin/gcc  -fomit-frame-pointer -O3 -funroll-all-loops
MCC = /bin/gcc  -fomit-frame-pointer -O

Looking for BLAS (this may take a while):
Unable to find usable BLAS, BLASlib left blank.
FINDING tar, gzip, AND gunzip
   tar    : /bin/tar
   gzip   : /bin/gzip
   gunzip : /bin/gunzip


ATLAS has default parameters for OS='Linux' and system='ATHLON'.
If you want to just trust these default values, you can use express setup,
drastically reducing the amount of questions you are required to answer

   use express setup? [y]:



You need to choose a name which represents this architecture (eg. UltraSparc,
Dec21164, etc).  Do not use a generic name (eg. solaris, linux), which might
apply to different  hardware.  This architecture name will be appended to the
name of the created make include file, and appear in all subdirectories, so
don't make it longer than you like to type.  The name should follow the rules
for file names (so don't use punctuation and spaces, for instance).

   Enter Architecture name (ARCH) [Linux_ATHLONSSE1_2]: 
<arch> set to 'Linux_ATHLONSSE1_2'


The ATLAS install process is heavily file-based, and this can cause major
reliability problems when interacting with an overloaded or malfunctioning
remotely mounted filesystem.  ATLAS therefore has a mechanism in place to
allow for a delay before a file is declared to not be there, so that
slow NFS (i.e., waiting for amd timout) problems can be overcome, or for
handling slightly differing clocks between server/client.  This problem is
magnified if doing cross-compilation.  In the question below, we ask how
much of a delay, in seconds, ATLAS should tolerate between file creation
and appearance.  If you are installing on a local filesystem (eg. /tmp) or
a smooth-running NFS system, answer 0; for a moderately loaded NFS server, you
may want a value in the 10 second range, and for cross-compiling systems or
NFS servers experiencing errors, you may want to go as high as a couple
of minutes (120).
   Enter File creation delay in seconds [0]:

I'm going to ask you for information about your Fortran 77 compiler.  ATLAS
does not need Fortran77 to build, so if you don't have a Fortran compiler,
the install can still be completed successfully.  However, ATLAS built without
a Fortran compiler will not be callable from Fortran (i.e., the user should
use the C interface), and we will not be able to do full testing, since some of
the tester code is written in Fortran77.



I'm going to ask you for information about your Fortran 77 compiler.  ATLAS
does not need Fortran77 to build, so if you don't have a Fortran compiler,
the install can still be completed successfully.  However, ATLAS built without
a Fortran compiler will not be callable from Fortran (i.e., the user should
use the C interface), and we will not be able to do full testing, since some of
the tester code is written in Fortran77.

   Enter f77 compiler [/usr/i686-pc-linux-gnu/gcc-bin/3.2/g77]:    
   Enter F77 Flags [-O]: 
F77 & FLAGS: /usr/i686-pc-linux-gnu/gcc-bin/3.2/g77 -O
FLINKER & FLAGS: $(F77) $(F77FLAGS)

CC & FLAGS: /bin/gcc  -fomit-frame-pointer -O3 -funroll-all-loops
MCC & FLAGS: /bin/gcc  -fomit-frame-pointer -O
CLINKER & FLAGS: $(CC) $(CCFLAGS)


Finding F77 to C calling conventions (this may take a while):

Calculated F77/C interoperation conventions:
   Suffix F77 names with underscores with __
   F77 INTEGER -> C int
   F77 strings handled via standard sun style

The ATLAS team has provided a default install for your architecture.  If you
want, these default values can be used, and ATLAS can skip most of the search
for your machine.  This will greatly decrease the amount of time required for
the install, allow you to take advantage of any special features found by the
ATLAS team, and provide protection against install miscues caused by unreliable
timing results, assuming you really have the machine ATLAS thinks you have.  If
your machine is non-standard in some way, or you just want to see the ATLAS
search for yourself, you should answer no to the following question.  Otherwise,
it is highly recommended to accept the default of yes.

Use supplied default values for install? [y]:

Unpacking Architectural defaults . . . done.

Creating make include file Make.Linux_ATHLONSSE1_2
Make.Linux_ATHLONSSE1_2 successfully created.



Creating ATLrun.sh

Creating subdirectories:
   Checking for already existing subdirectories  ........ no
Subdirectories successfully created.


Storing L1 cache size of 64KB.


Moving config logfiles ConfSummary.log and ConfDump.log to
bin/Linux_ATHLONSSE1_2/INSTALL_LOG/


Configuration completed successfully.  You may want to examine the make include
file (Make.Linux_ATHLONSSE1_2) for accuracy before starting the install with the
command:
   make install arch=Linux_ATHLONSSE1_2

rm -f ./xconfig
Comment 1 Patrick Kursawe (RETIRED) gentoo-dev 2004-04-20 04:24:31 UTC
Is this still a problem for 3.6.0?
Comment 2 Patrick Kursawe (RETIRED) gentoo-dev 2004-05-11 05:41:39 UTC
Someone reading this?
Comment 3 Patrick Kursawe (RETIRED) gentoo-dev 2004-05-17 04:18:52 UTC
No reaction, closing.