X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,SPF_HELO_PASS,TW_RW,TW_WX,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com connect(): No such file or directory From: Paul Bibbings Subject: Re: gcc: building gcc-4.5.0 for Cygwin Date: Tue, 20 Apr 2010 20:28:43 +0100 Lines: 47 Message-ID: <87eii92aac.fsf@gmail.com> References: <87y6go3743 DOT fsf AT gmail DOT com> <4BC904E3 DOT 60500 AT verizon DOT net> <878w8lx1kt DOT fsf AT gmail DOT com> <4BCD9A2A DOT 9060906 AT gmail DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (windows-nt) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Dave Korn writes: > On 17/04/2010 21:32, Paul Bibbings wrote: > >> The .dlls in question are: >> >> 21:10:29 Paul Bibbings AT JIJOU >> ~ $ls -l /opt/gcc-4.5.0/bin | grep dll >> -rwxr-xr-x 1 ... 437743 Apr 15 09:08 cyggcc_s-1.dll >> -rwxr-xr-x 1 ... 271146 Apr 15 09:08 cyggomp-1.dll >> -rwxr-xr-x 1 ... 55679 Apr 15 09:08 cygssp-0.dll >> -rwxr-xr-x 1 ... 5829289 Apr 15 09:07 cygstdc++-6.dll >> >> Maybe I am missing something in having these in the first place. I >> didn't get any new .dlls for gcc-4.4.1, for instance: > > That'd be my fault. GCC never used to build DLLs for anything, except > libgcc, prior to 4.5. Now it does, for all languages. (At last, the simplest > possible "hello world" in java isn't 45 megabytes any more.) They install > into $bindir, because that's where they need to be to be found easily; > alongside the executables that require them. > > Like a lot of libraries, they occasionally sprout new interfaces, but they > should always remain backwardly-compatible. Applications compiled with older > GCC against older versions of the DLL ought to run just fine with the newer > ones (it's a bug if they don't), but of course applications compiled with the > newer compilers that actually make use of the new features in the newer > versions of the DLLs won't be able to work with older ones. > > From the end-user's point of view, the simple solution would be to not worry > about switching them round or alternatives or any of that, but just make sure > the newest ones are at the front of your $PATH at all times, you could even > feel free to install them straight into /usr/bin and just overwrite the > existing versions; everything should still work. This last is good to know, and would essentially solve the issue for me. I shall give it a try and report back only if I encounter problems. Thanks for the clarification. (BTW. I'm guessing by "That'd be my fault" that you're working on gcc upstream?) Regards Paul Bibbings -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple