--- On Sat, 14/2/09, Ben Klein <shacklein(a)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.