On Thu, 24 May 2001, Kevin D. Kissell wrote: > > First, we are talking about glibc and not the entire userland. > > But since essentially the entire userland is linked with glibc, > I'm not sure how much that distinction matters, in practical > terms. Do you link statically? If not, then almost no code from glibc is incorporated into your binaries, with an unimportant exception of a few functions from libc_nonshared. > I'm simply saying that if one just does "./configure" > and "make" for glibc with a mips target, it should default > to use ll/sc, and that if one simply builds RPMs for binary > distribution of MIPS/Linux binaries, they should be linked > with a glibc that uses ll/sc. And that therefore the MIPS/Linux > kernel for R3000's (and R4100's) should have ll/sc emulation > support built in by default. Then you need to change your gcc configuration so that it assumes "-mips2" (or whatever level you want to) by default. That's typically done in the gcc's specs file. Nothing about glibc here. For RPM you might put "-mips2" into optflags in its rc file. > > Second, do you expect everyone compiling the entire userland from > > sources? I don't. The normal approach is to take a distribution and > > build only these pieces which are not satisfying for one reason or > > another. Just take an ISA I, ISA II or whatever version you need. > > >From where? I'd love to find a decently complete (with compilers, > networking tools, X, etc.) mipsel distribution of any MIPS ISA level > less that MIPS V to replace the antique crud that runs on my mipsel > platform. That's a real problem, but there is Debian available for MIPS -- is it missing anything? The main problem was to get glibc 2.2 right. Since it was done, building other programs should be easy. Then building other variants is just a matter of disk space and CPU time. > > Fourth, maintaining differently optimized distributions is not that > > troublesome. > > Please don't get me wrong here, because I tremendously > respect the work that you've been doing for MIPS/Linux, > but how many differently optimised distributions do you > presonally build, distribute, support, and maintain? I understand maintaining a distribution is serious task, but with appropriate tools maintaining two or more distributions with a common source set is not much harder than a single one. For example, using the source set as available at my FTP site, building differently optimized binaries is as easy as running a script looking more or less as follows: for rc in .rpmrc-mipsel .rpmrc-mipsel-II .rpmrc-mipsel-III .rpmrc-mipsel-IV; do for name in *.src.rpm; do rpm --rcfile=$rc --rebuild $name done done with different optflags set in .rpmrc-mipsel* files. It's boring and disk-consuming but easy and automatic. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
