Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 5

Qt-interest Archive, April 2007
fstream call in a dynamic library within a Qt application


Message 1 in thread

Let' see if the third time is the charm.

Here's my situation:

I'm attempting to read a file in using a std::ifstream in what will  
eventually become a Qt application on OS X. The calls to create the  
input stream, open it, and read from it all happen within a dynamic  
library. I wrote a short main.cpp to read the first line from the  
file and then close the stream and exit.

In XCode if I put that main in a target generated by "qmake -spec  
macx-code <project pro file>" the fstream is only properly read when  
the creation, opening, and reading of the stream happen within main.  
That is, if I try to link the library in and execute *the exact same  
code,* but from a call to the library now, I get a "Program received  
signal:  "EXC_BAD_ACCESS" error.

HOWEVER, if create my own target (one not created by running qmake - 
spec macx-xcode), link the library, and read from the file using the  
library, it all works perfectly. This would be a fine solution, but  
that target doesn't have all the necessary qmake preprocessing setup,  
and it will also be lost if I change the .pro file and rerun qmake to  
regenerate the XCode project file.

All of this makes me think I'm missing something regarding using the  
dynamic library in a Qt application that's preprocessed using qmake.  
If anyone with a Mac dev environment is willing to help, I can send  
my source code and project files.

Thanks,
Aaron

--
 [ signature omitted ] 

Message 2 in thread

Hi,

> HOWEVER, if create my own target (one not created by running qmake -spec 
> macx-xcode), link the library, and read from the file using the library, 
> it all works perfectly.

There's probably a difference in the command lines used to build main.cpp in 
either case. It would be a good idea to :
* compare the command lines,
* incrementally modify the command line that works to match the one that 
doesn't, that should help identify the compiler option that's causing the crash.

--
 [ signature omitted ]