Mail Archives: cygwin/2006/08/14/13:10:51
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/
- Raw text -