[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: assumptions about the build environment.



On Fri, Sep 21, 2012 at 09:07:57PM +0100, Ben Hutchings wrote:
> On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> > Some time ago I found that a package (I think it was openjdk but I
> > don't remember for sure) which relied on uname -r such that linux32
> > had to be used to build it in an i386 chroot on an amd64. However
> > since then I'm pretty sure i've seen similar cases with other
> > packages on other architectures being treated as bugs.
>  
> I think confusion between kernel vs userland architecture is so
> widespread that we should consider this a necessary part of doing a
> native build.

Please, don't.  This breaks cross building.  Any use of uname during build
other than for logging purposes is a bug.
 
> (It should preferably be fixed upstream, to benefit users who build
> from either Debian or upstream source on a 32/64 environment.  But I
> don't know a simple way to find the 'primary userland architecture'
> that is not distribution-specific.)

There's more than just 32/64.

Try this: amd64 kernel, i386 host (and compiler), armel chroot, multiarch
with armhf.  What should uname report?

And this is not even an artificial example: you can't really buy a real i386
machine anymore, yet most semi-proprietary (maemo, android) SDKs ship only
i386 binaries, if you want to develop a Debian guest you'd better use armhf
instead of armel, and semi-emulated scratchbox style builds can take 44
seconds compared to 8 hours native[1].

I don't do android so never went 4-way, but played with wine on armhf
earlier this very week... thanks to how wine is set up in wheezy, that's
3-way.  The result of uname wouldn't be too meaningful.

In a multiarch world, you can't speak of "environment" for more than a
single executable[2].

One of portable ways to check your target platform is:
$CC -dumpmachine
(assuming a typical build scheme).



[1]. A not so new amd64 box with make -j6 vs armel -j1, on C++ code that
caused a swappeathon on the latter.

[2]. And even that only because ELF doesn't support fat binaries.

-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623

Attachment: signature.asc
Description: Digital signature


Reply to: