--- On Sat, 14/2/09, Ben Klein shacklein@gmail.com wrote:
A packager of a debian based distro reported the same
issue. They are doing:
CFLAGS="$(CFLAGS)"
LDFLAGS="$(LDFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=$${prefix}/share/man --infodir=$${prefix}/share/info $(CONFFLAGS)
Where the two DEB_* variables are: DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture
-qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture
-qDEB_BUILD_GNU_TYPE)
When building 32-bit packages DEB_HOST_GNU_TYPE is set
to i486-linux-gnu and this results in 'i486-linux-gnu-as not found'.
I have a similiar problem on fedora 10 x86_64 via an rpm driven build process. rpmbuild has a macro %configure which does ./configure --host=%{_host} --build=%{_build}
I have managed to work around the problem by creating x86_64-redhat-linux-{as,ld,nm} sym-links to {as,ld,nm}. (x86_64-redhat-linux-{gcc,g++,...} already exists). But I wish I didn't have to do that.
I have no idea why suddenly at wine 1.1.15 it requires the x86_64-redhat-linux-{as,ld,nm} form of the binutils tools. It seems to treat x86_64 suddenly as a cross-compiling environment.