ports/117923: USE_FORTRAN=yes: shared libraries for blas, lapack, and atlas do not contain any dependencies on other libs
| From: | Thomas Ludwig <tludwig@smr.ch> |
| Date: | Thu, 8 Nov 2007 13:41:52 GMT |
| Subject: | USE_FORTRAN=yes: shared libraries for blas, lapack, and atlas do not contain any dependencies on other libs |
| Send-pr version: | www-3.1 |
| Number: | 117923 |
| Category: | ports |
| Synopsis: | USE_FORTRAN=yes: shared libraries for blas, lapack, and atlas do not contain any dependencies on other libs |
| Severity: | non-critical |
| Priority: | low |
| Responsible: | maho@FreeBSD.org |
| State: | feedback |
| Class: | sw-bug |
| Arrival-Date: | Thu Nov 08 13:50:01 UTC 2007 |
| Closed-Date: | |
| Last-Modified: | Fri Jul 11 00:30:09 UTC 2008 |
| Originator: | Thomas Ludwig |
| Release: | 6.3-PRERELEASE |
| Organization: |
SMR
| Environment: |
FreeBSD pingu.smr-internal.ch 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Nov 1 16:38:55 CET 2007 root@pingu.smr-internal.ch:/usr/obj/usr/src/sys/GENERIC i386
| Description: |
The USE_FORTRAN=yes directive present in the ports Makefiles for math/blas, math/lapack, and math/atlas does not add any dependency, including the dependency for libgfortran, to the shared libraries:
$ ldd /usr/local/lib/libblas.so.2
/usr/local/lib/libblas.so.2:
This in turn leads to problems when linking with such shared libraries.
$ ldd /usr/local/lib/libblas.so.2
/usr/local/lib/libblas.so.2:
This in turn leads to problems when linking with such shared libraries.
| How-To-Repeat: |
| Fix: |
| Release-Note: |
| Audit-Trail: |
| Responsible Changed | |
| From-To: | freebsd-ports-bugs->maho |
| By: | edwin |
| When: | Thu Nov 8 21:28:36 UTC 2007 |
| Why: | The situation wants that maho@ is maintainer of all three ports. |
| State Changed | |
| From-To: | open->feedback |
| By: | maho |
| When: | Sun Nov 11 08:32:31 UTC 2007 |
| Why: | Could you please explain more about the defect? |
| Reply via E-mail | |
| From: | Maho NAKATA <chat95@mac.com> |
| Date: | Sun, 11 Nov 2007 17:30:38 +0900 (JST) |
|
From: edwin@FreeBSD.org Subject: Re: ports/117923: USE_FORTRAN=yes: shared libraries for blas, lapack, and atlas do not contain any dependencies on other libs Date: Thu, 08 Nov 2007 21:31:02 +0000 (GMT) > Synopsis: USE_FORTRAN=yes: shared libraries for blas, lapack, and atlas do not contain any dependencies on other libs > > Responsible-Changed-From-To: freebsd-ports-bugs->maho > Responsible-Changed-By: edwin > Responsible-Changed-When: Thu Nov 8 21:28:36 UTC 2007 > Responsible-Changed-Why: > The situation wants that maho@ is maintainer of all three ports. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=117923 Verified. But what is the problem actually? Linking some objects against libblas requires libgfortran or something like that, though. All the best, -- Nakata Maho (maho@FreeBSD.org) | |
| Reply via E-mail | |
| From: | bf <bf2006a@yahoo.com> |
| Date: | Tue, 29 Apr 2008 22:39:57 -0700 (PDT) |
|
I think, Maho, that he is referring to two problems that were not present before because many of these ports used static libraries, and/or because Fortran was in the base FreeBSD system. Now the problems are: 1) Some of the libraries built by these ports have runtime dependencies on libraries associated with the compiler used to build them -- gfortran, for instance, for some of these ports built with lang/gcc42. At the moment, this runtime dependency is not recorded in LIB_DEPENDS for the port. Instead, USE_FORTRAN only records a BUILD_DEPENDS. This is appropriate for USE_FORTRAN, which is trying to retain some flexibility for users by permitting them to use several different Fortran compilers, and which is intended to also apply to ports that require a fortran compiler during the build stage, but not afterwards. However, for those ports that do need the compiler libraries at runtime, failing to record this dependency can break a port if, for instance, a compiler is first used to build the port and then the compiler is deinstalled or updated to a new compiler version with a different ABI or some subtly-different library behavior. This may also create some problems for people using packages instead of ports. The solution is to record the runtime dependency in LIB_DEPENDS, but it is a bit of a pain because some of the logic used in bsd.gcc.mk has to be repeated in the relevant port Makefiles for each compiler accepted by USE_FORTRAN, or some hack like using libmap.conf(5) has to be employed. 2)In some of these ports, we are assembling shared libraries from static libraries. This is simply because some of these older, standard ports first used only static libraries, and then we subsequently altered them to also make shared libraries in the simplest and quickest way. However, the resulting shared libraries, because of the way that they are built, lack some of the nice features of shared libraries built in other ports. For instance, the lapack library ${LOCALBASE}/lib/liblapack.so.4 is built by the command: cd ${WRKSRC_SHARED} ; ld -Bshareable -o liblapack.so.${SVERSION} -x -soname liblapack.so.${SVERSION} --whole-archive liblapack.a ; ${LN} -s liblapack.so.${SVERSION} liblapack.so in the math/lapack Makefile, and the resulting library lacks things like ELF DT_NEEDED tags that make it easier to resolve shared library dependencies. You can't use "ldd" or "objdump -x ... | grep -ie needed -ie rpath" (like in ${PORTSDIR}/Tools/scripts/neededlibs.sh or systutils/libchk ) or to find the needed libraries -- instead you have to laboriously go through and resolve undefined symbols by trying to find them in other libraries that may be dependencies, or by carefully looking through makefiles, documentation, and compiler settings. This can probably be fixed by tinkering with the commands used to assemble the shared libraries. b. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ | |
| Reply via E-mail | |
| From: | bf <bf2006a@yahoo.com> |
| Date: | Tue, 29 Apr 2008 23:05:30 -0700 (PDT) |
|
On second thought, it may be easier to solve the first problem in my earlier reply by changing USE_FORTRAN in bsd.gcc.mk to USE_FORTRAN_BUILD and USE_FORTRAN_RUN or something similar, like we already have for PERL, TCL, TK, TWISTED, PYTHON, etc. in ports. That way we could properly account for different types of dependencies and avoid cluttering up Makefiles for individual ports. b. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ | |
| Reply via E-mail | |||||
| From: | bf <bf2006a@yahoo.com> | ||||
| Date: | Fri, 4 Jul 2008 06:34:25 -0700 (PDT) | ||||
|
Here are two patches, for math/blas and math/lapack, (1) that extend the regression test targets, (2) clean up some parts of the build, (3) add some Netlib mirrors, and (4) build shared libraries directly, using the Fortran compiler for linking (which seems to be the best way to record the Fortran-related library dependencies) and the methods of /usr/share/mk/bsd.lib.mk, rather than trying to convert static libraries into shared libraries, as is currently done (as I suggested, this seems to cause a loss of information). The last step could also be accomplished as in NetBSD pkgsrc, by using devel/libtool15 as a wrapper during compilation and linking, but I didn't think that this extra dependency was necessary. Tested on 7-Stable i386 with lang/gcc42. This is a first step towards making linking with these ports easier, and towards more easily allowing for the use of multiple blas/lapack variants interchangeably in Ports. Some additional changes to correctly record the Fortran-related runtime dependencies still need to be made, but at least such dependencies are now correctly recorded within the blas and lapack shared libraries. Comments? Regards, b.f.
| |||||
| Reply via E-mail | |
| From: | bf <bf2006a@yahoo.com> |
| Date: | Tue, 8 Jul 2008 18:00:40 -0700 (PDT) |
|
Using the regression tests in the patches I sent in earlier, it now appears that ICAMAX in math/blas is not behaving as desired. It seems to be a problem that has been experienced elsewhere -- see, for example, https://bugs.launchpad.net/ubuntu/hardy/+source/blas/+bug/202869 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34616 which are thought to be a variant of infamous gcc bug 323: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 There are several different ways to handle this problem, some of which are discussed in the "323" link above, or in the periodic discussions of floating-point calculations on FreeBSD that have taken place in the cvs-src mailing list, usually after modifications of relevant code by bde@ and das@. From what little I know about this, I'm not convinced that using CFLAGS+=-ffloat-store for icamax.f and izamax.f if ${CC} or ${FC} are versions of gcc, as adopted by Debian, Ubuntu and others, is the best solution . I'll see if I can come up with something. These precision-related problems are starting to surface more often, not only with these venerable ports that are now being scrutinized more carefully, but with newer software that often makes use of extended and mixed precision. The whole range of problems needs to be addressed as simply and consistently as possible, considering the full range of platforms and compilers that we now have. Perhaps someone could draw up some detailed guidelines for dealing with them in the base system and ports, in a way that doesn't involve wholesale rewriting of existing third-party software? (At least until we move to a compiler that can better handle these problems without intervention ... ) Regards, b. | |
| Reply via E-mail | |
| From: | David Schultz <das@FreeBSD.ORG> |
| Date: | Tue, 8 Jul 2008 22:30:44 -0400 |
|
On Tue, Jul 08, 2008, bf wrote: > Using the regression tests in the patches I sent in earlier, it now appears that ICAMAX in math/blas is not behaving as desired. It seems to be a problem that has been experienced elsewhere -- see, for example, > > https://bugs.launchpad.net/ubuntu/hardy/+source/blas/+bug/202869 > > and > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34616 > > which are thought to be a variant of infamous gcc bug 323: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Hi Mr. or Ms. "bf", FreeBSD isn't subject to gcc bug 323. On i386, we deliberately set the FPU precision to double by default to avoid this problem. On other supported architectures, extended precision is not an issue in the first place. I'm not sure why you think -ffloat-store is needed. Perhaps it would help if you could explain what the actual problem is, or even produce a minimal test that fails. Is this a FORTRAN-specific issue? Thanks! | |
| Reply via E-mail | |||||
| From: | bf <bf2006a@yahoo.com> | ||||
| Date: | Wed, 9 Jul 2008 02:15:39 -0700 (PDT) | ||||
| |||||
| Reply via E-mail | |
| From: | David Schultz <das@FreeBSD.ORG> |
| Date: | Wed, 9 Jul 2008 07:51:50 -0400 |
|
On Wed, Jul 09, 2008, bf wrote: > COMPLEX Z1, Z2 > REAL S1 Aah, but the REAL type in FORTRAN is IEEE 754 single precision, so you do run into a similar issue. (The FPU is set to double precision in FreeBSD, so you get more precision than you asked for in intermediate calculations.) There's usually very little performance advantage to using single precision instead of double precision; double precision is certainly a lot faster than using -ffloat-store. Another option is to tell the compiler to use SSE, or switch to amd64 where that is the default. Then you won't run into these issues. > * SCABS1 computes absolute value of a complex number > * > * .. Intrinsic Functions .. > INTRINSIC ABS,AIMAG,REAL > * .. > SCABS1 = ABS(REAL(Z)) + ABS(AIMAG(Z)) This is not the correct formula for the absolute value of a complex number, by the way. | |
| Reply via E-mail | |
| From: | Bruce Evans <brde@optusnet.com.au> |
| Date: | Thu, 10 Jul 2008 02:36:16 +1000 (EST) |
|
On Thu, 10 Jul 2008, Bruce Evans wrote: > [... points about side issues deleted] > On Wed, 9 Jul 2008, David Schultz wrote: > > > On Wed, Jul 09, 2008, bf wrote: > > > COMPLEX Z1, Z2 > > > REAL S1 > > > > Aah, but the REAL type in FORTRAN is IEEE 754 single precision, so > > you do run into a similar issue. (The FPU is set to double > > precision in FreeBSD, so you get more precision than you asked for > > in intermediate calculations.) There's usually very little > > performance advantage to using single precision instead of double > > precision; > ... Back to the main point. I looked at the test data. This problem is fully understood. It is essentially the ancient gcc spilling bug that gives f(x) != f(x) almost everywhere for all interesting sub-default-precision libm functions f. This is because exactly one of the f(x)'s is spilled unless you use -O0 or -ffloat-store (not a bug -- spilling is unavoidable), both of the f(x)'s are normally evaluated and returned in extra precision (extra precision for the evaluation is a feature and for the return it is a required bugfeature for C99), and spilling is broken in the presence of non-explicit extra precision (this is the bug). Spilling loses the extra precision (and also any extra exponent range, but this is unusual) so the results compare unequal. FreeBSD changes the default precision to 53-bits (double) to mostly avoid this bug. Spilling still breaks float precision (when x and f(x) are floats and f(x) has extra precision) and cases where the extra exponent range has an effect. The test program is a little different -- it uses f(x) == testdata[x] on floats. For C, the test should be for inequality (or better use quaility with extra-precision testdata[x]) for certain values of FLT_EVAL_METHOD including the i386 one (actually the one in the missing documentation for the weird i386 FLT_EVAL_METHOD), since there is no way that a float testdata[x] can match an extra-precision f(x), and there is normally no spill to lose any extra precision in f(x). The C bugfeature requires returning any extra precision in the calculation of f(x) (modulo i386's FLT_EVAL_METHOD allowing anything), and the test is of cases where such extra precision actually occurs. Fortran is unlikely to have the same bugfeature as C here, so it might require equality. Patience might be required waiting for this to be fixed ;-(. I've been waiting for 20 years for it to be fixed in C so far. Fortan seems to be using the C back end too much since it has the same bugs. Even without the bugs, there might be semantic differences like C's bugfeature for return values not being present in Fortran. Bruce | |
| Reply via E-mail | |
| From: | bf <bf2006a@yahoo.com> |
| Date: | Wed, 9 Jul 2008 12:31:15 -0700 (PDT) |
|
Thanks for all the valuable information, guys. math/blas is an old, standard library (most of it was written in 1978), and I suppose that single precision was more important at that time. The "absolute value" was the author's terminology -- I would have called it the l^1 norm -- but of course it's "equivalent", in the analytical sense, to the usual absolute value (the l^2 norm), and I suppose it's easier to evaluate. I suppose then that we should leave the library as it is, except perhaps adding a compilation with -ffloat-store only for the two susceptible routines when they are compiled on vulnerable platforms -- pre-SSE i386 and m68k, am I missing any others? Supposedly gcc 4.3+ have better control over precision than their predecessors. Right now the default choice (set in /usr/ports/Mk/bsd.gcc.mk ) of compiler for FreeBSD Fortran Ports is lang/gcc42, and the base system C compiler for allied C code. Would it be better if we were to change this default to lang/gcc43, and use some of the newer compiler's features to protect the unwary user on the vulnerable platforms? If we did so, what should we use -- the new -mpcXX compiler flags? FENV_ACCESS? And are you aware of any problems that may occur when mixing code compiled with lang/gcc4X and the base system C compiler? I notice that there are a few differences between gcc42 from lang/gcc42 and the base system C compiler. For instance, on RELENG7 the base system C compiler reports LDBL_MANT_DIG = 64 while lang/gcc42 gives LDBL_MANT_DIG = 53. I am not sure if this has consequences, or if there are other significant differences. The modern incarnation of BLAS is at http://crd.lbl.gov/~xiaoye/XBLAS/ I started to make a port for this candidate reference implementation of the new mixed- and extended-precision BLAS, but ran into a few problems on i386. Do you have any comments about their chosen method of juggling precisions, and how best to handle it on FreeBSD as it is now? Regards, b. | |
| Reply via E-mail | |
| From: | Bruce Evans <brde@optusnet.com.au> |
| Date: | Thu, 10 Jul 2008 00:22:20 +1000 (EST) |
|
I just read the entire gcc bugzilla #323 thread (118 comments) and many links. Some points of interest, especially to me: - the guy from inria agrees with me and wants Linux to use the same precision hack as in FreeBSD. Linux used this in the early 90's but was changed to default to 64-bit precision as soon as gcc started pretending to support 8-bit long doubles. - the Microsoft Visual C++ documented pointed to in a comment shows that VC++ handled this better in 2005 (the doc is old (last update June 2004) but documents a 2005 version of VC++). VC++ apparently switched from a default of 64-bit precision back(?) to 53-bit precision in 2005, presumably to more or less avoid this problem in the usual case, as in FreeBSD. The document also shows almost correct but rather inefficient handling of the problem: - compiler flag fp:precise fixes all of the gcc precision bugs except for spilling: - assignments discard any extra precision as required by C99. fp_precise is claimed to be efficient, or at least as efficient as possible, but it cannot be efficient with this, except in code that uses complicated expressions to avoid assignments. It is indeed about as efficient as possible given the C99 requirement. - casts work discard any extra precision as required by C99. There must be some way to do this, and an explicit cast is as good as any. - function calls discard any extra precision as required by C99. gcc does this too (it is required by ABIs). - function returns discard any extra precision as required by POLA and a possibly a future IEEE standard but prohibited by C99, efficiency and accuracy (the accuracy and probably the C99 requirement for not discarding here is that expressions in return statments shouldn't have a different evaluation method than expressions in other statements. - spilling of intermediate results that have extra precision is completely broken, as in gcc. It's strange to fix assignment, which has a large runtime cost by a small POLA cost while not fixing this which has a small runtime cost and a large POLA cost. - compiler flag fp:fast mode is like gcc's -ffast-math. - compiler flag fp:strict is fp_precise, plus the strictness required for fenv access including exceptions, plus no contraction (no fma...). - C99 pragmas and extensions to control all this are implemented. On Wed, 9 Jul 2008, David Schultz wrote: > On Wed, Jul 09, 2008, bf wrote: > > COMPLEX Z1, Z2 > > REAL S1 > > Aah, but the REAL type in FORTRAN is IEEE 754 single precision, so > you do run into a similar issue. (The FPU is set to double > precision in FreeBSD, so you get more precision than you asked for > in intermediate calculations.) There's usually very little > performance advantage to using single precision instead of double > precision; Only in practice. Single precision is 2 to 4 times faster in many FreeBSD libm functions, and that is without much parallelism. This is about half due to specialized algorithms and half due to reduced memory traffic combined with easier optimization. With full vectorization, float SSE can stream 2 to 4 times faster than double SSE (2 times faster due to twice as many elements per operation and another factor of 2 times faster >= 2 year old CPUs where doubles are not pipelined as well). Fortran is more vectorizable than C, so single precision is probably more useful for efficiency in it. > double precision is certainly a lot faster than using > -ffloat-store. Except in rare cases where the latency of -float-store can be hidden. > Another option is to tell the compiler to use SSE, or switch to > amd64 where that is the default. Then you won't run into these > issues. Of course, not using extended precision defeats the point of having it. Does Fortran even permit extra precision? The default precision should be chosen by the library according to the requirements of the language and its implementation, not by the kernel. > > * SCABS1 computes absolute value of a complex number > > * > > * .. Intrinsic Functions .. > > INTRINSIC ABS,AIMAG,REAL > > * .. > > SCABS1 = ABS(REAL(Z)) + ABS(AIMAG(Z)) > > This is not the correct formula for the absolute value of a > complex number, by the way. :-). Complex arithmetic also benefits from extra precision. Just implementing multiplication efficiently and fairly accurately is almost imposible without it (using it avoids all overflow possibilities for multiplications and reduces cancellation errors significantly). Complex numbers are ancient technology in Fortran so they are presumably used more in it. Bruce | |
| Unformatted: |