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

Bug#710240: stage1 gcc depends on libgcc-*-dev and gcc-VERSION-base



Am 30.05.2013 02:06, schrieb YunQiang Su:
> On Thu, May 30, 2013 at 12:05 AM, Matthias Klose <doko@debian.org> wrote:
>> Am 29.05.2013 11:50, schrieb YunQiang Su:
>>> Package: gcc-4.8
>>>
>>> When build gcc-4.8 using
>>> WITH_SYSROOT=/ DEB_STAGE=stage1 debuild -B -d
>>>
>>> the generated gcc-4.8-TRIPLE package depends on gcc-4.8-base
>>> and libgcc-4.8-dev-ARCH-cross, while both of these 2 packages are
>>> missing here.
>>>
>>> The attached patch disable it depends on these 2 packages if they are not
>>> generated here.
>>
>> why is this necessary? These package should never be installed, just used for
>> the bootstrap. This is how Marcin did use it:
> yeah, bootstrap is the most important use case of this, while we can
> still have other
> cases to use this, such as it can be used to build kernel or something
> else no depends
> on libc or any other system libraries.
> Since here we can get it have correct dependency, and without breaking
> the host system,
> why not do it correctly?
>> https://launchpad.net/ubuntu/+source/arm64-cross-toolchain-base/0.6
> This is a great package. I noticed it before.
> While I plan to bootstrap with another way: write a script to it step
> by step instead of
> put them in a single package.

maybe the name of the arm64-cross-toolchain-base package is wrong. It now only
builds the kernel headers and the glibc packages.

> Maybe by it, I can get more automation.
> 
> 1. build dpkg with architecture support patch.

Not sure what that does mean.

> 2. build cross binutils

the binutils cross build is independent.

> 3. build stage1 gcc
> 4. build linux kernel (to get linux-libc-dev and workable linux-image)
> 5. build eglibc (maybe by clang? which may be easier to get multilib support)

yes, this is simpler, and that is how it should be done in the current
arm64-cross-toolchain-base package.

no, clang is not an option, just adds another dependency needed for the
bootstrap, and not available on half of the architectures.

> With help of a private repository, this script maybe can work automatic.

the goal should be to provide these packages as normal package builds.


Reply to: