Bug 117923 - USE_FORTRAN=yes: shared libraries for blas, lapack, and atlas do not contain any dependencies on other libs
Summary: USE_FORTRAN=yes: shared libraries for blas, lapack, and atlas do not contain ...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Maho Nakata
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-08 13:50 UTC by Thomas Ludwig
Modified: 2011-09-24 19:40 UTC (History)
0 users

See Also:


Attachments
blas.txt (9.20 KB, text/plain)
2008-07-04 14:34 UTC, bf
no flags Details
lapack.txt (9.32 KB, text/plain)
2008-07-04 14:34 UTC, bf
no flags Details
testdata.tar.bz2 (49.52 KB, application/octet-stream)
2008-07-09 10:15 UTC, bf
no flags Details
lapack_321_diff.txt (6.49 KB, text/plain; charset=US-ASCII)
2009-12-12 02:08 UTC, b. f.
no flags Details
pr117923_blas.diff (2.20 KB, patch)
2010-08-29 07:24 UTC, b. f.
no flags Details | Diff
pr117923_lapack.diff (11.68 KB, patch)
2010-08-29 17:34 UTC, b. f.
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Ludwig 2007-11-08 13:50:01 UTC
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.
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2007-11-08 21:28:36 UTC
Responsible Changed
From-To: freebsd-ports-bugs->maho

The situation wants that maho@ is maintainer of all three ports.
Comment 2 NAKATA Maho 2007-11-11 08:30:38 UTC
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)
Comment 3 Maho Nakata freebsd_committer freebsd_triage 2007-11-11 08:32:31 UTC
State Changed
From-To: open->feedback

Could you please explain more about the defect?
Comment 4 bf 2008-04-30 06:39:57 UTC
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
Comment 5 bf 2008-04-30 07:05:30 UTC
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
Comment 6 bf 2008-07-04 14:34:25 UTC
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.


      
Comment 7 bf 2008-07-09 02:00:40 UTC
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.
Comment 8 David Schultz freebsd_committer freebsd_triage 2008-07-09 03:30:44 UTC
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!
Comment 9 bf 2008-07-09 10:15:39 UTC
Thanks for offering to help -- I was hoping that some of you experienced developers would give us some insight.  I'm a Mr., if it matters.  ;)  I did not mean to suggest that the specific bug mentioned in 323 existed in FreeBSD, but only more generally that related problems did, on some platforms, with some versions of FreeBSD.  Some of your own comments regarding the bde@'s changes to src/sys/i386/include_types.h in March left me with the impression that you yourself were not altogether satisfied with som e of the compromises that had been made:

"... FreeBSD/i386 fixes the problem
for doubles by setting the i387 to use 53-bit precision. The
downside is that this breaks long doubles. 15 years ago, this was
clearly the right thing to do, because we had a double precision
libm that would break when gcc got things wrong, and no long
double support anyway. Now we have a bunch of long double math
functions that have problems as a result of the reduced precision."

The problem I was referring to above was the failure of the icamax portion of the cblat1 regression test for the math/blas port, as patched above.  The output reads:


Test of subprogram number 10            ICAMAX
                                       FAIL

 CASE  N INCX INCY MODE COMP TRUE DIFFERENCE

   10  4    1 9999 9999  3    2           1
   10  4    2 9999 9999  3    2           1

This output is identical to that obtained by others, some of whom I mentioned above, and their use of -ffloat-store to "resolve" this problem was what led me to mention it as a possible solution.  This test has to do with determining the maximum (of one kind of) absolute value of the elements of an array of complex numbers.  The test case in question essentially boils down to:

       PROGRAM TEST2

       COMPLEX Z1, Z2
       REAL S1

       REAL SCABS1
       EXTERNAL SCABS1
       
       DATA Z1, Z2 / (0.1E0,0.4E0) , (0.4E0,0.1E0) /
       
       S1=SCABS1(Z1)
       IF (SCABS1(Z2) .LE. S1)THEN
         PRINT *, 'COMPARISON IS OK'
       ELSE
         PRINT *, 'RESULT OF COMPARISON IS ERRONEOUS'
       END IF       
       RETURN
       END

where SCABS1 is:

      REAL FUNCTION SCABS1(Z)
*     .. Scalar Arguments ..
      COMPLEX Z
*     ..
*
*  Purpose
*  =======
*
*  SCABS1 computes absolute value of a complex number
*
*     .. Intrinsic Functions ..
      INTRINSIC ABS,AIMAG,REAL
