www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/05/14/14:50:03

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
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 <cgf-rcm AT cygwin DOT com>
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
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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019