Santiago Vila wrote: > On Mon, 19 Nov 2007, Neil Williams wrote: > >> Santiago Vila wrote: >>> Would it work if both --build and --host are always used and only CC >>> is redefined ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) ? >> No. That would cause the native build to have --host defined which means >> that even native builds would look for a cross compiler. > > So what? It means on i386 the compiler to use would be > i486-linux-gnu-gcc-4.1, which is the same as the native compiler. > > What harm would do that?
Please read the thread on debian-devel - this has been covered time and time again and the recommendation from the README.Debian is meant to be the definitive answer to all these questions. There are situations where --build will prevent problems and there are situations where adding --host will cause problems in the package. The autotools standard is to specify --build always and --host only when cross compiling. I see no reason to deviate from this recommendation in the case of dialog. If you disagree with this, take it up on debian-devel. >> See the autotools-dev README.Debian - --build is needed for both, --host >> must only be specified when cross building. > > This is what README.Debian says: > >> BTW, autoconf 2.52+ should enter cross-compiling mode if --host is >> specified. It will build in cross-compiling mode even if build and >> host type are the same (this information comes directly from autoconf >> upstream). This goes against what is in the docs of autoconf 2.59, >> and it may be a bug somewhere. > > So, if it is a bug in autoconf, let us fix it in autoconf. > > In either case, I fail to see the difference between a "cross-compilation" > to the native architecture and a native compilation. A native build should not use a cross compiler in any form. > BTW: The CC setting comes from policy 10.1, Binaries: > > For the C programming language, this means the following compilation > parameters should be used: > > CC = gcc > CFLAGS = -O2 -g -Wall # sane warning options vary between programs > LDFLAGS = # none > INSTALL = install -s # (or use strip on the files in debian/tmp) If you want to keep that, then you must use the longer patch from the original bug report. Current Policy does not cover cross compiling and besides, the cross compiling support in Debian has been completely rewritten recently and the nature and level of changes that will be needed in Policy to reflect the current state of cross compiling in Debian has yet to be decided. All I'm saying is that dialog builds fine without hardcoding CC. You wanted a smaller patch and omitting CC allows for a smaller patch. You can't have it both ways. Retain CC and use the original patch or omit CC and use the smaller patch. > Should we drop such CC = gcc from policy? It think it is useful because > it allows Debian packages to be built on foreign OSes with gcc automatically. Fine, then keep the original patch. All this fuss over a few extra lines of a patch . . . This is a mass bug filing, the principles are those already agreed on debian-devel and are applied to all packages equally. If you disagree with the recommendations of the mass bug filing, please take this to debian-devel. The recommendation underpinning this mass bug filing and agreed on debian-devel is: All autotools packages should use --build for native and cross. All autotools packages should only use --host when cross compiling. If packages specify CC explicitly, this will need to be overridden to CC=$(DEB_HOST_GNU_TYPE)-gcc only when cross compiling. My original patch implements this recommendation. My alternative of omitting CC is a workaround that works for dialog but if you want to stick to the autotools standard, use the original patch. That's all there is to it. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
