1.1.15 failing to build -- what changed?

[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

[Ben Klein]

2009/2/14 Scott Ritchie <scott(a)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

[Ben Klein]

2009/2/14 Scott Ritchie <scott(a)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

[Roderick Colenbrander]

> 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
-- 
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

[Ben Klein]

Stupid Gmail sent my last mail twice, it seems.

2009/2/15 Roderick Colenbrander <thunderbird2k(a)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.

[James McKenzie]

Ben Klein wrote:
> Stupid Gmail sent my last mail twice, it seems.
>
> 2009/2/15 Roderick Colenbrander <thunderbird2k(a)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

[Hin-Tak Leung]

--- 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.

[Ben Klein]

2009/2/15 Hin-Tak Leung <hintak_leung(a)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?

[Hin-Tak Leung]

--- On Sun, 15/2/09, Ben Klein <shacklein(a)gmail.com> wrote:
> 2009/2/15 Hin-Tak Leung <hintak_leung(a)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 .

[Ben Klein]

2009/2/15 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>:
> --- On Sun, 15/2/09, Ben Klein <shacklein(a)gmail.com> wrote:
> > 2009/2/15 Hin-Tak Leung <hintak_leung(a)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

[Hin-Tak Leung]

--- On Sun, 15/2/09, Ben Klein <shacklein(a)gmail.com> wrote:
> 2009/2/15 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>:
> > --- On Sun, 15/2/09, Ben Klein
>
> <shacklein(a)gmail.com> wrote:
> > > 2009/2/15 Hin-Tak Leung
>
> <hintak_leung(a)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

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...

[Ben Klein]

2009/2/16 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>:
> --- On Sun, 15/2/09, Ben Klein <shacklein(a)gmail.com> wrote:
> > 2009/2/15 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>:
> > > --- On Sun, 15/2/09, Ben Klein
> >
> > <shacklein(a)gmail.com> wrote:
> > > > 2009/2/15 Hin-Tak Leung
> >
> > <hintak_leung(a)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
>
> 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.

[Scott Ritchie]

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