*     ..
      SCABS1 = ABS(REAL(Z)) + ABS(AIMAG(Z))
      RETURN
      END

I compiled these functions on RELENG7 i386 using gfortran42 from the  lang/gcc42 port (version 4.2.5_20080702):


gfortran42 -Wall ${FFLAGS} test2.f scabs1.f -o test2
./test2

The comparison is "ok" for FFLAGS = -O0, but yields the "erroneous" result if -O[123] are used.  However, if -ffloat-store is used with -O[123], the "ok" result is again obtained.  I've attached a tarball of the assembly code generated by the compiler in each case, for reference.  I don't know whether this particular problem is a "Fortran problem", but I have been able to reproduce different, but perhaps equally undesirable, behavior with related pure C code using both the system C compiler and the C compi ler from the lang/gcc42 port.  Strictly speaking, I'm not sure that standards require the libraries to pass the above test, but it does seem undesirable and counterintuitive (if you're taking a naive point of view) that they fail it.  

Regards, 
           b.


      
Comment 10 David Schultz freebsd_committer freebsd_triage 2008-07-09 12:51:50 UTC
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.
Comment 11 Bruce Evans freebsd_committer freebsd_triage 2008-07-09 15:22:20 UTC
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
Comment 12 Bruce Evans freebsd_committer freebsd_triage 2008-07-09 17:36:16 UTC
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
Comment 13 bf 2008-07-09 20:31:15 UTC
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.
Comment 14 b. f. 2009-12-12 02:08:45 UTC
Attached, an updated patch for the recent version of lapack:

-- unbreak the regression-test target by fixing a glitch in the
xlintstd target in the bundled TESTING/LIN/Makefile;

--honor LDFLAGS during linking, as these are needed for USE_FORTRAN,
and when using various compiler flags like -flto, -fwhopr,
-fstack-protector[-all], etc.;

--respect user-defined AR and RANLIB -- this is a no-op for most
users, as the automatically-included /usr/share/mk/sys.mk sets AR?=ar
and RANLIB?=ranlib, but for those who need to use other utilities,
such as ar and ranlib from devel/binutils used by lang/gcc45, this is
desirable;

--while here, use semicolons rather than commas to delimit
substitutions, as some compiler and linker flags can include commas
(for example, the LDFLAGS additions recently introduced for
USE_FORTRAN in ports/Mk/bsd.gcc.mk), and thus break the build;

--use the Fortran compiler to also construct the shared libraries,
rather than invoking the system linker directly -- this should ensure
the presence of the correct DT_NEEDED tags, and is required when using
devel/gold or ld from devel/binutils with lang/gcc45;

--bump the PORTREVISION.

Regards,
                b.
Comment 15 Pav Lucistnik freebsd_committer freebsd_triage 2009-12-19 16:59:15 UTC
State Changed
From-To: feedback->open

Not sure what the latest patch is supposed to do, but certainly feedback has 
been received here.
Comment 16 b. f. 2010-08-29 07:24:11 UTC
As Maho remarked earlier, the math/blas patch is unnecessarily long:
there is no need to reproduce large pieces of bsd.lib.mk merely to
change the commands that link the object files in order to form the
shared library. Instead, modify the MAKE_ENV to do the right thing.
While here:

--Remove an old netlib mirror and add two others, as listed in:

http://www.netlib.org/bib/mirrors.html

(Since a number of ports use netlib, this should be abstracted, and
added to bsd.sites.mk. But this change will be submitted in another,
separate PR.).

--Allow profiling libraries to be built.

--Remove the shared library version number from
${FILESDIR}/makefile.lib, and only define it in the port Makefile, so
that it can be bumped more easily, if necessary.

--Don't mix toolchains: since lang/gcc44 now uses devel/binutils
implicitly, use the utilities from this port when building the
libraries (this can be removed or simplified later if ports/149955 is
approved).

Postpone the addition of the tests, contained in the earlier patch --
this will be submitted in another, separate PR.

A considerable period of time has elapsed since this PR was filed, so
if we could resolve this problem soon, and make linking with the
shared libraries easier, it would be appreciated.  I will submit a
separate, updated patch for math/lapack soon, but the attached patch
for math/blas will be independent of the patch for math/lapack, and
can be committed separately, if it is approved.

Regards,

