From mint-bounce@lists.fishpool.fi Thu Mar 27 08:12:25 2008 X-Belgacom-Dynamic: yes From: "J. F. Lemaire" To: mint@lists.fishpool.fi Subject: Re: [MiNT] Some comments on GCC 4 Date: Thu, 27 Mar 2008 12:43:08 +0100 User-Agent: KMail/1.9.9 References: <200803270951.11111.jflemaire@skynet.be> <1206609834.27157.4.camel@localhost> In-Reply-To: <1206609834.27157.4.camel@localhost> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Message-Id: <200803271243.08286.jflemaire@skynet.be> X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: jflemaire@skynet.be Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: On Thursday 27 March 2008, Alan Hourihane wrote: > On Thu, 2008-03-27 at 09:51 +0100, J. F. Lemaire wrote: > > - the file 'unistd.h' from CVS mintlib caused literally hundreds of > > errors, starting from line 461 (I haven't taken note of which ones > > though). I moved the file and copied over the one from the latest > > official mintlib and the errors went away; > > I would think you may not be including something before unistd which > may be required in your circumstance. Without seeing the errors I > can't say, but CVS mintlib unistd.h is fine. It's fixed now, the problem was related to the missing 'sys' folder, see below. > > - the folder ../include/sys has been replaced by ../include/bits in > > CVS. Is this normal? > > You should still have include/sys, as well as include/bits. It would appear there'd been a write error during install. 'sys' existed in 'include' but as a corrupted file. I copied manually 'sys' from the build directory and I have no issues now with 'unistd.h'. > > - the -s option given to GCC does not seem to result in stripping > > the binaries. > > Seems to work fine here, are you sure your application hasn't already > been stripped with the strip command ? Yes, I'm sure. If I strip it after compilation, the excutable becomes smaller, as expected. But the -s option has not effect here. Must be something wrong with my GCC build, then. On the other hand, stripped binaries are smaller than when compiled with GCC 2, which is good news. > > - the memory consumption of my program has increased from ca.340 KB > > to ca.400. > > Are you looking at the file size ? as memory consumption shouldn't > change. Not the file size, the memory consumption. The application uses more memory than when compiled with GCC 2.95.3 with the same compilation options. > > - the only new warning I had (which may or may not mean that my > > code is clean...) was 'dereferencing type-punned pointer will break > > strict-aliasing rules' on the following line: > > > > Col = (OBJC_COLORWORD *)&Tree[object].ob_spec.tedinfo->te_color; > > > > If I understand correctly, GCC 4 does not like the cast. Is there > > another way to get the colour index of an object than via a cast to > > OBJC_COLORWORD? > > That's a bug in your application, and you can use union's to fix this > type of problem. Probably, although my limited experience does not tell me how. Cheers, JFL -- Jean-François Lemaire