Re: [m68k] Restore some original predefines and cleanup m68k targetflags

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Sat, 20 Sep 2003, Bernardo Innocenti wrote:
> Hans-Peter Nilsson wrote:
> >>Well, the biggest problem with my boards with just 4MB of RAM
> >>would be its size.
> > Yeah.  For the record, glibc is 800kiB uncompressed,
> Not even close to uClibc with some options turned off:
 [92k]

Heh, I certainly didn't mean to display some wonderful
minimalistic property of glibc! :-)  Those were ballpark figures
to help people who don't know, to see the difference.

> > Right those are "a few lines of patches", but those aren't the
> > "finer points" I referred to.  Those are the cruder points. :-)
> >
> > I was referring more to exception handling and dynamic linking
> > (and loading) than build problems due to glibc-centricness in
> > libstdc++

> The whole exception handling machinery is in libgcc, not glibc
> or uClibc. To get it to work, you just need a way to do global
> constructors and destructors for __register_frame_info() to do
> its job.

Sigh, that's "basic functionality", not "finer points".  There
was a thread some months ago related to cancellation points for
OS calls, for example (IIRC) when using C++ and threads.  Not a
priority though, I'd guess.

> > Besides, you're still referring only to gcc when discussing the
> > proper GNU triplet.  GCC is only one of many packages using GNU
> > triplets.
>
> Ok, but GCC is the only piece of the toolchain that needs to know
> whether it's target is uClinux/uClibc or not. as, ld and gdb
> don't care at all.

There are other packages *outside the toolchain* too.  At
least so I've heard. :-)

> To avoid patching all of them, I'm still building with the
> m68k-elf target and using symlinks to let gcc find them.
> I'm looking for a better solution, but so far I have no choice.

Avoid patching them?  Sending in patches to get support for your
target is part of the porting effort.  Hopefully there's not
much work besides the config.sub (and config.guess if you can
self-host, but I guess that's not likely), and projects can
be expected to import them on a semi-regular basis.

> >>Actually, I need more tweaks in libstdc++ to disable all that
> >>crap that would make my statically built binaries too big for
> >>my tiny system.
> >
> > Dynamic linking would relieve some of the pain.
> > Mostly works with uclibc, AFAIK. :-)
>
> It does work fine on MMU systems. It's possible, but very
> kludgy, when you don't have an MMU and you still want to
> preserve POSIX semantics for dynamic libraries. Then you
> need to have multiple GOTs for the program and the libraries
> it uses.

Yeah, my answer was a bit CPU-*-linux-uclibc -centric. :-)
Sorry, I guess I upset those MMU-challenged.  Still, you can
certainly cook up a shlib solution for a no-mmu system.
It seems it's a been-there-done-that item.

> And I'll keep the URL of this thread around so I can show it to anyone
> complaining for the target name :-)

That's what we're here for!

brgds, H-P