1.1.15 fails to build using an identical layout to 1.1.14, which means something has changed with either the build dependencies or the way configure is working.
Here's the build failure I'm getting on amd64, but it fails on all arches: http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_1...
I'm going to sleep now, but hopefully I'll figure this out Valentine's day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages just yet.
Thanks, Scott Ritchie
2009/2/14 Scott Ritchie scott@open-vote.org:
1.1.15 fails to build using an identical layout to 1.1.14, which means something has changed with either the build dependencies or the way configure is working.
Worked for me on my Debian build environments. No changes required ...
Here's the build failure I'm getting on amd64, but it fails on all arches: http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_1...
This is the snippet that includes the failure:
make[3]: Entering directory `/build/buildd/wine-1.1.15~winehq0~ubuntu~8.10/dlls/acledit' x86_64-linux-gnu-gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -Wall -g -O2 -o main.o main.c ../../tools/winegcc/winegcc -b x86_64-linux-gnu -m32 -B../../tools/winebuild -shared ./acledit.spec main.o -o acledit.dll.so -lkernel32 ../../libs/port/libwine_port.a -L/build/buildd/wine-1.1.15~winehq0~ubuntu~8.10/debian/libtmp sh: x86_64-linux-gnu-as: not found winebuild: x86_64-linux-gnu-as --32 failed with status 32512 winegcc: ../../tools/winebuild/winebuild failed
Looks like a broken build environment to me.
I'm going to sleep now, but hopefully I'll figure this out Valentine's day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages just yet.
Thanks, Scott Ritchie
2009/2/14 Scott Ritchie scott@open-vote.org:
1.1.15 fails to build using an identical layout to 1.1.14, which means something has changed with either the build dependencies or the way configure is working.
Worked for me on my Debian build environments. No changes required ...
Here's the build failure I'm getting on amd64, but it fails on all arches: http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_1...
This is the snippet that includes the failure:
make[3]: Entering directory `/build/buildd/wine-1.1.15~winehq0~ubuntu~8.10/dlls/acledit' x86_64-linux-gnu-gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -Wall -g -O2 -o main.o main.c ../../tools/winegcc/winegcc -b x86_64-linux-gnu -m32 -B../../tools/winebuild -shared ./acledit.spec main.o -o acledit.dll.so -lkernel32 ../../libs/port/libwine_port.a -L/build/buildd/wine-1.1.15~winehq0~ubuntu~8.10/debian/libtmp sh: x86_64-linux-gnu-as: not found winebuild: x86_64-linux-gnu-as --32 failed with status 32512 winegcc: ../../tools/winebuild/winebuild failed
Looks like a broken build environment to me.
I'm going to sleep now, but hopefully I'll figure this out Valentine's day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages just yet.
Thanks, Scott Ritchie
1.1.15 fails to build using an identical layout to 1.1.14, which means something has changed with either the build dependencies or the way configure is working.
Here's the build failure I'm getting on amd64, but it fails on all arches: http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_1...
I'm going to sleep now, but hopefully I'll figure this out Valentine's day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages just yet.
Thanks, Scott Ritchie
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'.
Personally I consider it a misconfigured build system. It can be fixed by installing the proper binutils package for this architecture which I'm sure debian has. The same should be done for your ubuntu packages. You can't expect apps to build if you only have one half of the build apps (the compiler).
Roderick
Stupid Gmail sent my last mail twice, it seems.
2009/2/15 Roderick Colenbrander thunderbird2k@gmx.net:
1.1.15 fails to build using an identical layout to 1.1.14, which means something has changed with either the build dependencies or the way configure is working.
Here's the build failure I'm getting on amd64, but it fails on all arches: http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_1...
I'm going to sleep now, but hopefully I'll figure this out Valentine's day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages just yet.
Thanks, Scott Ritchie
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'.
This is interesting. I don't do this in my build system; I have chroots of each distro I build and a script that automates most of the work. I just run ./configure --verbose, pretty much, but I've installed a bunch of optional libs (like gphoto and such).
Personally I consider it a misconfigured build system. It can be fixed by installing the proper binutils package for this architecture which I'm sure debian has. The same should be done for your ubuntu packages. You can't expect apps to build if you only have one half of the build apps (the compiler).
That's what I was thinking too. Broken and/or misconfigured build environment.
Ben Klein wrote:
Stupid Gmail sent my last mail twice, it seems.
2009/2/15 Roderick Colenbrander thunderbird2k@gmx.net:
1.1.15 fails to build using an identical layout to 1.1.14, which means something has changed with either the build dependencies or the way configure is working.
Here's the build failure I'm getting on amd64, but it fails on all arches: http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_1...
I'm going to sleep now, but hopefully I'll figure this out Valentine's day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages just yet.
Thanks, Scott Ritchie
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'.
This is interesting. I don't do this in my build system; I have chroots of each distro I build and a script that automates most of the work. I just run ./configure --verbose, pretty much, but I've installed a bunch of optional libs (like gphoto and such).
Personally I consider it a misconfigured build system. It can be fixed by installing the proper binutils package for this architecture which I'm sure debian has. The same should be done for your ubuntu packages. You can't expect apps to build if you only have one half of the build apps (the compiler).
That's what I was thinking too. Broken and/or misconfigured build environment.
Please be aware that my MacOSX build based on Mike Kronenberg's build environment completed without any errors.
James McKenzie
--- 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.
2009/2/15 Hin-Tak Leung hintak_leung@yahoo.co.uk:
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.
Are you sure nothing in the build environment just happened to change in the last 2 weeks or so?
--- On Sun, 15/2/09, Ben Klein shacklein@gmail.com wrote:
2009/2/15 Hin-Tak Leung hintak_leung@yahoo.co.uk:
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.
Are you sure nothing in the build environment just happened to change in the last 2 weeks or so?
Well, I do my weekly fedora update, so a few hundred MB changes weekly. Given that this problem happens with both Debian/Ubuntu systems and fedora, this week... and I have had my rpmbuild system working smoothly for about a year...
If I am going to guess, I think the change has something to do with cross-compiling, instead of just the occasional -m32 .
2009/2/15 Hin-Tak Leung hintak_leung@yahoo.co.uk:
--- On Sun, 15/2/09, Ben Klein shacklein@gmail.com wrote:
2009/2/15 Hin-Tak Leung hintak_leung@yahoo.co.uk:
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.
Are you sure nothing in the build environment just happened to change in the last 2 weeks or so?
Well, I do my weekly fedora update, so a few hundred MB changes weekly. Given that this problem happens with both Debian/Ubuntu systems and fedora, this week... and I have had my rpmbuild system working smoothly for about a year...
If I am going to guess, I think the change has something to do with cross-compiling, instead of just the occasional -m32 .
scguy318 just brought this to my attention on IRC: http://bugs.winehq.org/show_bug.cgi?id=17340
--- On Sun, 15/2/09, Ben Klein shacklein@gmail.com wrote:
2009/2/15 Hin-Tak Leung hintak_leung@yahoo.co.uk:
--- On Sun, 15/2/09, Ben Klein
shacklein@gmail.com wrote:
2009/2/15 Hin-Tak Leung
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.
Are you sure nothing in the build environment just
happened
to change in the last 2 weeks or so?
Well, I do my weekly fedora update, so a few hundred
MB changes weekly. Given that this problem happens with both Debian/Ubuntu systems and fedora, this week... and I have had my rpmbuild system working smoothly for about a year...
If I am going to guess, I think the change has
something to do with cross-compiling, instead of just the occasional -m32 .
scguy318 just brought this to my attention on IRC: http://bugs.winehq.org/show_bug.cgi?id=17340
Argh... the original reporter of that bug seems to be rather mistaken - there is no need to have a separate cross-compile tool chain on 64-bit fedora (which I am also using) to build 32-bit applications. Just passing -m32 to both the compiler (CFLAGS for c , CXXFLAGS for c++ code and FFLAGS for fortrans) and the linker (LDFLAGS) would do.
So to make it work for one person's peculiar build environment, everybody else's normal environment has to break...
2009/2/16 Hin-Tak Leung hintak_leung@yahoo.co.uk:
--- On Sun, 15/2/09, Ben Klein shacklein@gmail.com wrote:
2009/2/15 Hin-Tak Leung hintak_leung@yahoo.co.uk:
--- On Sun, 15/2/09, Ben Klein
shacklein@gmail.com wrote:
2009/2/15 Hin-Tak Leung
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.
Are you sure nothing in the build environment just
happened
to change in the last 2 weeks or so?
Well, I do my weekly fedora update, so a few hundred
MB changes weekly. Given that this problem happens with both Debian/Ubuntu systems and fedora, this week... and I have had my rpmbuild system working smoothly for about a year...
If I am going to guess, I think the change has
something to do with cross-compiling, instead of just the occasional -m32 .
scguy318 just brought this to my attention on IRC: http://bugs.winehq.org/show_bug.cgi?id=17340
Argh... the original reporter of that bug seems to be rather mistaken - there is no need to have a separate cross-compile tool chain on 64-bit fedora (which I am also using) to build 32-bit applications. Just passing -m32 to both the compiler (CFLAGS for c , CXXFLAGS for c++ code and FFLAGS for fortrans) and the linker (LDFLAGS) would do.
So to make it work for one person's peculiar build environment, everybody else's normal environment has to break...
Only when using --target and --host flags (which I don't use because I have chroots, so I didn't notice the change), but I get your point.
Roderick Colenbrander wrote:
1.1.15 fails to build using an identical layout to 1.1.14, which means something has changed with either the build dependencies or the way configure is working.
Here's the build failure I'm getting on amd64, but it fails on all arches: http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_1...
I'm going to sleep now, but hopefully I'll figure this out Valentine's day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages just yet.
Thanks, Scott Ritchie
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'.
Personally I consider it a misconfigured build system. It can be fixed by installing the proper binutils package for this architecture which I'm sure debian has. The same should be done for your ubuntu packages. You can't expect apps to build if you only have one half of the build apps (the compiler).
Roderick
I've tried manually build-depending on the binutils and binutils-multiarch packages, however neither fix the build failure. I'm not quite sure what I'm looking for here.
Thanks, Scott Ritchie