Raphael Hertzog wrote: > On Sun, 09 Dec 2007, Neil Williams wrote: >> Emdebian cannot build, patch or test every permutation of toolchain that >> people need so this isn't about "us" patching locally, it is about >> lowering the barrier to cross building on Debian by not forcing every >> user to patch locally. This is why we are at the current impasse - too >> many permutations. > > Emdebian provides ready to use cross compiler. You can also provides > ready-to-use source packages for building other cross-compilers that are > not yet provided.
? You make it sound as trivial as providing a web page.
Emdebian provides a small selection of binary toolchains containing
selected cross compilers. Extending that range is a truly massive
undertaking that nobody has the time to do. There are no usable
toolchain-source packages anymore - unmaintainable - we can provide
simple scripts that can assist in building a variant toolchain but we do
not provide ready-to-use source packages for building cross compilers.
The major reason why this is so much work is because the necessary
changes have not been incorporated into dpkg and we end up having to
patch a patch of a diversion of a patch.
Emdebian has quite a good relationship with the gcc maintainers and our
patches are generally welcome but that does not diminish the amount of
time involved in making a tested patch in the first place. Emdebian only
has enough developer time to derive patches for the latest versions of
gcc and even then it can be difficult to keep up with gcc releases. We
look forward to the stability of the pre-Lenny freeze because we know
that we can catch up and get a stable set of toolchains for unstable and
testing, all thoroughly tested and fixed. Then as soon as Lenny comes
out, we'll be swamped by gcc changes again. (We, in this case, equals
Hector Oron, myself and Wookey - gcc has a much larger team just for
itself.)
>> Why propose changing every version of gcc (a process that could take
>> extreme amounts of time to test, implement and get into testing) and
>> then make it impossible to build cross compilers in Etch? Are we looking
>> at backports as well?? Who is going to do all that work? (Not me, before
>> anyone asks.)
>
> ARCH is a very generic environment variable that might be set for some
> other reasons (I use it for example in debian-cd) and I don't like to
> change the behaviour of dpkg-shlibdeps just because it's set. IMO,
> there should be a single check to activate cross-building support
cross building != building a cross compiler, as I've said many times.
A single check for cross building is already in place -
DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE
I created a patch for that in gcc for reverse cross support, it is
included in gcc-4.2.
A mass bug filing is already under way to implement this single check
for cross building support across Debian. The patch to dpkg-shlibdeps
contains a part of that support.
Cross building gcc is NOT the problem. gcc now cross builds just like
any other package in Debian. If reverse cross support in Debian goes
wrong, I'll fix it. I've no problem with that.
Building a cross compiler is a completely separate task and one that has
only become a problem *after* changes in dpkg made the dpkg-cross
diversions impractical.
> and gcc's crossbuild should provide the right variables.
It does, thanks to the reverse cross support in gcc-4.2. Thankfully, we
don't need reverse cross support in 4.1 or earlier. (Well, it would be
nice if it could happen but then nobody has the time to do it so ...)
> I'm ok with a
> supplementary specific check for building of a cross-compiler, but not
> with a generic check like testing the ARCH environment variable.
OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
I've tested with this change to the patch for scripts/Dpkg/Shlibs.pm
# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
...
I went for ARCH before because, in the context of building a cross
compiler, ARCH is only set at certain times. GCC_TARGET is set at the
beginning and is present throughout the build. This means that the
patched dpkg-shlibdeps behaves much more like the original diversion
from dpkg-cross - it effectively extends the list of directories
searched by dpkg-shlibdeps to include the ${crossprefix} ones for every
call throughout the entire build. It may slow things down a little bit
but building a cross compiler isn't exactly quick anyway. It is far more
important that the build completes than shaving a few more seconds off
the build time.
> Furthermore, all the cross-building support in gcc has been contributed
> by various Emdebian people (according to doko), so it looks like Emdebian
> is also able to fix gcc in that regard if needed.
Those fixes (or hacks) were implemented piecemeal over many years and
the cross building support in Emdebian has recently been rewritten so
some of those hacks (i.e. the dpkg-cross diversions) have to be removed.
I don't like the hacks any more than you do, that's why I'm still
pursuing this bug.
As I've mentioned above, Emdebian is not usually able to fix gcc in
anything other than the latest version due to lack of developer time.
>> Now that we finally have a chance to fix dpkg-shlibdeps, why must all
>> the previous work be undone? For the sake of one environment variable?
>
> Please stop dramatizing the situation, we're not undoing your work. We're
> adding proper support for cross-building by trying to do the right thing
> instead of integrating crude hacks to match other crude hacks on the gcc
> side.
>
> Until you convince me that there's a good reason on the gcc side to not
> have a consistent set of variables set, my opinion won't change just
> because you repeat the same non-arguments.
? So the simple fact that changing all versions of gcc is simply too
much work is not relevant ?
Anyway, I hope you are now happy to use the "supplementary specific
check for building of a cross-compiler" that I have described above, in
addition to the checks from the original patch for normal cross building
support, including checking DEB_TARGET_GNU_TYPE so that future versions
of gcc can migrate away from GCC_TARGET, possibly.
The final version is:
(email line wrapping notwithstanding)
use constant DEFAULT_LIBRARY_PATH =>
qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
/emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
my @shlibdeps=();
# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
# host for normal cross builds.
$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne
$ENV{DEB_BUILD_GNU_TYPE}));
# target when building a cross compiler
$crossprefix = $ENV{DEB_TARGET_GNU_TYPE}
if (($ENV{DEB_TARGET_GNU_TYPE}) and ($ENV{DEB_TARGET_GNU_TYPE} ne
$ENV{DEB_BUILD_GNU_TYPE}));
if ($crossprefix)
{
@shlibdeps = ( "${crossprefix}/lib", "/usr/${crossprefix}/lib",
"/${crossprefix}/lib32", "/usr/${crossprefix}/lib32",
"/${crossprefix}/lib64", "/usr/${crossprefix}/lib64");
}
our @librarypaths = ((DEFAULT_LIBRARY_PATH), @shlibdeps);
>> them - changing every gcc package is simply not workable IMHO and the
>
> You make it sound like it would require horribly complicated patches on
> the gcc side but we're speaking of setting a few environment variables
> only. IMO it's perfectly workable.
Are you proposing to do the work?
I fear it is not as simple as you imagine - the patches would be
complicated because of the permutations that would need testing and the
amount of time involved. This is a dpkg problem and it needs a dpkg
solution, IMHO.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
