[uClibc] gcc-3.3.2 building problem

[Manuel Novoa III]

Hello,

On Sun, Jan 25, 2004 at 09:26:04AM +0100, Peter S. Mazinger wrote:
> On Sun, 25 Jan 2004, Manuel Novoa III wrote:
> > If you want to experiment, feel free.  But until there's been some
> > discussion on the list about what config.guess should report, I'm
> > not going to waste any time hacking up buildroot when I have actual
> > uClibc devel stuff to do.  Buildroot has already sucked up too much
> > of my time the last few weeks.
> 
> Can't give you time back, but trying to help out, here's a patch for 
> binutils-2.14.90.0.8 (if you will update)

I'm not asking for my time back.  :-)  The stuff needed to be done.
And I do understand you are trying to help out.  I appreciate that.
All that I was trying to say is that you are working on step n+k
while at the moment I need to be working on step n.  So please
continue to look at things and post patches, etc.  But also don't be
offended if I don't seem to be giving them the attention they are due
until I actually get to step n+k myself.

I'm hoping that by sometime in March I should finish the next round
of l10n/i18n support work.  At that point, I'll personally be looking
towards working exclusively in a uClibc-based environment since the
abi should be pretty stable by then.  That move is something I've
spent much of the last 3 years working towards, and I'm probably more
anxious to get there than you are.

While I can probably look at your binutils patch later this week,
the whole purpose of doing all the <arch>-linux-uclibc changes was
to move away from the old 'hack-the-source' approach and towards
something that might be acceptable upstream.  So chasing the current
stable release isn't the best use of time in the long run.

I'd really like to coordinate with some of the uClinux folks and get
at least the binutils stuff and the configuration-related gcc stuff
moving upstream.  The gcc libstdc++ uclibc support code is in a
seperate patch precisely because it isn't finished.  When it is, then
it too can be pushed upstream.  But if the configuration stuff is
in place, then it is a simple matter to just supply the uClibc-specific
config/os and config/locale subdirs in the meantime since they are
completely independent.

The config.guess stuff is a related issue.  I'd like to hear pros
and cons for including some uClibc configuration info in the tuple
name itself.  And, as I've mentioned to Rob, if we do decide to
include info in the tuple name then I would prefer that we control
the exported info via some define in uClibc_config.h rather than
encoding checks in the config.guess script.  That way, we avoid
having to again change things upstream if we decide to make internal
changes.

Manuel