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.
Responsible Changed From-To: freebsd-ports-bugs->maho The situation wants that maho@ is maintainer of all three ports.
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)
State Changed From-To: open->feedback Could you please explain more about the defect?
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
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
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.
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.
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!
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.
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.
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
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
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.
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.
State Changed From-To: feedback->open Not sure what the latest patch is supposed to do, but certainly feedback has been received here.
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.
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.
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
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
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"
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"
State Changed From-To: open->closed this was committed on 30 Aug 2010.
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"