[m68k] Restore some original predefines and cleanup m68k target flags

[Bernardo Innocenti]

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. uClibc has also become annoyingly big
nowadays... 0.9.21 introduced a lot of fine grained options
to make it smaller again, such as kicking out 15KB worth
of strerror() messages.


>>uclibc is compatible enough with glibc to share the libstdc++
>>config/os/gnu-linux subdirectory with just a few lines of
>>fixes.
> 
> 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

Of course to get it working you must enable C locale,
wchar/mbchar stuff, posix threads...

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.

The problem with libstdc++ is that nobody is testing it on
systems configured with some advanced glibc features disabled.
I bet many ARM based systems using glibc would need that.

So, what shall I use, m68k-uclinux or m68k-uclinux-uclibc?
I still prefer the former. Since it's mostly a matter of
taste, I could also make it work both ways :-)

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html