b.
Comment 17 b. f. 2010-08-29 17:34:49 UTC
The updated patch for math/lapack:

--make profiling libraries dependent upon {NO_,NO,WITHOUT_}PROFILE
--conditionally define BLAS for testing purposes
--don't mix toolchains
--respect LDFLAGS when linking test binaries and shared libraries
--reduce the amount of copying and renaming of libraries
--use the Fortran compiler, rather than the base system linker, to
construct the shared libraries (with the earlier math/blas patch, this
provides ELF DT_NEEDED tags)
--update to 3.2.2
--Fix a few gmake-isms in the source makefiles

Regards,

b.
Comment 18 NAKATA Maho 2010-08-30 02:46:31 UTC
From: "b. f." <bf1783@googlemail.com>
Subject: Re: ports/117923: USE_FORTRAN=yes: shared libraries for blas, lapack, and atlas do not contain any dependencies on other libs
Date: Sun, 29 Aug 2010 06:24:11 +0000

> As Maho remarked earlier, the math/blas patch is unnecessarily long:
> there is no need to reproduce large pieces of bsd.lib.mk merely to
> change the commands that link the object files in order to form the
> shared library. Instead, modify the MAKE_ENV to do the right thing.
> While here:
> 
> --Remove an old netlib mirror and add two others, as listed in:
> 
> http://www.netlib.org/bib/mirrors.html
> 
> (Since a number of ports use netlib, this should be abstracted, and
> added to bsd.sites.mk. But this change will be submitted in another,
> separate PR.).
> 
> --Allow profiling libraries to be built.
> 
> --Remove the shared library version number from
> ${FILESDIR}/makefile.lib, and only define it in the port Makefile, so
> that it can be bumped more easily, if necessary.
> 
> --Don't mix toolchains: since lang/gcc44 now uses devel/binutils
> implicitly, use the utilities from this port when building the
> libraries (this can be removed or simplified later if ports/149955 is
> approved).
> 
> Postpone the addition of the tests, contained in the earlier patch --
> this will be submitted in another, separate PR.
> 
> A considerable period of time has elapsed since this PR was filed, so
> if we could resolve this problem soon, and make linking with the
> shared libraries easier, it would be appreciated.  I will submit a
> separate, updated patch for math/lapack soon, but the attached patch
> for math/blas will be independent of the patch for math/lapack, and
> can be committed separately, if it is approved.
> 
> Regards,
> 
> b.

Hi bf, 

I reviewed your pr117923_blas.diff and approved. Please commit.

Thanks
-- Nakata Maho http://accc.riken.jp/maho/ , JA OOO http://ja.openoffice.org/
http://blog.goo.ne.jp/nakatamaho/ ,GPG: http://accc.riken.jp/maho/maho.pgp.txt
Comment 19 NAKATA Maho 2010-08-30 02:59:34 UTC
From: "b. f." <bf1783@googlemail.com>
Subject: Re: ports/117923: USE_FORTRAN=yes: shared libraries for blas, lapack, and atlas do not contain any dependencies on other libs
Date: Sun, 29 Aug 2010 16:34:49 +0000

> The updated patch for math/lapack:
> 
> --make profiling libraries dependent upon {NO_,NO,WITHOUT_}PROFILE
> --conditionally define BLAS for testing purposes
> --don't mix toolchains
> --respect LDFLAGS when linking test binaries and shared libraries
> --reduce the amount of copying and renaming of libraries
> --use the Fortran compiler, rather than the base system linker, to
> construct the shared libraries (with the earlier math/blas patch, this
> provides ELF DT_NEEDED tags)
> --update to 3.2.2
> --Fix a few gmake-isms in the source makefiles

Hi bf,

I really appreciate your input. Patch looks almost okay.

Please commit with following minor fix.

please do use 
DISTFILES=     lapack-${PORTVERSION}.tgz manpages-3.2.0.tgz
instead of 
DISTFILES=     lapack.tgz manpages-3.2.0.tgz

since filename with version number is very imporntat to know
whether the file is correct or not. If 3.2.3 will be released
then we must explain as slient update. 
Note that other mirrors did not contain lapack-3.2.2.tgz, but
it is okay.

