Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Date: Wed, 14 May 2003 14:49:18 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Help cross compiling for MingW32 standalone executables. Message-ID: <20030514184918.GC12866@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i On Wed, May 14, 2003 at 01:52:10PM -0400, Bill C. Riemers wrote: >>I was wondering if you knew something I didn't. :-) I didn't remember >>any solution to this problem but with my aging brain that is >>unsurprising. >> >>IIRC, the real problem here was in binutils. There was no way to get >>ld to stop searching /usr/lib. > >I do not believe this is the real problem. If it was, then the >configure script would also find libjpeg.a from /usr/lib .... The only >library it finds that it shouldn't is libm.a. I maintain binutils. I know what the problem is. If 'gcc -mno-cygwin' could be made to never search /usr/lib that would solve many -mno-cygwin problems. I expended considerable effort trying to ensure that gcc does not search /usr/include/mingw for header files and does not include /usr/lib on the command file when calling ld or collect2. I never got around to doing the same thing for ld, though. ld knows about /usr/lib "implicitly". >While I believe creating an empty libm.a would solve this particular >problem, doing that inside the an autoconf macro is definitely the wrong >place for that solution. I was not suggesting doing this in an autoconf macro. Do it once and forget about it. >Especially, since this might break the build if later the bug is fixed >in mingw, or a libm.a is added as part of mingw. If that type of hack >is neccissary it should be done in the gcc-mingw postinstall script. If libm.a is added to the mingw-runtime release it will overwrite your empty file. There isn't any mingw bug here. mingw is allowed to not have a libm.a file. gcc/ld just shouldn't be finding cygwin's libm.a. The suggestion was to get you up and running. It was intended to be a quick fix. Since it would have taken ten seconds to type and involved no code changes at all, I thought it was a clear win. Obviously you think differently, so I'll bow out of this discussion now since I have nothing further to add. cgf >For a configure script it looks like I can change AC_CHECK_LIB(m,sqrt) to: > >AC_CHECK_LIB(msvcrt,sqrt,AC_CHECK_LIB(msvcp60,mbrlen),AC_CHECK_LIB(m,sqrt)) >I can both avoid the problem of bogus libm.a detection, and avoid using >msvcp60 under cygwin builds. > >The only problem remaining, is I'm not certain if I should use msvcrt, >msvcrt20 or msvcrt40, since I do not know what the difference is between >these libraries. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/