Problem porting QuickFix

QNX DEVELOPERS Porting
1

I’m attempting to port the open source QuickFix engine from http://www.quickfixengine.com to QNX 6.3.0 and am struggling. Admittedly as a LONG time C programmer (I’ve been writing C longer than some of my coworkers have been alive!), C++ is a bit of a foreign to me – I know just enough to be dangerous – and that might be the problem. However to my naive eye it looks like there are incompatibilities in the QNX C++ headers.

As directed, I downloaded and made and installed lib-xml2 first. That went without problem.

Then I downloaded the Linux QuickFix hoping that would compile. My first attempt at had the configure script creating makefiles that called g++ which seemed to be a problem, so I did a ‘make clean’ then reran configure as:

./configure CC=qcc CXX=QCC

That worked a little better, but eventually very standard things that the code (and I) expected to be in the headers were missing.

Can anyone suggest what I might be doing wrong? Or what additional info do you need before you can give me guidance.

P.S. Yes, I’m THAT Bill Flowers! Rumors of my death or abandonment of QNX are premature. :smiley:

2

Try using QCC -Vgcc_ntox86_gpp - that will use the GNU C++ libs/headers, rather than the Dinkum C++ lib/headers that we ship.

Cheers,

Colin

3

Thanks Colin. I appreciate the quick response. I’ll give this a try tonight.

4

No joy. It was looking good for a while but then I got this error:

DataDictionaryTestCase.cpp: In method bool FIX::DataDictionaryTestCase::readFromStream::onSetup(FIX::DataDictionary *&)': DataDictionaryTestCase.cpp:587: no matching function for call to fstream::fstream (const char[18])’
/usr/qnx630/target/qnx6/usr/include/g+±3/fstream.h:83: candidates are: fstream::fstream()
/usr/qnx630/target/qnx6/usr/include/g+±3/fstream.h:84: fstream::fstream(int)
/usr/qnx630/target/qnx6/usr/include/g+±3/fstream.h:86: fstream::fstream(const char *, int, int = 436)
/usr/qnx630/target/qnx6/usr/include/g+±3/fstream.h:87: fstream::fstream(int, char *, int)
/usr/qnx630/target/qnx6/usr/include/g+±3/fstream.h:90: fstream::fstream(const fstream &)
cc: /usr/qnx630/host/qnx6/x86//usr/lib/gcc-lib/ntox86/2.95.3/cc1plus error 33

I have to believe that this software compiles on some platforms, but not this one without work it seems.

Any more suggestions?

5

This appears to be this function…

584 bool DataDictionaryTestCase::readFromStream::onSetup 585 ( DataDictionary*& pObject ) 586 { 587 std::fstream stream( "../spec/FIX43.xml" ); 588 pObject = new DataDictionary( stream ); 589 return true; 590 }

But I fail to see how it’s getting that char[18] signature. If you pull the stream
def into a test file does it fail in the same way?

6

Make sure you use QCC -V3.3.5,gcc_ntox86_gpp. 2.95.3 is really old and most package out there compile with 3.x.x.

7

Thanks Mario. Overnight I was wondering about that and was planning to try it this morning. The quickFix docs gave a passing reference to 2.95.3 but could be out of date.

Am I right in believing that all libs it uses must also be compiled with the same version? If so, I’ll have to recompile lib-xml2. No problem, but it is something I need to know.

8

I posted this question before and no one had anything to say. If dynamic libraries foo.so needed to be compiled with the same compiler as your program, then how could programs compiled with different compilers work at all since the all need libc.so, right? I assume that your libxml2 is libxml2.so Bill.

9

It’s only the C++ component which has the compiler dependencies.

10

Success! Compiling with 3.3.1 (that came with my 6.3.0 release) compiled all the code and linked all the test apps.

I ran out of time to run the tests though because I had to fly to Boston Friday night, join my wife who had been away for 3 months, then drive back home to Clearwater through the remains of Tropical Storms Gustav and Hanna. We did the 22 hour drive (est. without stops) in 26 hours elapsed.

Thanks to everyone for the advice in getting this going.

11

I spoke too soon.

The extensive tests failed on lines that are essentially of the form:

assert( strtod( "0.00340244000", NULL ) == 0.00340244 );

A friend tried a small piece of test code under 6.3.0 SP3 and reported that such an assertion would succeed there, so I upgraded and tried again with the gcc 3.3.5.

Now the executables produced won’t even load! I get reports of “unknown relocation type” and memory faults.

I’ve been using QNX for 25+ years but with trying to port this package I am feeling like a total n00b. Nothing that I can see is wrong but nothing works, and I’m running out of time.

Is there a porting guru out there that could try a quick download, configure and make to see if I’m just doing (or forgetting) something stupid, or if there is a real problem so I can stop wasting my time.

If you download from www.quickfixengine.com then I ran configure as:

./configure CXX=QCC CXXFLAGS=-V3.3.5,gcc_ntox86_gpp

Oh, before I ran configure I had to edit that script to remove “-ansi” from the SHAREDFLAGS somewhere around line 19630.

Also before running make I changed a couple of references from bash to sh in src/Makefile and src/C++/Makefile.

Then:

make
cd test
./runut

Pick a port that isn’t otherwise used. I tried 11000. Make takes a while (lots and LOTS) to make, so just start it up and get a coffee.

Did I mention that I’d REALLY appreciate someone, anyone taking a look at this?

12

I’m on 6.3.2 initial ./configure shows libxml2 isn’t available, which I’m setting up right now.

I’m guessing the error “unknown relocation type” is because some required .so, like libxml2.so were not build with the same version of gcc.

13

Mario, thanks for taking a look. Yeah, I forgot to mention libxml2.

Hmmm … compiler version problem; that would be easy enough to fix. I’ll try that now. [Oops, I’m at work and I’ve got it setup at home. I’ll check it tonight.]

Like I said: something stupid I did or didn’t do.

14

Lunch time is over, here is what I found so far. AR in libtool points to ar and RANLIB points to ranlib. I replaced AR with QCC -v… -A and got rid of RANLIB. With this it’s able to build libquickfixcpptest.a without any error. Will resume later today.

15

I’ll plug those changes into my copy at home tonight and try to take it further.

16

Bill you can’t mix the 2.95.3 and 3.3.5 stuff at all - you have to set the 3.3.5 version for BOTH compile and link. Probably the safest thing to do is to set the global default to the 3.3.5 (check the qcc usemsg for how to do that).

17

Colin, I appreciate your advice but what if it doesn’t use qcc to link? It appears to be using ntox86-ld directly.

I’ve set the default as suggested and left it compiling while I’m at the office. (This project is one of 3 jobs I’m holding down at the same time, besides father and husband.) Tonight I’ll see if it worked.

So far I still can’t get this to port and my client is telling me to move on … that I’ve wasted too much time trying to get this to work under QNX. I’ve been forced to give up trying to port this to QNX so unless someone can give me the magic incantation today that makes it work then I’m outta here. :frowning:

I really want to stick with QNX if I could but tonight I will be forced to look at other platforms.

18

Yes the makefile are somewhat broken, ar and runlib are called directly.

19

OK, sounds like it is time for me to move on then. Sounds like the package is too specifically targetted at a “pure” GNU environment (if that is the correct term).

I’m not supposed to be spending my time trying to port QuickFIX. I’m supposed to spend my time writing an app which will be communicating using the FIX protocol.

Drop dead decision time for how to do this project is 7pm EDT today.