On Sat, Oct 18, 2008 at 02:50:38PM +0300, Adrian Bunk wrote:
quoted text
> > this is becoming off-topic, but there are some points which need to be
> > addressed. Please if you want to reply afterwards, be kind to strip the
> > CC list.
> 
> sorry, but you can't publically spread misinformation (and even repeat 
> wrong things I already replied to earlier in this thread) and then 
> demand to not have the reply public.

It's not about not having it public, it's about not flooding people's
mailboxes with off-topic mails.

quoted text
> > On Sat, Oct 18, 2008 at 01:04:01PM +0300, Adrian Bunk wrote:
> > I'm not judging that, they build like they want. If they want to build
> > on the final target and have as many build machines as they support,
> > it's their problem. It's just very amateurish.
> 
> Debian does it, it works, and there's nothing amateurish about it - it's 
> much easier than coping with all the problems faced with when trying to 
> cross-compile > 12.000 source packages.

It's easier as long as you have one build environment very close to the
target, which tends not to be possible anymore as time passes or for too
small devices.

quoted text
> With <= 3 build machines per architecture.

and why not have 3 build machines at all ?

quoted text
> > > Scratchbox [1], e.g. used for building the software in Nokias Internet 
> > > Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted 
> > > cross-compilation environment.
> > > 
> > > Yes, it works.
> > 
> > I'm not saying it does not work, I'm saying it's far from being practical
> > when you want to support multiple architectures or targets, and that it
> > will do nasty things under you without letting you know.
> 
> Scratchbox easily allows switching between targets, no matter which 
> architectures they are for.
> 
> Can you describe the problems you have experienced more precisely?

Adrian, don't try to make me look like dumb by asking for specific
problems. Problems range from auto-detection of kernel version to
enable or disable feature X or Y, to endian detection and bit width
detection. If you don't believe me, it's just that you're used to
build completely OS-agnostic packages, which is perfectly fine, but
that doesn't seem to be completely the case given that you're feeling
you will get annoyed by breaking the openssl BUILD environment if
you make it run on a different kernel. *That* is the funny part,
since this build environment should not even require to run on Linux
at all! And believe me, I know that openssl is boring to build due
to many hard-coded things which require patching (mainly paths if my
memory is correct). But once that's done, it's done forever.

quoted text
> > A build environment is what it is, a build environment. It contains
> > compilers, shells to run scripts, various interpreters and build tools,
> > possibily debuggers and editors, versionning systems, etc...
> 
> The build environment in the chroot is the correct release.    

No it isn't because you're saying that some of the packages check for
kernel version which is not the right one. So if you move your chroot
to another machine, it is susceptible to break because it relies on
the host's kernel version. So your chroot is not your build environment,
it's just part of it.

quoted text
> > > Userspace ABIs of the kernel are usually stable.
> > 
> > Yes but they are not necessarily forward-compatible. If openssl believes
> > some feature is present in 2.6.521 because 521 is bigger than 233, you
> > will build a broken package which will not work with any distro running
> > your long-term 2.6.27 which does not have the feature introduced in .233.
> 
> I already addressed this previously in this thread:
> 
> I'm not even sure whether OpenSSL actually does anything with the 
> information: The script comes from the Apache foundation and
> claims to be "Similar to config.guess but much, much smaller."

You addressed it only for openssl and apache 1.3, that you used as
examples to object to a change of changing kernel version numbering
scheme. So do you have other examples of packages like this which
might break and might be more sensible to build environment's kernel
version ? Because if only apache 1.3 and openssl 0.9.8g are sensible,
the fix will be really quick using something like this in your build
scripts and makefiles :

uname() {
   if [ -n "$KERNEL_TARGET" ]; then
      echo $KERNEL_TARGET
   else
      /bin/uname "$@"
   fi
}

And BTW, if your build environment mimmics so well the target except
for uname, let's fix its uname tool to reflect the target version !

quoted text
> > And when
> > you know how to fix packages so that chroot is not a problem, then you
> > know how to fix the package not to require a chroot.
> 
> That's complete bullshit:
> 
> Packages do not require fixes for being built inside a chroot.
> 
> Given:
> - some software package of a foobar program
> - Scratchbox on an x86 host
> - an ARM target that mounts the target filesystem from the host
> 
> host   # ./configure && make && make install
> target # foobar
> 
> The build system of the software thinks it gets built on the target 
> architecture.

Quite cool stuff, but I'm really not interested. Having been beat by
a number of packages which try to run target environment commands
during the build when not set for cross-compile, I'd expect pretty
random results.

quoted text
> And due to transparent usage of qemu or sbrsh it also works when the 
> package uses a program built for the target during the build.
> No matter whether the build system of the package knows anything about
> cross-compilation.

That's the design error you're trying to fix by pushing constraints on
the kernel.

Willy

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/