Thanks
-- Nakata Maho http://accc.riken.jp/maho/ , JA OOO http://ja.openoffice.org/
http://blog.goo.ne.jp/nakatamaho/ ,GPG: http://accc.riken.jp/maho/maho.pgp.txt
Comment 20 dfilter service freebsd_committer freebsd_triage 2010-08-30 08:26:40 UTC
bf          2010-08-30 07:26:27 UTC

  FreeBSD ports repository

  Modified files:
    math/blas            Makefile 
    math/blas/files      makefile.lib 
  Log:
  Respect LDFLAGS; add ELF DT_NEEDED tags to shared libraries;
  use one toolchain consistently; build profiling libraries
  
  PR:             117923
  Approved by:    maho (maintainer), makc (co-mentor)
  
  Revision  Changes    Path
  1.47      +20 -6     ports/math/blas/Makefile
  1.10      +0 -9      ports/math/blas/files/makefile.lib
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 21 dfilter service freebsd_committer freebsd_triage 2010-08-30 08:31:44 UTC
bf          2010-08-30 07:31:34 UTC

  FreeBSD ports repository

  Modified files:
    math/lapack          Makefile distinfo pkg-plist 
    math/lapack/files    patch-TESTING+LIN+Makefile 
                         patch-make.inc.gfortran 
  Added files:
    math/lapack/files    patch-TESTING+Makefile 
  Log:
  Respect LDFLAGS; add ELF DT_NEEDED tags to shared libraries;
  use one toolchain consistently; minor cleanups; update to 3.2.2
  
  PR:             117923
  Approved by:    maho (maintainer), makc (co-mentor)
  
  Revision  Changes    Path
  1.50      +37 -26    ports/math/lapack/Makefile
  1.15      +3 -3      ports/math/lapack/distinfo
  1.3       +22 -8     ports/math/lapack/files/patch-TESTING+LIN+Makefile
  1.1       +14 -0     ports/math/lapack/files/patch-TESTING+Makefile (new)
  1.2       +24 -9     ports/math/lapack/files/patch-make.inc.gfortran
  1.15      +2 -2      ports/math/lapack/pkg-plist
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 22 Martin Wilke freebsd_committer freebsd_triage 2011-02-05 12:03:27 UTC
State Changed
From-To: open->closed

this was committed on 30 Aug 2010.
Comment 23 dfilter service freebsd_committer freebsd_triage 2011-09-24 19:37:12 UTC
bf          2011-09-24 18:36:59 UTC

  FreeBSD ports repository

  Modified files:
    math/atlas           Makefile distinfo pkg-descr pkg-plist 
    math/atlas/files     patch-CONFIG+src+SpewMakeInc.c 
                         patch-CONFIG+src+backend+archinfo_freebsd.c 
  Added files:
    math/atlas/files     patch-CONFIG+src+backend+archinfo_x86.c 
                         patch-makes+Make.sysinfo tuning-message 
  Removed files:
    math/atlas/files     Makefile.test alpha-patch 
                         patch-CONFIG+src+atlcomp.txt thread-patch 
  Log:
  Update to 3.8.4 before the 3.10 release; clean up (substantially
  reduce build times, introduce options, drop unneeded dependencies,
  and make linking with ATLAS shared libraries easier)
  
  Thanks to maho and A. Shterenlikht for review and testing, and to
  mm, T.  Ludwig, skreuzer, and E. Lemos de Sa for reminders or related
  submissions
  
  PR:             117923, 139169, 155650, 159876
  
  Revision  Changes    Path
  1.64      +198 -210  ports/math/atlas/Makefile
  1.15      +2 -2      ports/math/atlas/distinfo
  1.4       +0 -35     ports/math/atlas/files/Makefile.test (dead)
  1.2       +0 -9      ports/math/atlas/files/alpha-patch (dead)
  1.2       +52 -7     ports/math/atlas/files/patch-CONFIG+src+SpewMakeInc.c
  1.4       +0 -124    ports/math/atlas/files/patch-CONFIG+src+atlcomp.txt (dead)
  1.2       +88 -26    ports/math/atlas/files/patch-CONFIG+src+backend+archinfo_freebsd.c
  1.3       +14 -0     ports/math/atlas/files/patch-CONFIG+src+backend+archinfo_x86.c (new)
  1.1       +11 -0     ports/math/atlas/files/patch-makes+Make.sysinfo (new)
  1.5       +0 -12     ports/math/atlas/files/thread-patch (dead)
  1.1       +35 -0     ports/math/atlas/files/tuning-message (new)
  1.7       +17 -21    ports/math/atlas/pkg-descr
  1.11      +24 -48    ports/math/atlas/pkg-plist
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"