distfiles for lang/g95
I am the maintainer of lang/g95. The source tarball for this
software changes almost daily. I need to put a snapshot tarball
up to support the lang/g95 port. I will also need to make
available the gcc-core-4.0.3.tar.gz tarball as the lang/gcc40 port
has been removed, evidently. Specifically, how can I make the
tarballs available via ${MASTER_SITE_LOCAL}?
g95 is an important port for compiling scientific software. Using
gfortran is problematic for some important software and is
discouraged by the developers of the software in one case I know
of. In that case Intel fortran is the preferred compiler with g95
the second. gfortran may or may not work depending on the
vagaries of gfortran development at its time of installation. I
have had gfortran work one week and fail a month later using a new
installation. The scientific software developers have little
patience for this situation. Not all of us can satisfy the Intel
Fortran license requirements, but the cost of that compiler suite
cannot be easily absorbed.
g95 uses the gcc4.0 backend. I have had some success with gcc4.1,
but that is not an officially supported configuration. I will
communicate with the g95 developer to encourage the move to the
gcc4.1 backend, but meanwhile the port is broken because of the
inability to download the correct snapshot for g95, or correctly
install the port dependence.
Thanks,
Bud Dodson
--
M. L. Dodson
Email: mldodson-at-comcast-net
Phone: eight_three_two-five_63-386_one
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggested improvements for ports
Guido Falsi wrote: Mark Linimon wrote: On Fri, Jan 11, 2008 at 06:40:35PM +0100, Guido Falsi wrote: I think that too much formalization in the porting rules would harm the system. That seems to have been the community consensus in the past. Nevertheless, the PH could use some improvement. Most of what I've tried to put in there is "here's what we recommend as the preferred practice". There's not much "you can't do this" -- most of that deals with things that e.g. break INDEX or otherwise wreak havoc. Obviously some rules are needed to maintain the structure, I meant no attack to that. I simply wanted to say that I agree with the policy stated above. Putting rules like strict limiting numbers to items or the like would be against the ports logic. I think. This thread seems like one we covered in the recent past. I have held off until now, but I think people are missing the perspectives of many port maintainers, maybe most. Those I mean are subject experts that are not computer scientists. I am a biochemist, but I maintain two ports (neither a "biggie"). We, and I am so bold as to speak for this group, see the need for standards, wish the ports system was perfect, but also are very sensitive to the doctrine of "perfect as the enemy of good". We write ports because of convenience, by and large. Heavy requirements on port structure will just cause us to quit writing our ports, or cause us to keep them in house. In chemistry there is something called transition state theory. It posits that the rate of a reaction (here the likelihood I will write a port for a piece of software I use) is directly proportional to the inverse of the energetic barrier height between reactants and products. If you raise the barrier height by putting hard and fast requirements that are much more onerous than currently exist, you will see the rate of new port formation for other than "biggie" software fall dramatically. IMO. Please don't let the search for computer science elegance break the ports system. FreeBSD ports is the one place where the developers and the users meet on the street. Bud Dodson PS, by similar reasoning, I think the Ports 2.0 project is a loser in the real world. -- M. L. Dodson Email: mldodson-at-comcast-net Phone: eight_three_two-five_63-386_one ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggested improvements for ports
Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dominic Fandrey wrote: Paul Schmehl wrote: 1) You can't build a dependent port and first set the config for the options that you want. So, when you select sasl in postfix, you never get the chance to check the saslauthd option, for example. As the ports man page states: # make config-recursive does what you want. It's surprising how often people claim this feature is missing, even though it has been there ever since I started using FreeBSD. Not completely correct for reasons given in http://aegis.sourceforge.net/auug97.pdf - -- Aryeh M. Friedman FloSoft Systems, Java Developer Tools. http://www.flosoft-systems.com Developer, not business, friendly. That is completely off the point of the email to which you are responding. That is the way we do it in the FBSD ports system. We all know, as you have said ad nauseam, you believe the ports system is broken because of that. Why must you always hijack threads to make points for your agenda? Bud Dodson PS, I will refuse respond to the (almost guaranteed) passive aggressive flame you will use to respond to this post. -- M. L. Dodson Email: mldodson-at-comcast-net Phone: eight_three_two-five_63-386_one ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Help for a problematic port to replace biology/nab
I am the maintainer of biology/nab and asked that it be marked deprecated several months ago. I just filed a PR to have it removed. Nab has been superseded by AmberTools (also by the nab developers). I have the current version of AmberTools building with no problems from within a skeleton port. The problem (and I do not see any solution) is that AmberTools assumes that it will be built in its final installed location. This location is hardwired throughout the compiled code. The build process fails spectacularly if you specify some other location, then move the built code and data. Is there some secret method to handle such ports for which I do not possess the magical decoder ring? Any help would be appreciated. Bud Dodson -- M. L. Dodson Email: mldodson-at-comcast-net Phone: eight_three_two-five_63-386_one ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help for a problematic port to replace biology/nab
M. L. Dodson wrote: I am the maintainer of biology/nab and asked that it be marked deprecated several months ago. I just filed a PR to have it removed. Nab has been superseded by AmberTools (also by the nab developers). I have the current version of AmberTools building with no problems from within a skeleton port. The problem (and I do not see any solution) is that AmberTools assumes that it will be built in its final installed location. This location is hardwired throughout the compiled code. The build process fails spectacularly if you specify some other location, then move the built code and data. Is there some secret method to handle such ports for which I do not possess the magical decoder ring? Any help would be appreciated. Bud Dodson I just discovered the port depends on a 64-bit. Work around the patch rejection to get it to work on 32-bit, and I will fix it tomorrow. -- M. L. Dodson Email: mldodson-at-comcast-net Phone: eight_three_two-five_63-386_one ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help for a problematic port to replace biology/nab
M. L. Dodson wrote: M. L. Dodson wrote: I am the maintainer of biology/nab and asked that it be marked deprecated several months ago. I just filed a PR to have it removed. Nab has been superseded by AmberTools (also by the nab developers). I have the current version of AmberTools building with no problems from within a skeleton port. The problem (and I do not see any solution) is that AmberTools assumes that it will be built in its final installed location. This location is hardwired throughout the compiled code. The build process fails spectacularly if you specify some other location, then move the built code and data. Is there some secret method to handle such ports for which I do not possess the magical decoder ring? Any help would be appreciated. Bud Dodson I just discovered the port depends on a 64-bit. Work around the patch rejection to get it to work on 32-bit, and I will fix it tomorrow. The port (same location, same name) has been updated to handle both 64-bit and 32-bit systems. Did a cleanup edit that was ill advised. Thanks for the help. Bud Dodson -- M. L. Dodson Email: mldodson-at-comcast-net Phone: eight_three_two-five_63-386_one ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] graphics/raster3d -- replace g77 dependence by gfortran
Steve Kargl wrote:
diff -urN raster3d.old/Makefile raster3d/Makefile
--- raster3d.old/Makefile 2008-02-01 04:05:24.0 -0800
+++ raster3d/Makefile 2008-08-01 14:09:43.0 -0700
@@ -23,7 +23,8 @@
BINARIES= avs2ps balls rastep render ribbon rings3d rods normal3d
SCRIPTS= label3d stereo3d
-USE_FORTRAN= g77
+USE_FORTRAN= yes
+FFLAGS+= -fno-range-check
.if !defined(WITHOUT_IMAGEMAGICK)
RUN_DEPENDS= convert:${PORTSDIR}/graphics/ImageMagick
Applied patch.
[EMAIL PROTECTED]:85] % make
===> Building for raster3d-2.7.d_1
mv render.f render.f.bak
egrep -v '(CARRIAGECONTROL|DISPOSE)' render.f.bak > render.f
mv normal3d.f normal3d.f.bak
egrep -v '(CARRIAGECONTROL|DISPOSE)' normal3d.f.bak > normal3d.f
mv rastep.f rastep.f.bak
egrep -v '(CARRIAGECONTROL|DISPOSE)' rastep.f.bak > rastep.f
Making Raster3D 2.7d for freebsd
cc -O2 -fno-strict-aliasing -pipe -I/usr/include -I/usr/local/include
-DGUNZIP -DIMAGEPIPE -DTIFF_SUPPORT -DTIFF_INVERT -DJPEG_SUPPORT
-DPNG_SUPPORT -DLINUX -DNETWORKBYTEORDER -o avs2ps avs2ps.c -lm
gfortran42 -O -fno-range-check -o balls balls.f
gfortran42 -O -fno-range-check -c quadric.f
gfortran42 -O -fno-range-check -c suv.f
gfortran42 -O -fno-range-check rastep.f quadric.o suv.o -o rastep
gfortran42 -O -fno-range-check -c render.f
render.f:3687.72:
CALL ASSERT(TYPE(INEXT).EQ.VERTRANSP,'lost vertex transp'
1
Error: Syntax error in argument list at (1)
*** Error code 1
Stop in /usr/ports/graphics/raster3d/work/Raster3D_2.7d.
*** Error code 1
Stop in /usr/ports/graphics/raster3d.
--
M. L. Dodson
Email: mldodson-at-comcast-net
Phone: eight_three_two-five_63-386_one
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] graphics/raster3d -- replace g77 dependence by gfortran
Steve Kargl wrote:
On Fri, Aug 01, 2008 at 06:24:54PM -0500, M. L. Dodson wrote:
Steve Kargl wrote:
diff -urN raster3d.old/Makefile raster3d/Makefile
--- raster3d.old/Makefile 2008-02-01 04:05:24.0 -0800
+++ raster3d/Makefile 2008-08-01 14:09:43.0 -0700
@@ -23,7 +23,8 @@
BINARIES= avs2ps balls rastep render ribbon rings3d rods normal3d
SCRIPTS=label3d stereo3d
-USE_FORTRAN= g77
+USE_FORTRAN= yes
+FFLAGS+= -fno-range-check
.if !defined(WITHOUT_IMAGEMAGICK)
RUN_DEPENDS=convert:${PORTSDIR}/graphics/ImageMagick
Applied patch.
[EMAIL PROTECTED]:85] % make
gfortran42 -O -fno-range-check -c render.f
render.f:3687.72:
CALL ASSERT(TYPE(INEXT).EQ.VERTRANSP,'lost vertex transp'
1
Error: Syntax error in argument list at (1)
Arrgh. The source code has tabs embedded, which expands the
line past 72 columns. Tabs are illegal whitespace Fortran,
but most compilers assume 8 spaces.
Can you add -ffixed-line-length-none to FFLAGS?
Works now.
Bud Dodson
--
M. L. Dodson
Email: mldodson-at-comcast-net
Phone: eight_three_two-five_63-386_one
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
math/atlas does not build
Reproducibly stops at same place. This is probably pilot error, but I have no clue. Is this known? Any help appreciated. uname -a FreeBSD leucine.activesitedynamics.com 7.1-RELEASE-p1 FreeBSD 7.1-RELEASE-p1 #0: Thu Jan 8 17:33:50 CST 2009 mldod...@leucine.activesitedynamics.com:/usr/obj/usr/src/sys/LEUCINE amd64 tail -30 nohup.out STAGE 2-1-2: CacheEdge DETECTION make -f Makefile INSTALL_LOG/atlas_cacheedge.h pre=d 2>&1 | ./xatlas_tee INSTALL_LOG/dMMCACHEEDGE.LOG STAGE 2-1-3: LARGE/SMALL CASE CROSSOVER DETECTION STAGE 2-1-3: COPY/NO-COPY CROSSOVER DETECTION make -f Makefile INSTALL_LOG/dXover.h pre=d 2>&1 | ./xatlas_tee INSTALL_LOG/dMMCROSSOVER.LOG done. STAGE 2-1-4: LEVEL 3 BLAS TUNE make -f Makefile INSTALL_LOG/atlas_dtrsmXover.h pre=d 2>&1 | ./xatlas_tee INSTALL_LOG/dL3TUNE.LOG make -f Makefile dcblaslib 2>&1 | ./xatlas_tee INSTALL_LOG/dL3TUNE.LOG done. STAGE 2-1-5: GEMV TUNE make -f Makefile INSTALL_LOG/dMVRES pre=d 2>&1 | ./xatlas_tee INSTALL_LOG/dMVTUNE.LOG *** Error code 255 Stop in /usr/ports/math/atlas/work/ATLAS/NON_THREADED_PIC. *** Error code 1 Stop in /usr/ports/math/atlas/work/ATLAS/NON_THREADED_PIC. *** Error code 1 Stop in /usr/ports/math/atlas. The tail of work/ATLAS/NON_THREADED_PIC/bin/INSTALL_LOG/dMVTUNE.LOG is: . . . res/dgemvN_3_75 : 1415.462812 MFLOPS res/dgemvN_3_75 : 839.783499 MFLOPS res/dgemvN_3_75 : 302.153636 MFLOPS res/dgemvN_3_75 : 852.47 MFLOPS res/dgemvN_3_75 : VARIATION EXCEEDS TOLERENCE, RERUN WITH HIGHER REPS. ATL_gemvN_mm.c : 683.87 ATL_gemvN_1x1_1.c : 572.26 *** Error code 255 Stop in /usr/ports/math/atlas/work/ATLAS/NON_THREADED_PIC/tune/blas/gemv. *** Error code 1 Stop in /usr/ports/math/atlas/work/ATLAS/NON_THREADED_PIC/bin. -- M. L. Dodson Email: mldodson-at-comcast-net Phone: eight_three_two-five_63-386_one ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port lang/g95 out of date
Peter Jeremy wrote: Hi, I have run into some issues with lang/g95 and, following discussion with Andy Vaught, have realised that the FreeBSD port is somewhat out of date. A newer version is available at http://ftp.g95.org/v0.91/g95_source.tgz Do you have any plans to update the port? I no longer use G95, having gone over to gfortran for my needs since it became able to compile the software I use. If you want to take it over, please feel free. Otherwise, I will update the port some time in the next few weeks, then ask I be taken off as maintainer when I send in the new port. The problem with G95 is, as has been pointed out on the list, the rather old version of gcc used as the basis. There are good reasons to go with later versions of gcc for general use, and G95 then requires (yet another) version of gcc be installed. I have spoken about this a couple of years ago with Andy Vaught, but he seemed to not have plans at that time to bring that aspect up to date. Bud Dodson -- M. L. Dodson Email: mldodson-at-comcast-net Phone: eight_three_two-five_63-386_one ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] USE_FORTRAN knob has been added
Hello, Thanks for the USE_FORTRAN knob. Are there plans to add g95 to the list of supported Fortran compilers? In an earlier communication, I mentioned that AMBER, a molecular mechanics software suite I use, would not compile with gfortran. I tested gfortran and AMBER two days ago, and gfortran is now able to compile AMBER. On benchmarks, however, gfortran showed only approximately 70% of the performance of g95 on compute-bound benchmarks. The benchmarks were run with a dual core AMD64 and FreeBSD-CURRENT of a very recent date. The schedsmp.diff diff was applied. I do not have a Linux install on the machine ready to compare, but the FreeBSD / g95 combination is now able to keep pace with published Linux benchmarks (same software). These benchmarks are 100% compute-bound. Bud Dodson -- M. L. Dodson Email: mldodson-at-houston-dot-rr-dot-com Phone: eight_three_two-five_63-386_one ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
