From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <679d141b719c3cb9b9100dacbd917df6@proxima.alt.za> To: 9fans@cse.psu.edu Subject: Re: [9fans] GCC/G++: some stress testing Date: Sat, 1 Mar 2008 08:25:45 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 6a392ce0-ead3-11e9-9d60-3106f5b1d025 > It will no doubt be useful to us folks doing work for the gov't. They > DOE has lots of apps written for GCC or Fortran -- while there may be > other methods of accommodating these applications, having them "just > work" with GCC (particularly if the GCC fortran could be part of the > port) would help us a lot. It could also serve as a baseline for > performance/efficiency comparisons with other methodologies such as > linuxemu, etc. > My interpretation of what you're saying is that I ought to wrap up what I have in a format that can be installed successfully and more or less effortlessly, then present myself as the "maintainer" and get on with tracking the more recent releases. Unfortunately, there's quite a bit of effort required catching up with the missing documentation that would make the project more readily supported, namely the binary formats dhog implemented to match GCC's different function interfacing. In fact, the whole exercise is quite vast and lack of documentation (or understanding) makes it even larger. But we have a starting point and I would like to see some use of what we have before embarking on an even bigger task. If we can prove that the foundations are solid (GCC does compile itself, which is no small achievement), we may be able to draw some attention and funding from potential users. My time is free, when available, but more skilful resources may need to be paid for. > Similarly, I've been working with other folks at potentially using > Plan 9 (for instance with the RAMP project) -- they'd be much happier > if they knew they could compile apps with GCC. Well, Lyndon's suggestion seems useful, to go the ansi2knr route wherever possible and, my response, use CFront where C++ does not exceed its capabilities. GCC/G++ then becomes the last resort. But nn my opinion GCC does not really address the problem you mention. The Auto* tools are a much bigger problem where "they'd be much happier if they knew they could compile apps with GCC". I'm sure that translates into "if they could just type './configure; make install'". No one I know about is figuring that one out. But that's precisely why I posted, because someone out there _may_ need just GCC/G++ (fortran and Java included) and I would very much like to know. I can find ./configure examples by the bushelful, they are no good in my situation. ++L