From mint-bounce@lists.fishpool.fi Wed Jun 9 12:51:08 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YviywN133AibysSp7B8urrKO8pTwiXNRiOvFE0CqGrs=; b=k/7bnEIbpsvWtu1K/h2E37jmFMC58VVhaFV5zmZ6FlKwuqdOtl/LaAKMilXMb228nJ qKmnUflC9QFcxK79rv+JZUGeLeicAkToCwkXC02k3QP28DRYIO0b+VeNFvSnFPm+60aS oylWM06x6INp6qFIPlQ9ToOiEEsYWazZwdLkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qBnFAUkrqHpGcJeSIQqCbJ150J6RDr/2mG81KY+zhkH21aBYuMSVEatSdUZ2pS8DF6 l1036uEYNMSNQueko2AlFoZc5/2jBzHoxK2BHiUp54XNV+1NKtF0PFzYaoNJOqILjaRi 9mGPsLZjTcrip3mEuH8F7tjht9SDTvrCtpF2k= Message-ID: <4C0FC5E4.5040306@freesbee.fr> Date: Wed, 09 Jun 2010 18:48:36 +0200 From: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: mint Subject: Re: [MiNT] MiNTLib 0.59.1 for your testing pleasure.... References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: vincent.riviere@freesbee.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Keith Scroggins wrote: > I would be surprised if all of those packages would fail to build in > GCC4. Others can speak to this more than I can, but there is not a huge > compatibility gap, unless there is assembly in the code. The incompatibilities are: 1) As Keith said, inline assembly has to be revisited. It is only present in very low-level packages, and the job has already been done in the MiNTLib, GemLib, FreeMiNT... So I'm sure there is not much inline assembly remaining in the packages. 2) The aggressive strict aliasing optimization enabled by default. This causes compile time warnings and sometimes bugs. If bugs are encountered, we can turn off that optimization manually with -fno-strict-aliasing and see if things improves. Then fix the source of the bug with the help of the warnings. I don't know anything else. These 2 kind of fixes will improve the code quality, the sources will remain compatible with GCC 2.x. Also, all the GNU/Linux packages have been fixed for GCC 4.x long ago, so the updated packages should compile out of the box. Alan can give us his experience on Gentoo. The big problem is the obsolescence of the MiNTLib/fdlibm versus Linux's GLIBC, but this is unrelated to GCC itself. However, there is still an important bug with GCC 4.x: the debug info produced in STABS format is often invalid. This cause GDB 5.x crashing or saying "cannot set breakpoint" or so on. GDB 7.x only produces a warning, but I have not finished porting it. Since this bug is specific to the obsolete a.out code generation in GCC, we can be sure no official developer would look at it. However, I have not fully investigated that issue, neither posted a bug report. -- Vincent Rivière