[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] gcc install directories and libgomp build fai

From: Mark Brand
Subject: Re: [Mingw-cross-env-list] gcc install directories and libgomp build failure
Date: Fri, 19 Aug 2011 09:04:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0

On 08/19/2011 01:29 AM, Tony Theodore wrote:
Hi Mark,

On 19 August 2011 05:36, Mark Brand<address@hidden>  wrote:

Yesterday there was an unexpected change to the gcc configuration in
mingw-cross-env on my 64-bit opensuse factory system. Files previously
installed under
are now installed under

I don't know what caused this change, but I speculate that it might have to
do with recently updated opensuse packages.

I discovered this while investigating why building libgomp's test program
suddenly started to fail due to omp.h not being found. Libgomp continues to
install omp.h in<mce>/usr/lib/gcc/i686-pc-mingw32/4.6.1/include, which I
guess is a directory no longer in the include search path since the change
in gcc configuration.

I'm a bit over my head here. Does someone here have an idea about what
caused the gcc configuration to change? Could it be that 'lib64' is actually
right? If so, what about libgomp?
I'd say libgomp is doing the right thing, but gcc is partly building
as a multi-lib. I won't have chance to look at it before tomorrow, but
the first thing I'd is try explicitly passing --disable-multilib to
gcc's ./configure (and probably binutils as well).

Thanks for the hint. Passing --disable-multilib to both gcc and binutils' configure makes no difference.

Next I tried passing --libdir='$(PREFIX)/lib' to gcc's configure. This seems to work and building libgomp succeeds. All files are now installed under <mce>/usr/lib.

Binutils still installs <mce>/usr/lib64/libiberty.a, which differs from <mce>/usr/i686-pc-mingw32/lib/libiberty.a. This is the only file under <mce>/usr/lib64. I guess this is correct. Passing --libdir='$(PREFIX)/lib' to binutils' configure does not change this.

I'm wondering if the --libdir hack should be checked in. I don't know the mechanism by which gcc chooses between lib and lib64 for libdir, apparently influenced by something in the operating system. I notice that the configure output includes: configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu, I wonder if that script is part of the story. Do you know how to tell if the script is broken?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]