From owner-freebsd-ports@FreeBSD.ORG Sat Dec 11 14:31:29 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC0DC16A4CF for ; Sat, 11 Dec 2004 14:31:29 +0000 (GMT) Received: from mx3.utmb.edu (mx3.utmb.edu [129.109.195.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DFC243D2D for ; Sat, 11 Dec 2004 14:31:29 +0000 (GMT) (envelope-from bdodson@scms.utmb.edu) Received: from histidine.utmb.edu (histidine.utmb.edu [129.109.65.24]) by mx3.utmb.edu (8.12.11/8.12.11) with ESMTP id iBBESxqq018379; Sat, 11 Dec 2004 08:28:59 -0600 Received: from localhost (localhost [[UNIX: localhost]]) by histidine.utmb.edu (8.12.11/8.12.11/Submit) id iBBEVQLo023869; Sat, 11 Dec 2004 08:31:26 -0600 (CST) (envelope-from bdodson@scms.utmb.edu) X-Authentication-Warning: histidine.utmb.edu: bdodson set sender to bdodson@scms.utmb.edu using -f From: "M. L. Dodson" Organization: University of Texas Medical Branch To: freebsd-ports@freebsd.org Date: Sat, 11 Dec 2004 08:31:25 -0600 User-Agent: KMail/1.7.1 References: <41B8DCD3.1080009@math.missouri.edu> <200412100846.25288.bdodson@scms.utmb.edu> <20041211141449.73155dc7@Magellan.Leidinger.net> In-Reply-To: <20041211141449.73155dc7@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412110831.25529.bdodson@scms.utmb.edu> X-Proofpoint-Spam-Details: rule=notspam score=0 mlx=0 adultscore=0 adjust=0 version=2.1.0-04121000 cc: Alexander Leidinger Subject: Re: distfile for lang/ifc X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bdodson@scms.utmb.edu List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 14:31:30 -0000 On Saturday 11 December 2004 07:14 am, Alexander Leidinger wrote: > On Fri, 10 Dec 2004 08:46:25 -0600 > > "M. L. Dodson" wrote: > > > > just copied the port, changed the distfile specs in the Makefile > > > > to point to the one I had, did a "make makesum", and it compiled > > > > and worked with no problem (this was with fortran, version 7, I > > > > think). > > > > > > This doesn't work with the update from 8.0 to 8.1 (at least this > > > wasn't the case for icc, and ifc seems to be similar to icc). > > > > Well that's good and bad. I use ifc to compile a molecular > > mechanics suite called AMBER (not freely available). A F90 or > > later compiler is required, so g77 won't suffice. The AMBER > > mailing list has documented that only certain versions of ifc v8 > > will (1) compile the key AMBER program, and (2) generate code > > which can reproduce known good trajectories (generated by earlier > > AMBER code compiled with many different compilers, not just g77). > > These new differences from one minor version to another increase > > the work necessary to work around the Intel compilers > > "peculiarities". On the up side, WHEN THEY WORK, the Intel > > compilers produce easily demonstrably faster code. > > From v8.0 to v8.1 it isn't a minor upgrade like the 8.0.x versions... at > least not when looking at the "internals" of the compiler (I don't have > access to the source, this is purely based upon my experience with the > update of lang/icc, and lang/ifc is based upon the icc port). The > installation procedure changed a lot and some internals (compiler/libs) > changed too. Since we don't use Intels installation procedure and we > need to "fixup" some parts to be able to produce native FreeBSD > binaries, this was a major update from the FreeBSD port perspective. > > Bye, > Alexander. OK, that makes sense. BTW, I certainly did not mean to imply that you or the maintainer were part of the problem. I was just trying to issue caveats to people about using the compilers. I assume many people that qualify for the noncommercial versions are using them in an academic environment to do serious (physics, chemistry, engineering, ...) research. I do not think the AMBER guys know what the problem with some versions of the compiler is, but they know when a compile will not complete or the benchmark gives the wrong answers. They have reported their results back to Intel, but have on some occasions, but not all, apparently been ignored or told that no fix will be forthcoming. If it is really important to you that the compiler "get it right", you need to have your own validation suite, IMO. Bud Dodson -- M. L. Dodson bdodson@scms.utmb.edu 409-772-2178 FAX: 409-772-1790