From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b70281e9df653875 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-20 12:07:01 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!61.11.230.176!not-for-mail From: Andreas Almroth Newsgroups: comp.lang.ada Subject: Re: gcc/gnat 3.3 Date: Mon, 20 Oct 2003 20:04:56 +0100 Message-ID: References: <3f8fff8b$1_1@news.tm.net.my> NNTP-Posting-Host: 61.11.230.176 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1066676781 29567112 61.11.230.176 (16 [198985]) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en In-Reply-To: <3f8fff8b$1_1@news.tm.net.my> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Xref: archiver1.google.com comp.lang.ada:1224 Date: 2003-10-20T20:04:56+01:00 List-Id: Adrian Hoe wrote: > Hi, > > Has anyone built gcc/gnat 3.3 for Sparc Solaris 9? I tried to build one > from source but failed. Generated too many errors and I gave up. :( > > Thanks. I have built a CSW build for SPARC and Intel Solaris 8, found at http://www.blastwave.org. It does work with Solaris 9, but with the exception for that there is a problem with threads on SPARC (as noted by several sources). I still have the build tree for native Solaris 9 on one of the servers, so I might be able to schedule some time to test with other threading libraries than the native one. But please let me know if interested... The developers have changed the way of fiddling with threads (task control in the run-time) to cater for the change in the thread API in Solaris 9 in the later 5.01 source tree, but that change does not really work when incorporated into the GCC tree the way I have tested it. The former method was very very specific to how GCC produces the binaries, and the new method is somewhat less "hack'n'slashy", but I don't seem to get it to work though. The fault most likely on my side of course... Using a "clean" 5.xx would probably be a way to verify... BTW, just being curious, would you mind adding some meat on the "generated too many errors"? Just interested to know what went wrong... Cheers, Andreas