Date: Sun, 12 Jan 2003 05:56:17 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: alane@geeksrus.net Cc: Andy Fawcett <andy@athame.co.uk>, Kris Kennaway <kris@citusc.usc.edu>, Kris Kennaway <kris@obsecurity.org>, kde@FreeBSD.org, alpha@FreeBSD.org Subject: Re: [kde-freebsd] koffice broken on alpha Message-ID: <3E217401.49AEC3E4@mindspring.com> References: <20030104032551.A899@citusc.usc.edu> <200301120315.40618.andy@athame.co.uk> <20030112013223.GA2057@wwweasel.geeksrus.net> <200301121302.22191.andy@athame.co.uk> <20030112134129.GA11765@wwweasel.geeksrus.net>
next in thread | previous in thread | raw e-mail | index | archive | help
AlanE wrote: > On Sun, Jan 12, 2003 at 01:02:22PM +0200, Andy Fawcett wrote: > >Anyway, this would now appear to be academic, since Kris's last mail > >states that the recent KOffice update in ports has screwed any chance > >of updating it and retagging. > > That's my misunderstanding of his wishes. Sorry for hassle it is now > causing. I didn't read it as "don't touch", I read it as what it said, > "no sweeping changes like KDE or Gnome". And I didn't think of the > possible implications of just updating koffice. > > The question is, what do we do now? The problem is intractable. The problem happened in the first place because the table size was inflated by 4 bytes per symbol, when the pointers got large. The real answer is that 4 bytes per symbol isn't that much, compared to the other per-symbol crap that was already there (e.g. decorated names, which will get even longer, if FreeBSD adopts the Microsoft/Linux pig-trick of putting version numbers into the symbol name, which started in Microsoft because you can't have version numbers in DLL names). I believe the last time I looked, the i386 table came in at just over 47K. And KDE is not getting smaller. Eventually, the i386 will be pushed over 64K, as well, and it will quit working, too (a 4 byte version in the symbol name would push i386 over the edge, as well). Another alternative would be to split the "final" objects into several "ld -r"'ed objects, instead of one big one, and that will also push the table size below 64K again (at least until the KDE developers bloat it back up there with more cruft). Any approach based on anything other than removing the 64K limit entirely, or not being on an exponential curve to bump your head on it, ever, is probably a correct approach (compared to, say, hacking all sorts of special cases into the Makefiles, and making them more and more architecture dependent, even if the OS never changes. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E217401.49AEC3E4>