RE: progress towards mipsel glibc-2.3.5

["Jake C. Page" <jcpage at 2wire dot com>]

> If that ends up being the thing to do,
> we probably want to check whether $(CC) supports that flag.
> It might not have mipsel in the name... maybe checking
> the output of $(CC) -v would be best.

I wouldn't even consider recommending anyone else do this... :)  mostly posted it just to get the thread started...
Truthfully, I think the cleanest solution would be to add a much needed "--bootstrap" option or something like that to the glibc configure script, so that it does not make any assumptions on the gcc used (basically, changes have been made to MIPS around 2.3.3 that really do assume the gcc used is always for the target arch...) 
 
Barring that, I think an equivalent "automatic" check in configure along the lines of what you mentioned would work, too..  

> > * glibc-headers won't compile due to the fact that several places are
> > checking for gcc-defined macros _MIPS_SIM and _MIPS_SZPTR.
> > I defined CFLAGS="-D_MIPS_SIM=_ABIO32 -D_MIPS_SZPTR=32" in the configure
> > to get around this.
> > I also had to add $(CFLAGS) after the $(CC) at Makerules:1285 so they
> > could be picked up.  I TOLD you these hacks were ugly :)
> 
> Bleah!  :-)    There's clearly a better way, but I don't
> have it handy.

Yeah, this one is harder, since it is basically depending on the builtin macros of a compiler that doesn't exist yet.  Ugh.
Again, the fix is probably a (fairly painful) addition to configure that sets them if it determines that it is in "bootstrap" mode and figures out which specific ABI to build for.  The only other way I see would be to change the way the _MIPS_* macros are used, but those changes seemed to be a fairly determined redesign of glibc MIPS ABI handling that I don't really want to get into (who compiles MIPS natively any more these days anyway!?  Guess there still a few old SGIs hanging around out there.. :) 

> This is enough to build glibc-headers.  I also removed the steps to make
> sysdeps/gnu/errlist.c & touch errlist-compat.c, they weren't necessary
> anymore...

Really?  I'll have to check into that.  Maybe they get built
by the earlier commands now (which may be why any of the above
hacks were needed).

> > A couple more issues when building full glibc:
> >
> > * gcc was compiled with --disable-shared, and glibc-2.3.5's Makeconfig
> > tries to link with -lgcc_eh, which does not exist on a non-shared gcc
> > build (doesn't work to try --enable-shared, don't bother...).  I had to
> > comment Makeconfig lines 506 and 511 to remove the reference to
> > libgcc_eh (there was some attempt in this file to workaround the fact
> > that it could be missing, but it fails since the check in configure
> > tries to link with libgcc_s.so during the process (DOH!)
> 
> I think the way to address this is to apply
> patches/glibc-2.3.4/make-install-lib-all.patch
> Then the lgcc_eh problems go away (assuming you
> have a recent crosstools).

Sounds good, I'll try that out...

> With those changes glibc compiles & installs.
>
> > However, I have NOT tested it at all yet.   When building gcc-full I get
> > a compile error (it builds the C & C++ compilers, but fails on Java.
> > Looks like the glibc syscall.h header file was generated incorrectly by
> > the glibc build... something is still wrong...
> 
> Just checking: do you really need Java?  If not, you could
> configure that out of gcc...

Actually, I do... but even if not, it would have been a broken toolchain - I found the bits/syscall.h file was more or less empty.  However, applying the following patch fixed that problem, and now full gcc builds fine:
 
http://ftp.jg555.com/patches/raq2/glibc/glibc-2.3.4-mips_syscall-2.patch
 
 
Now it's time to see of the toolchain actually WORKS...
 

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com