question on hurd-i386 Debian architecture
Dear DDs, Can anyone please explain why this architecture is named hurd-i386 rather that i386-hurd? Is there any rule that says that the OS name should come before CPU name? Pjotr Kourzanov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cross-compiling Debian packages
Eric Cooper wrote: Also, would you welcome patches that add the ability to handle packages built with alternative libc implementations, namely uClibc, Dietlibc and Newlib? Shall I file a bug report? In the meantime, can you make these available somewhere? (I'm interested in using dpkg-cross for a cross-gcc + uclibc toolchain.) Thanks. OK. Here is the stuff I've been playing with. A. For starters, you need to setup Debian-based GNU Libc based cross-toolchain for your architecture(s). This includes, in this order: 1. binutils 2. db1-compat 3. linux-kernel-headers 4. glibc 5. gcc I found this step to be the easiest. If you need more info, ask Nikita Youschenko. He has some pre-compiled binaries of those packages somewhere. Note the linux-kernel-headers, binutils and gcc are required to be installed for building the uClibc package. B. Update your dpkg. This patch (http://www.xs4all.nl/~kurzanov/debian/patches/dpkg-1.13.16-uclibc.patch) is needed to teach dpkg-architecture to allow for Debian architectures named X-Y. I used i386-uclibc, arm-uclibc and mipsel-uclibc. Feel free to add additional ones to debian/archtable and ostable. C. Update your dpkg-cross. This patch (http://www.xs4all.nl/~kurzanov/debian/patches/dpkg-cross-1.26-libcs.patch) is needed to teach dpkg-cross about existence of lib/debug, lib/diet/lib and lib/newlib and Debian architecures named X-Y (needed for uClibc). Feel free to add more to the lists in dpkg-cross.pl. D. Compile uClibc. Unfortunately, uClibc package is not designed for cross-supporting a a complete Debian distribution, so I had to modify it extensively with this patch. http://www.xs4all.nl/~kurzanov/debian/patches/uclibc-0.9.27-debian.patch. Compiling this package with just a 'dpkg-buildpackage -ai386-uclibc' should give you a workable set of .debs that you can 'dpkg-cross -ai386-uclibc' after which you get a /usr/i486-linux-uclibc, just as you get /usr/i486-linux-gnu with glibc. You also get uclibc-toolchain package with gcc wrappers. Note: during compilation you will get errors that i486-linux-uclibc-gcc can not be found. You can just do this somewhere in the $PATH: $ for x in ar as cpp g++ gcc ld nm ranlib readelf size strings strip; do\ ln -s /usr/bin/i486-linux-gnu-$x i486-linux-uclibc-$x\ done E. Voila! If you want to just try how it all works, point your apt at http://www.xs4all.nl/~kurzanov/debian/ and install the versions of dpkg, dpkg-cross, libuclibc0, libuclibc-dev, uclibc-toolchain-i386-linux-uclibc that can be found there. Good luck! Pjotr Kourzanov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: but ./configure makes it look so easy, or why cross compiling isn't always trivial
Peter Samuelson wrote: [Peter Kourzanov] For most of the packages, what is so different in cross-compilation in comparison to native? Whether or not 'configure' believes it can use tests of the form try compiling and running this little program to see what it does. If it is cross-compiling, it is forced to skip such tests and use predetermined default answers. Yes, sure. But all of that is hidden behind the ./configure, why should Debian package management be concerned with these differences? And even then, why can't I run these little tests remotely with e.g., rsh? Assuming that I already have an initial working environment on the host... ;-) Note that this can produce nefarious little bugs, if the defaults aren't correct for your target architecture. Note also that not all configure scripts are given these default answers - if they aren't, you get a warning from autoconf about not supporting cross compilation, and I *believe* --host fails entirely. All true. There are also many packages which build _and run_ utilities as part of the build process. Three of my packages do this, though in two cases it's Debian-specific, so could be edited without much difficulty. Most packages do not distinguish between compiler-for-the-host-system and compiler-for-the-target-system (what the Linux kernel makefiles call HOSTCC and CC). So those will require significant hacking in upstream configure scripts and makefile to teach them to detect, and use, two separate compilers. This is a major problem for cross-compiling the whole distribution. And this is the problem I would like seeing solved. Also, debian/rules must make sure not to run any testsuites when cross- compiling. This is generally not hard, but it *is* an extra thing to have to fix. Yes. There are... 25411 Debian packages according to my 'apt-cache stats' and what I would like is to just issue a 'dpkg-buildpackage -aHOST ' on every single one of them and get a .deb file(s) that could be then immediately installed on a HOST machine. Of the six or so packages I'm involved with, three of them need more than just '--host'. (And two of the others are arch:all, so there's no need to cross-compile them anyway.) If that's representative, you're looking at a *lot* of work by a *lot* of people to realise your dream. Well, that or a *lot* of work by you, to write and submit patches for all these packages. Yes. But if I can convince maintainers then I suppose this can become *less* work for a *lot* of people:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cross-compiling Debian packages
Nikita V. Youshchenko wrote: I have devoted some time cross-compiling a number of essential packages, with glibc-based, uclibc-based and dietlibc-based ARM and MIPS toolchains and found all of that not a huge problem at all, given that debian/rules is provisioned with proper calls to --host (as described by the earlier thread) and some extra tokens in DEB_BUILD_OPTIONS for passing uclibc and diet specific CC modifications. You may look at dpkg-cross ... I did, and I'm using it, thanks:-) What is the deal BTW with that new rewrite_dependencies (as of 1.26) producing bogus names with -dcv1 suffix? I had to comment 2 lines out of dpkg-cross script to make it work for libgpm for instance... Also, would you welcome patches that add the ability to handle packages built with alternative libc implementations, namely uClibc, Dietlibc and Newlib? Shall I file a bug report? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
Russ Allbery wrote: Thomas Bushnell BSG [EMAIL PROTECTED] writes: I'm one of the people who actually helped design the GNU Makefile and configure standards, and --host does not signal that you're cross-compiling. What signals that you are cross-compiling is a disagreement between --host and --build. That's the old way. Autoconf changed this in the current releases. Now, specifying --host signals that you're cross-compiling, whether it disagrees or not. Yes, this was not a backward compatible change. A lot of people were upset about it. And yes, it was a change in the GNU Makefile and configure standards. But see the current Autoconf manual: `--host=HOST-TYPE' the type of system on which the package will run. By default it is the same as the build machine. Specifying it enables the cross-compilation mode. That is to say the least a very confusing statement. But OK, I suppose that avoiding side-effects was not part of the reasoning behind this change;-( Also, why is it then not an error to pass --host=X together with --build=X? According to that description, this is the default and enables both cross-compilation as well as native mode at the same time!!! There's a long archived discussion on the Autoconf mailing list about it. Will look at it, thanks. Pjotr Kourzanov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cross-compiling Debian packages
Hi everyone! To continue the ./configure in debian/rules thread... Can anyone tell me what is the factual difference between a cross- and a native-build? I am aware only of an obvious limitation that a cross package build system can not rely on the cross-compiled binaries generated in the process (coreutils comes readily as an example)... So, why should the autoconf have this cross-compiling mode, when what is in fact needed is a way to let it still work despite the inability to execute built test programs? For the rest, the gcc packages already provide us with the softlinks to the compilers needed for the native build. The only thing missing is the link from DEB_HOST_GNU_TYPE to . in /usr. Given this, almost all essential packages just build out of the box for both native and cross builds equally well... I have devoted some time cross-compiling a number of essential packages, with glibc-based, uclibc-based and dietlibc-based ARM and MIPS toolchains and found all of that not a huge problem at all, given that debian/rules is provisioned with proper calls to --host (as described by the earlier thread) and some extra tokens in DEB_BUILD_OPTIONS for passing uclibc and diet specific CC modifications. Regards, Pjotr Kourzanov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
Hendrik Sattler wrote: Am Donnerstag, 9. März 2006 03:12 schrieb Russ Allbery: Thomas Bushnell BSG [EMAIL PROTECTED] writes: I'm one of the people who actually helped design the GNU Makefile and configure standards, and --host does not signal that you're cross-compiling. What signals that you are cross-compiling is a disagreement between --host and --build. That's the old way. Autoconf changed this in the current releases. Now, specifying --host signals that you're cross-compiling, whether it disagrees or not. Yes, this was not a backward compatible change. A lot of people were upset about it. And yes, it was a change in the GNU Makefile and configure standards. But see the current Autoconf manual: `--host=HOST-TYPE' the type of system on which the package will run. By default it is the same as the build machine. Specifying it enables the cross-compilation mode. That's insane. However, it doen't say anything about the sitution of --build and --host are used and both contain the same value. Work-around for the compiler could be to ship with symbolic links, e.g. gcc - gcc-4.0 - i686-linux-gcc-4.0 Which it already does:-) Now autoconf has no problem in finding the proper compiler even if not really cross-compiling, does it? Nothing I have seen in my practice. HS Pjotr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
Henrique de Moraes Holschuh wrote:
On Thu, 09 Mar 2006, Hendrik Sattler wrote:
`--host=HOST-TYPE'
the type of system on which the package will run. By default it
is the same as the build machine. Specifying it enables the
cross-compilation mode.
That's insane. However, it doen't say anything about the sitution of --build
Actually, what it was before was completely and utterly broken (not
necessarily in the design, for all I know it was an implementation snafu.
All I know is that cross-compiling with old autoconf is just plain
impossible unless you do practice dark arts).
Now you have this:
HOST: where you are doing the compilation
BUILD: where the code being built will run
TARGET: where code that the code being built will generate when run on a
BUILD box, will run (for cross-compiling cross-compilers and
toolchains, rarely used)
TARGET defaults to BUILD
BUILD defaults to HOST
HOST defaults to whatever (nothing, I think).
Host and Build meant the opposite on autoconf 2.13/automake1.4. IMHO the
new definitions are much better.
The following is for autoconf 2.5* and newer:
Specify HOST (through --host), and you immediately enter cross-compiling
mode. Specifiying --host in a Debian maintainer package build when not
crosscompiling is a bug, so don't do it.
For most of the packages, what is so different in cross-compilation in
comparison to native?
You must *always* specify BUILD (through --build) when building a Debian
package, it is required by Debian policy, and it MUST be set to the output
of dpkg-architecture -qDEB_BUILD_GNU_TYPE unless overriden.
If you need to specify TARGET then you'd rather better know more than I do
about crosscompiling and how to make that compliant to Debian policy.
and --host are used and both contain the same value.
If both build and host have the same value, you are cross-compiling to the
build architecture, on a host of the same architecture.
This *does* use different compilers for generating production code and
build-tools code, which might be a feature, for all I know. I'd ask all of
the porters if that is useful before touching it.
Work-around for the compiler could be to ship with symbolic links, e.g.
gcc - gcc-4.0 - i686-linux-gcc-4.0
Work around for what? Not for non-policy compliant, buggy packages, I
presume. Are users somehow being hit by this?
Or do you want to do this to avoid an ifeq..endif block in debian/rules
files that are currently required to detect if --host should be issued to
configure ?
Yes. There are... 25411 Debian packages according to my 'apt-cache
stats' and what I would like
is to just issue a 'dpkg-buildpackage -aHOST ' on every single one of
them and get a .deb file(s)
that could be then immediately installed on a HOST machine. Yes, I
understand that some packages
do require special handing (binutils, gcc, glibc,
linux-kernel-{image,headers}), but this number should
be limited to a (well-documented) minimal subset.
As I've indicated earlier, Debian is in fact quite close to this wet
dream of mine, it just misses on a
small number of annoying items such as '--host' and complications w.r.t.
endless ifeq...endif blocks
for uClibc or Dietlibc modifications to the CC command line in debian/rules.
rant
I don't know about all of you guys, but for embedded systems this is
quite a pre-requisite I suppose:
the ability to do automated cross-compiles of a complete system. Debian
was supposed to host most
archs after all, yes? Shouldn't we expend more effort in co-existance of
all these architectures?
/rant
Pjotr Kourzanov
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
