Date: Tue, 15 Dec 1998 09:07:18 -0600 (CST) From: "M. L. Dodson" <bdodson@beowulf.utmb.edu> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: sysinstall Message-ID: <199812151507.JAA27744@beowulf.utmb.edu> In-Reply-To: <199812141107.DAA00420@dingo.cdrom.com> References: <199812091437.IAA03589@beowulf.utmb.edu> <199812141107.DAA00420@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith writes: > > If I might, I would like to suggest that any project along this > > line look to include g77 as well as C++ as part of the base > > system. This would help those of us interested in using FBSD for > > number crunching. I can generate some testing time, including > > compiling and testing some pretty hefty computational chemistry > > packages. Unfortunately, I'm a biochemist who knows about > > computers, not a computer scientist who knows about biochemistry, > > so my time would only be usefully used in a testing mode. > > Can you clarify for us why having g77 in the base system, rather than > an easily-installable and easily-upgradeable port would be worthwhile? > > Our current drive is to increase, not decrease, the modularity of the > system where possible; an addition like this would have to have a > compelling justification that was key to the system's functionality to > be considered. I'm absolutely sympathetic with a desire for modularity. The problem is specific to g77 (and, possibly, to other of the optional gnu compilers). You can't just install g77; you have to take, at least, a custom version of gcc along with it. That means that you have to juggle your path in order to pick up the correct versions of everything. Let me point out that people using this compiler are not likely to be as knowledgable as your ordinary "hackers" subscriber. I have had success getting things done in spite of this behavior, but it is a royal PITA. Not to mention the possible differences in code generation between the system gcc and the g77-specific gcc. I have no way of judging whether that might or might not be a general source of difficulty. I do have experience with the behavior of the regression tests accompanying some number crunching packages being dependent on the compiler optimization level chosen, in some quite unexpected ways. This is really important to us. A 5% speedup means something when a run is 2 weeks long. This is one of the PsITA I would like to avoid. Perhaps a compromise would be for the system gcc version to have the hooks for g77 already compiled in, together with a module (installed as a binary package to maintain version consistency, likely to be important if I can read between the lines of the development history of the egcs and gcc projects) which could be optionally installed. This package would have all the g77-specific stuff in it, but nothing else. Is this in any way feasible? Failing that, let me suggest a port/package for g77 which is absolutely synchronized with the system version of gcc, including a pointer to a FreeBSD-maintained source code tree. By that I mean no attempt to track the latest/greatest gcc/egcs/g77 combo, only the real bug fixes. The issues are the same as those governing the decision not to track the development of gcc/egcs/g77 with the system gcc, but to settle on a version and stay with it. Or possibly an environment variable-dependent makefile target in the /usr/src tree might produce a g77 synchronized with the system gcc? I guess another way of expressing my "problem" is that I would like g77 available to me in the same high quality way that the rest of the base FreeBSD is available to me. I don't perceive that to be the case now. For instance, I have never had any luck with the g77 ports. For various reasons, perhaps now fixed (I haven't tried in more than a year), they just never worked (perhaps I never had the right combinations of versions of everything needed?). I have always had to get the gcc or egcs sources and go through the regular gnu installation procedure (although the egcs port seems to work OK now). That seems to me an inferior way to go about things. In any case, thanks to you guys for hearing me out, no matter what your decision. And I remain available to help out on this, if anyone wants to follow up. Bud Dodson [deletia] -- M. L. Dodson bdodson@scms.utmb.edu 409-772-2178 FAX: 409-772-1790 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812151507.JAA27744>