On Mon, 13 Aug 2007 00:57:04 +0200 Julien Cristau <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 12, 2007 at 23:21:05 +0100, Neil Williams wrote: > > > I'm not sure why you thought this would work because the debdiff > > contained no changes that would have resulted in the src/utils/Makefile > > using gcc in place of arm-linux-gnu-gcc because the critical variables > > are defined BEFORE CC_FOR_BUILD is even specified. THAT is why I had to > > use override. > > > What variables? makekeys_LINK, LINK and COMPILE. > src/utils/Makefile.in has 'CC = @CC_FOR_BUILD@', which > becomes 'CC = gcc' in src/utils/Makefile. But src/utils/Makefile does not exist. It is obj-x86_64-linux-gnu/src/utils/Makefile or obj-$(DEB_BUILD_GNU_TYPE)/src/utils/Makefile (from debian/rules) > I don't believe the only way to build makekeys with a native compiler is > using a gnu makeism. I only wish that such a method would actually work. > > What are you using to build at your end? What is it that makes you > > think that this can be solved without 'override' ? > > > I installed the libc6-dev-arm-cross and gcc-4.1-arm-linux-gnu from the > emdebian repo, symlinked /usr/include/X11 from > /usr/arm-linux-gnu/include/ (hopefully any differences here don't > matter), and ran dpkg-buildpackage -rfakeroot -B -aarm. > Of course the package doesn't build because I don't have some of the > necessary stuff, but it gets further than the makekeys stuff. So you don't have dpkg-cross installed? I think this is a completely different bug. I use emdebuild (part of emdebian-tools) which merely does some useful stuff to prepare patch files and then calls the dpkg-cross diversion of dpkg-buildpackage -rfakeroot -a$ARCH etc. to do the rest of the work. With a fully operational toolchain installed, dpkg-buildpackage fails at makekeys just like emdebuild (which is exactly what I would expect). > The log has: > /bin/sh ../../../libtool --tag=CC --mode=link arm-linux-gnu-gcc > -I../../../../include -I../../../../include/X11 -I../../../include > -I../../../include/X11 -I../../../../src/xcms -I../../../../src/xkb > -I../../../../src/xlibi18n -I../../../../src -Wall -Wpointer-arith > -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN > -DHAS_STICKY_DIR_BIT -D_BSD_SOURCE -DMALLOC_0_RETURNS_NULL -Wall -g > -O2 -o libxomGeneric.la omDefault.lo omGeneric.lo omImText.lo omText.lo > omTextEsc.lo omTextExt.lo omTextPer.lo omXChar.lo -ldl > arm-linux-gnu-ar cru .libs/libxomGeneric.a .libs/omDefault.o > .libs/omGeneric.o .libs/omImText.o .libs/omText.o .libs/omTextEsc.o > .libs/omTextExt.o .libs/omTextPer.o .libs/omXChar.o > arm-linux-gnu-ranlib .libs/libxomGeneric.a > creating libxomGeneric.la > (cd .libs && rm -f libxomGeneric.la && ln -s ../libxomGeneric.la > libxomGeneric.la) > make[4]: Leaving directory > `/home/julien/src/xsf/git/lib/libx11/obj-i486-linux-gnu/modules/om/generic' > make[4]: Entering directory > `/home/julien/src/xsf/git/lib/libx11/obj-i486-linux-gnu/modules/om' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory > `/home/julien/src/xsf/git/lib/libx11/obj-i486-linux-gnu/modules/om' > make[3]: Leaving directory > `/home/julien/src/xsf/git/lib/libx11/obj-i486-linux-gnu/modules/om' > make[3]: Entering directory > `/home/julien/src/xsf/git/lib/libx11/obj-i486-linux-gnu/modules' > make[3]: Nothing to be done for `all-am'. > make[3]: Leaving directory > `/home/julien/src/xsf/git/lib/libx11/obj-i486-linux-gnu/modules' > make[2]: Leaving directory > `/home/julien/src/xsf/git/lib/libx11/obj-i486-linux-gnu/modules' > Making all in src > make[2]: Entering directory > `/home/julien/src/xsf/git/lib/libx11/obj-i486-linux-gnu/src' > cd util && /usr/bin/make > make[3]: Entering directory > `/home/julien/src/xsf/git/lib/libx11/obj-i486-linux-gnu/src/util' > gcc -DHAVE_CONFIG_H -I. -I../../src -I../../include/X11 -I../../../src/util > -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Wnested-externs -fno-strict-aliasing > -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -Wall -g -O2 -MT > makekeys-makekeys.o -MD -MP -MF .deps/makekeys-makekeys.Tpo -c -o > makekeys-makekeys.o `test -f 'makekeys.c' || echo > '../../../src/util/'`makekeys.c In the same position, I get: arm-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../src -I../../include/X11 -I../../../src/util -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/arm-linux-gnu/include -I/usr/arm-linux-gnu/include -I/usr/arm-linux-gnu/include -Wall -g -O2 -MT makekeys-makekeys.o -MD -MP -MF .deps/makekeys-makekeys.Tpo -c -o makekeys-makekeys.o `test -f 'makekeys.c' || echo '../../../src/util/'`makekeys.c Wrong compiler. :-( Note that the actual values of the variables are NOT taken from the Makefile but from dpkg-buildpackage unless 'override' forces the reverse handling, as documented in GNU make. If I avoid the dpkg-cross diversion (dpkg-buildpackage.orig -rfakeroot -a$ARCH etc.) makekeys DOES compile under GCC and run. For now, I'm cloning this bug against dpkg-cross until I can get the dpkg-buildpackage.orig build to complete, at which point I'll let you know exactly what patch is or is not required for this bug. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgppkdxKZJ0zw.pgp
Description: PGP signature
