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

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

(Trimmed CC list)
On Sat, 20 Sep 2003, Bernardo Innocenti wrote:
> Hans-Peter Nilsson wrote:
> >>I would agree with you on using uclinux in place of linux, but
> >>then would I really need to append -uclibc to it?
> > I can imagine other libraries being used with uclinux than
> > uclibc.  There was even an attempt to use glibc, but there
> > were... problems.
> Well, the biggest problem with my boards with just 4MB of RAM
> would be its size.

Yeah.  For the record, glibc is 800kiB uncompressed, 400kiB
compressed (cramfs) on the systems I know.  (But that's on
cris-axis-linux-gnu, not uclinux so it's apples and oranges.)

> > With a proper configuration you wouldn't need "a few lines of
> > fixes", right?  Either way, uclibc is still not glibc and I
> > doubt it has yet implemented the finer points of C++ and thread
> > support.  Don't be blinded by whatever gcc uses and matches
> > configure-wise.
>
> You'll be surprised to see this:
>
> http://www.uclibc.org/cgi-bin/cvsweb/toolchain/gcc-3.3.1/sources/gcc-810-libstd%2B%2B-locale.patch?rev=HEAD&content-type=text/vnd.viewcvs-markup

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++ -- which should of course be fixed anyway; some of
that patch should make it to libstdc++-patches@ and the rest
should be fixed to use feature tests (HAVE_*) macros before
sending it in.  To wit, when an uclibc-based system passes
check-c++ with no less errors than the corresponding glibc-based
system, I'll change my mind.  And don't forget to link
dynamically.

Besides, you're still referring only to gcc when discussing the
proper GNU triplet.  GCC is only one of many packages using GNU
triplets.

> 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. :-)

> So, what shall I use, m68k-uclinux or m68k-uclinux-uclibc?

You asked, so I'll answer again: m68k-uclinux-uclibc, so you'll
not be as uclibc-centric for -uclinux as glibc is for -linux.
Tweaking configury (not only just in gcc) will hopefully not be
opposed by the obvious intriguing questions like "but why are
you setting HAVE_XX in libstdc++-v3/crossconfig.m4 based on the
OS name?  That's a library feature".

brgds, H-P