X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: problem with library search path when targeting mingw
Date: Mon, 14 Aug 2006 18:10:36 +0100
Message-ID: <006901c6bfc4$8f98d150$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <44E0A9E7.2030101@laposte.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On 14 August 2006 17:51, Damien Fouilleul wrote:

> I'm a big fan of cygwin and I use it a lot to compile mingw apps,
> however with the latest mingw-runtime, I'm having trouble running
> configure scripts successfully as test such 'dlopen() in -ldl', which
> used to fail for mingw target (as expected) now succeeds. This causes
> havoc in compilation as the resulting config.h file contains reference
> to APIs not supported by mingw.
> 
> after having a look at gcc -mno-cygwin -print-search-dirs, I think I may
> have found the culprit in the following element of the library search path:
> '/usr/lib/gcc/i686-pc-mingw/3.4.4/../../..', as this points back
> straight at /usr/lib, the cygin main library path. This means now that
> the following command
> 
> $ gcc -mno-cygwin dlopen-test.c -dl
> 
> Now passes with flying colors. I have to edit all my config.h as I do
> not know of any way to remove this path from the search paths
> 
> Similarily, I have a similar but less serious problems with headers
> paths for files such as math.h, float.h, these are available for both
> cygwin and mingw, but they are different files.Unfortunately,
> "/usr/lib/gcc/i686-pc-cygwin/3.4.4/include" has precedence over
> '/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/include'
> when targetting mingw by default, therefore the cygwin version is chosen
> over the mingw one.
> In 99% of cases, this is usually not a problem, as the files are nearly
> identical, but they are some Microsoft specific code in the mingw, which
> is required to compile Trolltech QT, for example.
> If i use the following compiler option '-isystem /usr/include/mingw',
> then everything works fine.

  Thanks for the report.  This has been mentioned before, it's a problem in
gcc's 'specs', which are command-line pattern matching strings (more-or-less)
used by the gcc compiler driver to select the right options for the
sub-programs that it invokes.  It's basically a consequence of the fact that
we're using the same driver to drive a native compiler /and/ a cross-compiler;
normally, a cross-compiler wouldn't include any of the system paths such as
/usr/lib at all, but for a native compiler that's exactly what you want it to
do.

  As there are a couple of packaging bugs in the (currently experimental) new
release of gcc-3.4.4-2, meaning I'll have to roll a new package anyway when
it's time to make it a proper full release, I'll try and take a look at a fix.
It shouldn't be too hard.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
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/