stdcxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Winn" <geoff.w...@googlemail.com>
Subject Re: Problem building Tuscany SDO with stdcxx on Linux
Date Tue, 17 Oct 2006 13:24:14 GMT
I've tried adding -H to the compiler options, which lists all the header
files as they are loaded. It's quite a long list. I was wondering if I might
be able to spot something that wasn't right but there's nothing obvious to
me except possibly a number of cases where the same base filename is loaded
from multiple locations, eg stdio.h is loaded from both
/home/tuscany/workspace/stdcxx/stdcxx-4.1.3/include/ansi and /usr/include
and there are others like this. Could that be a problem? I can post the
whole list if that's any help.

Thanks and regards

Geoff.

On 16/10/06, Martin Sebor <sebor@roguewave.com> wrote:
>
> Geoffrey Winn wrote:
>
> > I don't think so. I'm assuming you mean sdotest.h It looks like this
> >
> > class sdotest {
> >    public:
> >
> >        static bool silent;
> >        static bool ramping;
> >
> >        static int  printseq(FILE *f, SequencePtr sptr);
> >
> > and then a long list of different static int methods that are test
> shots.
> >
> > This code works fine on XP using stdcxx.
> >
> > By the way, I'm not expecting you to debug this for me :-) I was just
> > checking in case this has come up before.
>
> It suggests some kind of memory corruption. A possible cause
> is colliding with another implementation of iostreams. Check
> (using ldd) to make sure you're not linking with libstdc++.
>
> >
> > One thought has just occured to me - but I need to check. It could be
> that
> > all the failing uses of stdcxx are all in the test program rather than
> in
> > the Tuscany SDO library itself - in which case the most likely
> explanation
> > is that I'm still not building the test program correctly. I'll check
> that
> > before I take up any more bandwidth.
>
> No worries. What does the link line of the executable look like?
>
> Btw, I'm at a conference this week and on vacation the next so
> I might be slow to respond.
>
> Martin
>
> >
> > Thanks again
> >
> > Geoff.
> >
> > On 16/10/06, Martin Sebor <sebor@roguewave.com> wrote:
> >
> >>
> >>
> >>
> >> What happens in this header? Are there any global objects being
> >> constructed that might be manipulating cout or its streambuf
> >> object?
> >>
> >> Martin
> >>
> >> >
> >> > extern "C"{
> >> >
> >> > #define TEST(testname)\
> >> >    value = testname;\
> >> >    if (value == 0) {\
> >> >        cout << "Test Failed: " << totaltests  << " "
<< #testname <<
> >> endl;\
> >> >    }\
> >> >    testspassed += value;\
> >> >    totaltests++;
> >> >
> >> > int main (int argc, char** argv)
> >> > {
> >> >    cout << "Starting SDO tests ...";      <=== Fails here.
> >> >
> >> > The thing that puzzles me is that this is fairly unremarkable code
> >> compared
> >> > to all the other stuff that's workin OK.
> >> >
> >> > Regards,
> >> >
> >> > Geoff.
> >> >
> >> > On 12/10/06, Liviu Nicoara < nicoara@roguewave.com> wrote:
> >> >
> >> >>
> >> >> Martin Sebor wrote:
> >> >> > Geoffrey Winn wrote:
> >> >> >> Is the reference to __cxa_pure_virtual familiar to anyone?
> >> >> > (When using g++, the runtime is included in libstdc++).
> >> >>
> >> >> I stand corrected :-), g++ does not link libsupc++ anymore - these
> >> >> symbols are indeed in libstdc++. I do remember a time when
> downstream
> >> >> products on top of our stdlib were linking libsupc++ explicitly.
> >> >>
> >> >> Liviu
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message