libstdc++v3 portability problems
Robert Lipe
robertl@sco.com
Sat Dec 9 12:40:00 GMT 2000
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.]
Deal.
> 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.
RJL
More information about the Gcc
mailing list