On Fri, Nov 14, 2003 at 05:58:52AM +1100, Simon Burge wrote:
> On Thu, Nov 13, 2003 at 01:45:33PM -0500, Rafal Boni wrote:
> > In message <20031113134236.C1838@snowdrop.l8s.co.uk>, you write: 
> > 
> > -> I've modified crunchgen so that it no longer needs to parse each program's
> > -> Makefile to find the list of objects to build.  Instead it relies on the
> > -> program's Makefile having a ${PROG}.ro: ld -r ${OBJS} ${.TARGET} rule.
> 
> I'm not sure I understand this - does each program's normal Makefile
> that is part of a ramdisk (or any other crunchgen'd program) need to
> have an entry like you mention above (${PROG}.ro)?

It is in bsd.prog.mk just below the one that generates ${PROG}.
So none of the usual netbsd makefiles need to be changed.

> > -> Also changed:
> > -> - Delete code for RENAME_SYMS - all getting too hard!
> > 
> > Hmm, I think this was necessary for MIPS with 2.95.3 and the 2.95.3-era
> > binutils, otherwise we'd overflow the GOT building large crunched binaries
> > (this is why the 1.6-branch MIPS installers don't have dhcp support; linking
> > in dhclient tipped the crunched binary used by the installer over the edge).
> > 
> > I haven't looked at the state of all this after the integraton of the new
> > gcc & binutils, but you should probably verify that it won't kill MIPS ports
> > before ripping it out (making sure rescue builds is a start; I think it 
> > didn't on MIPS platforms before Simon added the renaming code).
> 
> Same as Rafal, I haven't looked to see if we still require the
> rename-syms hack with new gcc/bintuils.  I'll be a bit unhappy
> if you manage to break all the MIPS ports that have a ramdisk :-)

I've actually removed the code for not RENAME_SYMS - the source had a hard
#define RENAME_SYMS, so it wasn't a build option.
I thought there was a problem with different types of fixups for local
and global symbols, so changing a symbol to local was non-trivial.

I don't actually fancy cross building ALL the mips ports!
I haven't got that much disk space - might do some of one though,

	David

-- 
David Laight: david@l8s.co.uk