This is the mail archive of the libstdc++@sources.redhat.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: libstdc++v3 portability problems


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]