This is the mail archive of the
mailing list for the libstdc++ project.
Re: libstdc++v3 portability problems
- To: gcc at gcc dot gnu dot org, libstdc++ at sources dot redhat dot com
- Subject: Re: libstdc++v3 portability problems
- From: Robert Lipe <robertl at sco dot com>
- Date: Sat, 9 Dec 2000 14:43:18 -0600
- References: <20001208112705.A18615@rjlhome.sco.com> <20001208150204.A14385@disaster.jaj.com>
Phil Edwards wrote:
> [As a side note, please cc any future libstdc++-v3 issues to the libstdc++-v3
> list. It's easy for things to get swamped in the gcc list.]
> On Fri, Dec 08, 2000 at 11:27:05AM -0600, Robert Lipe wrote:
> > 1) Calls to 'ar rc' with no files to add. GNU ar supports this.
> > Phil delivered a patch, but others were unhappy with it so it never
> Phil needed to review the Automake manual again. :-) An updated patch
> is below. (It's the same thing, almost, but incorporates Alexandre's "keep
Thanx. That seems to do it for me.
> > 2) 'make check' in the libstdc++v3 build diredtory calls scripts that
> > have implicit dependencies on bash. Nested shell functions are
> > a bash extension and not available on POSIX shells.
> Anyhow, Gaby is converting the whole mess to work with dejagnu.
Lovely. That should reduce the pain. (Or at least trade it for a known
form of pain. :-)
> > 3) Toplevel 'make check' now doesn't work on multilibbed targets.
> Hmmm. I don't about this one, sorry. (I thought recent Solaris was supposed
> to also be multilibbed, but the sparcv9 stuff doesn't seem to be active now.)
Once the treee builds again, I'll take this one back up. I observed
this on the lone (sigh) day that it successfully built for me.
> > I'll keep the podium for one more minute.) The builds are
> > getting _really_ obscure throgh the use of libtool/automake magic.
> On the plus side -- and this is a big plus -- if we do our job correctly,
> a whole bunch of stuff will just /work/ for the end user. Speaking as an
> end user, I'm all for that. :-)
Agreed. That should always be our goal as developers. When we succeed,
it's great. But I have a suspicion that debugging this stuff in the
field is going to be a patience-trying experience. We could have
targets now that must have libtool ported to them before the tree will
bootstrap. Perhaps that's a necessary cost on the road of progress.
Thanx for the response.