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

Re: cross compiler deb package question



Arnd Bergmann <arnd@bergmann-dalldorf.de> writes:

> On Wednesday 22 January 2003 21:18, Daniel Schepler wrote:
> 
> > I was actually starting some work on this, too.  I've gotten as far as
> > getting the kernel to boot in Bochs and run a statically linked
> > version of dash.  I was planning to start more work on it tonight: set
> > aside a large amount of disk space for the Bochs disk image, cross
> > compile coreutils, binutils, gcc, etc.
> Cool. Can you post the .config you used for your kernel? 

Ok, I'm sending this in private mail.  For reference, I needed to cut
down config options to a bare minimum so the kernel was small enough
to boot from (simulated) floppy, and use a version of Bochs from CVS
which includes a cpuid fix.

> > BTW, I found that the gcc build gave me endless problems unless I
> > passed --disable-multilib to configure.  Also, it wants to link
> > libgcc_s.so against -lc, while glibc wants to link against libgcc.a,
> > so you won't be able to compile either all the way through the first
> > time.
> I solved this by installing the glibc rpm package from ftp.suse.com
> and bootstrapping gcc from there. The gcc and glibc packages on my
> page are now independent from that and only need each other (and
> biarch binutils). I had to make some changes to gcc files to allow
> making 32 bit output the default. Appearantly all the others so
> far have gcc installed as a native x86_64 compiler with an extra
> 32 bit mode.
> 
> > > Now, my question is: should it be installed in prefix=/usr or /opt or
> > > /usr/local.  I understand that the debian-way (TM) is to instal in /usr,
> > > but this is a less then usual package, no?
> > >
> > > Moreover, what should I call the package?  x86-64-gcc-3.2.i386.deb?
> >
> > How about gcc-x86-64 instead?  Iirc at one point there were
> > binutils-m68k packages, and there's currently binutils-multiarch
> > (though I don't think that includes x86-64 support atm).
> On s390 and sparc, there is only one compiler for both, which makes
> perfect sense to me (I mostly copied the changes from s390, which
> copied them from sparc).

I was talking about the cross compiler from ia32 to x86-64.  I agree
it would be best to make x86-64 native gcc be able to compile in -m64
or -m32 mode, since it's so inexpensive anyway.

> The more important question imho is how to package libraries.
> So far we have three different schemes (and more are possible):
> 
> - libgcc and libstdc++ have both 32 bit and 64 bit libraries in
>   one .deb,
> - libc6 has extra libc6-x86-64 and libc6-dev-x86-64 packages, which
>   contain only 64 bit parts, while the 32 bit packages also contain
>   files that are always needed (=> libc6-x86-64 depends on libc6)
> - libncurses has packages for both 64 and 32 bit and another one
>   for the common files (=>libncurses5 and libncurses5-64 both
>   depend on ncurses-base, but not on each other)

I think for x86-64 the default should be 64 bit libraries, with others
having versions libc6-32 or maybe libc6-i386, and so on.  I'm curious,
though, why sparc uses 32 bit libraries as the default -- is the
reason for it something specific to sparc systems, or would it apply
to x86-64 too?  Or is this something which the upstream x86-64
developers have an explicit opinion on?

Anyway, all this would be for later, once I've gotten the system
nicely bootstrapped.  For now I'm just going to keep on using
--disable-multilib so I don't have to worry about the 32 bit versions
until later.
-- 
Daniel Schepler              "Please don't disillusion me.  I
schepler@math.berkeley.edu    haven't had breakfast yet."
                                 -- Orson Scott Card



Reply to: