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

Re: Bug#447427: dpkg-cross: please support wrong architecture

On 10/22/07, Ron <ron@debian.org> wrote:
> On Mon, Oct 22, 2007 at 01:21:26PM +0200, Jonas Meyer wrote:
> > No. I want to beable to forcibly cross install mipsel libc packages as
> > uclibc packages to build the cross-compiler.
> Oh.  Well that seems like a totally different brand of horrible and
> wrong to just supporting uclibc-mipsel and that requiring a bit of
> hand-hacking to the dpkg tables.

the changes to the dpkg tables support all already existing debian
arches in their uclibc- variants
> I have a hard time thinking of how that could possibly work unless
> you end up with a system that depends on _both_ glibc and uclibc,
> and that kind of defeats the point of using uclibc...
once I have built gcc I remove those wrong packages again, of course.
then I have everything to continue proper bootstrapping of the

> > From gccs README.cross:
> > -1.3. libc for target
> >
> > -You also need libc library and development packages for the target
> > -architecture installed.
> For uclibc this means you need uclibc.

Yes. It's a chicken and egg problem. And until it is possble to build
a libc-less cross-compiler this is a pretty conveniant way to get that
> > I'd prefer if there was proper support for bootstrapping
> There is.  See how the SLIND uclibc package creates a bootstrap uclibc
> that can be used for this.  A post I made to this list in June might
> help too, it describes the minimal things I needed to do to bootstrap
> a uclibc toolchain entirely from source.

I'll have a look. But I kind of insiston being able to build the whole
toolchain using only what I can get from sid (+uclibc)
> > but this seems to be a pretty good way around that problem to me.
> mixing libc versions seems like a pretty good way to _make_ problems
> for yourself to me.  glibc and uclibc are not binary compatible
> replacements for one another, so if the tools are barking at you
> when you try to do that I can only consider that to be a good thing,
> and not a bug that we ought to 'fix' by making that warning go away.
I never expected it to disappear completely. but some --force option
wouldn't hurt, would it?

> We do need to fix the extra dpkg-arch thing, but the fix for what you
> describe here is that you need a bootstrap uclibc package, the glibc
> one is not a replacement for that.
as far as I can tell I need a bootstrap gcc package. how can I
possibly build the uclibc without a compiler?
> hth!
> Ron

Reply to: