|
From: | Mark Brand |
Subject: | Re: [Mingw-cross-env-list] gcc install directories and libgomp build failure |
Date: | Fri, 19 Aug 2011 18:37:27 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 |
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?
Just a quick update. libmikmod needs an explicit --libdir as well. Besides that, everything builds successfully now. See attached patch for the --libdir workarounds. I still don't know how clean this solution is.
Mark
fix-libdir.export
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |