QCA/toPEM() Assertion failures

Heya

I'm having a few problems with key/certificate generation; I
want to
convert the objects to PEM strings so I can store them in a
database,
but whenever I call toPEM() on either my PrivateKey,
PublicKey or
Certificate objects, an assertion failure is triggered later
on,
during the processing of the Qt event loop.

My apologies if this is not a fault with QCA, but I can
cause or
remove the assertion failure by simply commenting out the
QString
thingPem = thing.toPEM(); lines from the following code.
Given that
the failure happens later, I can perfectly happily qDebug()
<<
thing.toPEM() and see that the method works.

Is this possibly a fault in QCA, or more likely a corrupt
stack
somewhere else in my own code?

Thanks

/* Code */

int FirstRunWizard::run() {

// ...

	// Generate the public and private keys for this user
	int bits =
SettingsManager::getConfig("security.ssl.bits").to
Int();
	QCA::PrivateKey privateKey =
m_keyGenerator->createRSA(bits);
//->	//QString privateKeyPem = privateKey.toPEM();
	SettingsManager::setConfig("server.ssl.key",
""/*privateKeyPem*/);

	// Obtain the public key
	QCA::PublicKey publicKey = privateKey.toPublicKey();
//->	//QString publicKeyPem = publicKey.toPEM();

	// Create a self-signed certificate using these keys
	QCA::CertificateInfo certificateInfo;
	certificateInfo.insert(QCA::CommonName, peerName);

	QCA::CertificateOptions certificateOptions;
	certificateOptions.setInfo(certificateInfo);
	QCA::Certificate certificate(certificateOptions,
privateKey);
//->	//QString certificatePem = certificate.toPEM();
	SettingsManager::setConfig("server.ssl.certificate&quo
t;, ""/*certificatePem*/);

// ...

	return result;
}

For each of these toPEM() calls, I get the following
failures:

---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!

Program: c:UsersBenDocumentsprojecttrunkbinrsdss.exe
File: f:ddvctoolscrt_bldself_x86crtsrcdbgheap.c
Line: 1317

Expression: _CrtIsValidHeapPointer(pUserData)

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
---------------------------
Abort   Retry   Ignore
---------------------------


---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!

Program: c:UsersBenDocumentsprojecttrunkbinrsdss.exe
File: f:ddvctoolscrt_bldself_x86crtsrcdbgheap.c
Line: 1317

Expression: _CrtIsValidHeapPointer(pUserData)

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
---------------------------
Abort   Retry   Ignore
---------------------------


---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!

Program: c:UsersBenDocumentsprojecttrunkbinrsdss.exe
File: f:ddvctoolscrt_bldself_x86crtsrcdbgheap.c
Line: 1323

Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
---------------------------
Abort   Retry   Ignore
---------------------------


And the stack trace for the PrivateKey::toPEM() is as
follows:

 	ntdll.dll!76f42ea8() 	
 	[Frames below may be incorrect and/or missing, no symbols
loaded for
ntdll.dll]
 	ntdll.dll!76fb0c9a() 	
 	ntdll.dll!76f84bdf() 	
 	ntdll.dll!76f61c21() 	
 	kernel32.dll!770a7a7e() 	
>	msvcr90d.dll!_free_base(void * pBlock=0x6683d496)  Line
109 + 0x13 bytes	C
 	0018d310()	
 	QtCored4.dll!qFree(void * ptr=0x017e8e58)  Line 62 + 0xa
bytes	C++
 	QtCored4.dll!QList<QObject *>::free(QListData:ata *
data=0x0018d388)  Line 560 + 0x9 bytes	C++
 	QtCored4.dll!00db15eb() 	
 	0018d3b0()	
 	QtCored4.dll!QCoreApplication::notifyInternal(QObject *
receiver=0x0180fa68, QEvent * event=0x0018d4c8)  Line 587 +
0x15
bytes	C++
 	QtCored4.dll!QCoreApplication::sendEvent(QObject *
receiver=0x0180fa68, QEvent * event=0x0018d4c8)  Line 215 +
0x39
bytes	C++
 	QtCored4.dll!QEventDispatcherWin32::event(QEvent *
e=0x017e9120)
Line 1055 + 0x10 bytes	C++
 	QtGuid4.dll!QApplicationPrivate::notify_helper(QObject *
receiver=0x0182f2b8, QEvent * e=0x017e9120)  Line 3768 +
0x11
bytes	C++
 	QtGuid4.dll!QApplication::notify(QObject *
receiver=0x0182f2b8,
QEvent * e=0x017e9120)  Line 3360 + 0x10 bytes	C++
 	QtCored4.dll!QCoreApplication::notifyInternal(QObject *
receiver=0x0182f2b8, QEvent * event=0x017e9120)  Line 587 +
0x15
bytes	C++
 	QtCored4.dll!QCoreApplication::sendEvent(QObject *
receiver=0x0182f2b8, QEvent * event=0x017e9120)  Line 215 +
0x39
bytes	C++
 	QtCored4.dll!QCoreApplicationPrivate::sendPostedEvents(QOb
ject *
receiver=0x00000000, int event_type=0x00000000, QThreadData
*
data=0x002ea3e8)  Line 1198 + 0xd bytes	C++
 	QtCored4.dll!QEventDispatcherWin32::processEvents(QFlags&l
t;enum
QEventLoop::ProcessEventsFlag> flags={...})  Line 671 +
0x10 bytes	C++
 	QtGuid4.dll!QGuiEventDispatcherWin32::processEvents(QFlags
<enum
QEventLoop::ProcessEventsFlag> flags={...})  Line 1087 +
0x15
bytes	C++
 	QtCored4.dll!QEventLoop::processEvents(QFlags<enum
QEventLoop::ProcessEventsFlag> flags={...})  Line
150	C++
 	QtCored4.dll!QEventLoop::exec(QFlags<enum
QEventLoop::ProcessEventsFlag> flags={...})  Line 200 +
0x1c bytes	C++
 	QtCored4.dll!QCoreApplication::exec()  Line 845 + 0x15
bytes	C++
 	QtGuid4.dll!QApplication::exec()  Line 3299	C++
 	rsdss.exe!MainApplication::main()  Line 219	C++
 	rsdss.exe!main(int argc=0x00000001, char * *
argv=0x002e5508)  Line 16	C++
 	rsdss.exe!__tmainCRTStartup()  Line 582 + 0x19 bytes	C
 	rsdss.exe!mainCRTStartup()  Line 399	C
 	kernel32.dll!770a3833() 	
 	ntdll.dll!76f3a9bd()
_______________________________________________
Delta mailing list
Deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

My guess is this is just a problem of mixing release and
debug builds.  Make 
sure you're linking against the correct qca lib, and also be
sure you're not 
loading wrong-mode plugins (Qt should protect against this,
but if in doubt 
just delete/move the wrong-mode plugins so they can't get
loaded).

Running 'qcatool2 plugins --debug' is also a good way to see
which plugin 
files are getting loaded.

-Justin

On Thursday 10 April 2008 4:47 am, optimism_ wrote:
> Heya
>
> I'm having a few problems with key/certificate
generation; I want to
> convert the objects to PEM strings so I can store them
in a database,
> but whenever I call toPEM() on either my PrivateKey,
PublicKey or
> Certificate objects, an assertion failure is triggered
later on,
> during the processing of the Qt event loop.
>
> My apologies if this is not a fault with QCA, but I can
cause or
> remove the assertion failure by simply commenting out
the QString
> thingPem = thing.toPEM(); lines from the following
code. Given that
> the failure happens later, I can perfectly happily
qDebug() <<
> thing.toPEM() and see that the method works.
>
> Is this possibly a fault in QCA, or more likely a
corrupt stack
> somewhere else in my own code?
>
> Thanks
>
> /* Code */
>
> int FirstRunWizard::run() {
>
> // ...
>
> 	// Generate the public and private keys for this user
> 	int bits =
SettingsManager::getConfig("security.ssl.bits").to
Int();
> 	QCA::PrivateKey privateKey =
m_keyGenerator->createRSA(bits);
> //->	//QString privateKeyPem = privateKey.toPEM();
> 	SettingsManager::setConfig("server.ssl.key",
""/*privateKeyPem*/);
>
> 	// Obtain the public key
> 	QCA::PublicKey publicKey = privateKey.toPublicKey();
> //->	//QString publicKeyPem = publicKey.toPEM();
>
> 	// Create a self-signed certificate using these keys
> 	QCA::CertificateInfo certificateInfo;
> 	certificateInfo.insert(QCA::CommonName, peerName);
>
> 	QCA::CertificateOptions certificateOptions;
> 	certificateOptions.setInfo(certificateInfo);
> 	QCA::Certificate certificate(certificateOptions,
privateKey);
> //->	//QString certificatePem =
certificate.toPEM();
>
	SettingsManager::setConfig("server.ssl.certificate&quo
t;,
> ""/*certificatePem*/);
>
> // ...
>
> 	return result;
> }
>
> For each of these toPEM() calls, I get the following
failures:
>
> ---------------------------
> Microsoft Visual C++ Debug Library
> ---------------------------
> Debug Assertion Failed!
>
> Program:
c:UsersBenDocumentsprojecttrunkbinrsdss.exe
> File: f:ddvctoolscrt_bldself_x86crtsrcdbgheap.c
> Line: 1317
>
> Expression: _CrtIsValidHeapPointer(pUserData)
>
> For information on how your program can cause an
assertion
> failure, see the Visual C++ documentation on asserts.
>
> (Press Retry to debug the application)
> ---------------------------
> Abort   Retry   Ignore
> ---------------------------
>
>
> ---------------------------
> Microsoft Visual C++ Debug Library
> ---------------------------
> Debug Assertion Failed!
>
> Program:
c:UsersBenDocumentsprojecttrunkbinrsdss.exe
> File: f:ddvctoolscrt_bldself_x86crtsrcdbgheap.c
> Line: 1317
>
> Expression: _CrtIsValidHeapPointer(pUserData)
>
> For information on how your program can cause an
assertion
> failure, see the Visual C++ documentation on asserts.
>
> (Press Retry to debug the application)
> ---------------------------
> Abort   Retry   Ignore
> ---------------------------
>
>
> ---------------------------
> Microsoft Visual C++ Debug Library
> ---------------------------
> Debug Assertion Failed!
>
> Program:
c:UsersBenDocumentsprojecttrunkbinrsdss.exe
> File: f:ddvctoolscrt_bldself_x86crtsrcdbgheap.c
> Line: 1323
>
> Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
>
> For information on how your program can cause an
assertion
> failure, see the Visual C++ documentation on asserts.
>
> (Press Retry to debug the application)
> ---------------------------
> Abort   Retry   Ignore
> ---------------------------
>
>
> And the stack trace for the PrivateKey::toPEM() is as
follows:
>
>  	ntdll.dll!76f42ea8()
>  	[Frames below may be incorrect and/or missing, no
symbols loaded for
> ntdll.dll]
>  	ntdll.dll!76fb0c9a()
>  	ntdll.dll!76f84bdf()
>  	ntdll.dll!76f61c21()
>  	kernel32.dll!770a7a7e()
>
> >	msvcr90d.dll!_free_base(void * pBlock=0x6683d496) 
Line 109 + 0x13
> > bytes	C
>
>  	0018d310()
>  	QtCored4.dll!qFree(void * ptr=0x017e8e58)  Line 62 +
0xa bytes	C++
>  	QtCored4.dll!QList<QObject
*>::free(QListData:ata *
> data=0x0018d388)  Line 560 + 0x9 bytes	C++
>  	QtCored4.dll!00db15eb()
>  	0018d3b0()
>  	QtCored4.dll!QCoreApplication::notifyInternal(QObject
*
> receiver=0x0180fa68, QEvent * event=0x0018d4c8)  Line
587 + 0x15
> bytes	C++
>  	QtCored4.dll!QCoreApplication::sendEvent(QObject *
> receiver=0x0180fa68, QEvent * event=0x0018d4c8)  Line
215 + 0x39
> bytes	C++
>  	QtCored4.dll!QEventDispatcherWin32::event(QEvent *
e=0x017e9120)
> Line 1055 + 0x10 bytes	C++
> 
	QtGuid4.dll!QApplicationPrivate::notify_helper(QObject *
> receiver=0x0182f2b8, QEvent * e=0x017e9120)  Line 3768
+ 0x11
> bytes	C++
>  	QtGuid4.dll!QApplication::notify(QObject *
receiver=0x0182f2b8,
> QEvent * e=0x017e9120)  Line 3360 + 0x10 bytes	C++
>  	QtCored4.dll!QCoreApplication::notifyInternal(QObject
*
> receiver=0x0182f2b8, QEvent * event=0x017e9120)  Line
587 + 0x15
> bytes	C++
>  	QtCored4.dll!QCoreApplication::sendEvent(QObject *
> receiver=0x0182f2b8, QEvent * event=0x017e9120)  Line
215 + 0x39
> bytes	C++
> 
	QtCored4.dll!QCoreApplicationPrivate::sendPostedEvents(QObj
ect *
> receiver=0x00000000, int event_type=0x00000000,
QThreadData *
> data=0x002ea3e8)  Line 1198 + 0xd bytes	C++
> 
	QtCored4.dll!QEventDispatcherWin32::processEvents(QFlags<
;enum
> QEventLoop::ProcessEventsFlag> flags={...})  Line
671 + 0x10 bytes	C++
> 
	QtGuid4.dll!QGuiEventDispatcherWin32::processEvents(QFlags&
lt;enum
> QEventLoop::ProcessEventsFlag> flags={...})  Line
1087 + 0x15
> bytes	C++
> 
	QtCored4.dll!QEventLoop::processEvents(QFlags<enum
> QEventLoop::ProcessEventsFlag> flags={...})  Line
150	C++
>  	QtCored4.dll!QEventLoop::exec(QFlags<enum
> QEventLoop::ProcessEventsFlag> flags={...})  Line
200 + 0x1c bytes	C++
>  	QtCored4.dll!QCoreApplication::exec()  Line 845 +
0x15 bytes	C++
>  	QtGuid4.dll!QApplication::exec()  Line 3299	C++
>  	rsdss.exe!MainApplication::main()  Line 219	C++
>  	rsdss.exe!main(int argc=0x00000001, char * *
argv=0x002e5508)  Line
> 16	C++ rsdss.exe!__tmainCRTStartup()  Line 582 + 0x19
bytes	C
>  	rsdss.exe!mainCRTStartup()  Line 399	C
>  	kernel32.dll!770a3833()
>  	ntdll.dll!76f3a9bd()
> _______________________________________________
> Delta mailing list
> Deltalists.affinix.com
> http://lists.affinix.com/listinfo.cgi/delta-affinix.com
_______________________________________________
Delta mailing list
Deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

qmake seems to be adding qca2.lib instead of qcad2.lib when
generating
the vs project files.
I manually changed the lib file, and it runs now, so well
spotted.

Why would qmake be adding the wrong library to the linker
options? Is
it likely that i've made a mistake in my pro file?

Thanks again

On 10/04/2008, Justin Karneges <justin-psi2affinix.com> wrote:
> My guess is this is just a problem of mixing release
and debug builds.  Make
>  sure you're linking against the correct qca lib, and
also be sure you're not
>  loading wrong-mode plugins (Qt should protect against
this, but if in doubt
>  just delete/move the wrong-mode plugins so they can't
get loaded).
>
>  Running 'qcatool2 plugins --debug' is also a good way
to see which plugin
>  files are getting loaded.
>
>  -Justin
>
>
>  On Thursday 10 April 2008 4:47 am, optimism_ wrote:
>  > Heya
>  >
>  > I'm having a few problems with key/certificate
generation; I want to
>  > convert the objects to PEM strings so I can store
them in a database,
>  > but whenever I call toPEM() on either my
PrivateKey, PublicKey or
>  > Certificate objects, an assertion failure is
triggered later on,
>  > during the processing of the Qt event loop.
>  >
>  > My apologies if this is not a fault with QCA, but
I can cause or
>  > remove the assertion failure by simply commenting
out the QString
>  > thingPem = thing.toPEM(); lines from the
following code. Given that
>  > the failure happens later, I can perfectly
happily qDebug() <<
>  > thing.toPEM() and see that the method works.
>  >
>  > Is this possibly a fault in QCA, or more likely a
corrupt stack
>  > somewhere else in my own code?
>  >
>  > Thanks
>  >
>  > /* Code */
>  >
>  > int FirstRunWizard::run() {
>  >
>  > // ...
>  >
>  >       // Generate the public and private keys for
this user
>  >       int bits =
SettingsManager::getConfig("security.ssl.bits").to
Int();
>  >       QCA::PrivateKey privateKey =
m_keyGenerator->createRSA(bits);
>  > //->  //QString privateKeyPem =
privateKey.toPEM();
>  >      
SettingsManager::setConfig("server.ssl.key",
""/*privateKeyPem*/);
>  >
>  >       // Obtain the public key
>  >       QCA::PublicKey publicKey =
privateKey.toPublicKey();
>  > //->  //QString publicKeyPem =
publicKey.toPEM();
>  >
>  >       // Create a self-signed certificate using
these keys
>  >       QCA::CertificateInfo certificateInfo;
>  >       certificateInfo.insert(QCA::CommonName,
peerName);
>  >
>  >       QCA::CertificateOptions
certificateOptions;
>  >      
certificateOptions.setInfo(certificateInfo);
>  >       QCA::Certificate
certificate(certificateOptions, privateKey);
>  > //->  //QString certificatePem =
certificate.toPEM();
>  >      
SettingsManager::setConfig("server.ssl.certificate"
;,
>  > ""/*certificatePem*/);
>  >
>  > // ...
>  >
>  >       return result;
>  > }
>  >
>  > For each of these toPEM() calls, I get the
following failures:
>  >
>  > ---------------------------
>  > Microsoft Visual C++ Debug Library
>  > ---------------------------
>  > Debug Assertion Failed!
>  >
>  > Program:
c:UsersBenDocumentsprojecttrunkbinrsdss.exe
>  > File:
f:ddvctoolscrt_bldself_x86crtsrcdbgheap.c
>  > Line: 1317
>  >
>  > Expression: _CrtIsValidHeapPointer(pUserData)
>  >
>  > For information on how your program can cause an
assertion
>  > failure, see the Visual C++ documentation on
asserts.
>  >
>  > (Press Retry to debug the application)
>  > ---------------------------
>  > Abort   Retry   Ignore
>  > ---------------------------
>  >
>  >
>  > ---------------------------
>  > Microsoft Visual C++ Debug Library
>  > ---------------------------
>  > Debug Assertion Failed!
>  >
>  > Program:
c:UsersBenDocumentsprojecttrunkbinrsdss.exe
>  > File:
f:ddvctoolscrt_bldself_x86crtsrcdbgheap.c
>  > Line: 1317
>  >
>  > Expression: _CrtIsValidHeapPointer(pUserData)
>  >
>  > For information on how your program can cause an
assertion
>  > failure, see the Visual C++ documentation on
asserts.
>  >
>  > (Press Retry to debug the application)
>  > ---------------------------
>  > Abort   Retry   Ignore
>  > ---------------------------
>  >
>  >
>  > ---------------------------
>  > Microsoft Visual C++ Debug Library
>  > ---------------------------
>  > Debug Assertion Failed!
>  >
>  > Program:
c:UsersBenDocumentsprojecttrunkbinrsdss.exe
>  > File:
f:ddvctoolscrt_bldself_x86crtsrcdbgheap.c
>  > Line: 1323
>  >
>  > Expression:
_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
>  >
>  > For information on how your program can cause an
assertion
>  > failure, see the Visual C++ documentation on
asserts.
>  >
>  > (Press Retry to debug the application)
>  > ---------------------------
>  > Abort   Retry   Ignore
>  > ---------------------------
>  >
>  >
>  > And the stack trace for the PrivateKey::toPEM()
is as follows:
>  >
>  >       ntdll.dll!76f42ea8()
>  >       [Frames below may be incorrect and/or
missing, no symbols loaded for
>  > ntdll.dll]
>  >       ntdll.dll!76fb0c9a()
>  >       ntdll.dll!76f84bdf()
>  >       ntdll.dll!76f61c21()
>  >       kernel32.dll!770a7a7e()
>  >
>  > >     msvcr90d.dll!_free_base(void *
pBlock=0x6683d496)  Line 109 + 0x13
>  > > bytes       C
>  >
>  >       0018d310()
>  >       QtCored4.dll!qFree(void * ptr=0x017e8e58) 
Line 62 + 0xa bytes  C++
>  >       QtCored4.dll!QList<QObject
*>::free(QListData:ata *
>  > data=0x0018d388)  Line 560 + 0x9 bytes       
C++
>  >       QtCored4.dll!00db15eb()
>  >       0018d3b0()
>  >      
QtCored4.dll!QCoreApplication::notifyInternal(QObject *
>  > receiver=0x0180fa68, QEvent * event=0x0018d4c8) 
Line 587 + 0x15
>  > bytes C++
>  >      
QtCored4.dll!QCoreApplication::sendEvent(QObject *
>  > receiver=0x0180fa68, QEvent * event=0x0018d4c8) 
Line 215 + 0x39
>  > bytes C++
>  >      
QtCored4.dll!QEventDispatcherWin32::event(QEvent *
e=0x017e9120)
>  > Line 1055 + 0x10 bytes        C++
>  >      
QtGuid4.dll!QApplicationPrivate::notify_helper(QObject *
>  > receiver=0x0182f2b8, QEvent * e=0x017e9120)  Line
3768 + 0x11
>  > bytes C++
>  >       QtGuid4.dll!QApplication::notify(QObject *
receiver=0x0182f2b8,
>  > QEvent * e=0x017e9120)  Line 3360 + 0x10 bytes   
    C++
>  >      
QtCored4.dll!QCoreApplication::notifyInternal(QObject *
>  > receiver=0x0182f2b8, QEvent * event=0x017e9120) 
Line 587 + 0x15
>  > bytes C++
>  >      
QtCored4.dll!QCoreApplication::sendEvent(QObject *
>  > receiver=0x0182f2b8, QEvent * event=0x017e9120) 
Line 215 + 0x39
>  > bytes C++
>  >      
QtCored4.dll!QCoreApplicationPrivate::sendPostedEvents(QObje
ct *
>  > receiver=0x00000000, int event_type=0x00000000,
QThreadData *
>  > data=0x002ea3e8)  Line 1198 + 0xd bytes      
C++
>  >      
QtCored4.dll!QEventDispatcherWin32::processEvents(QFlags<
enum
>  > QEventLoop::ProcessEventsFlag> flags={...}) 
Line 671 + 0x10 bytes    C++
>  >      
QtGuid4.dll!QGuiEventDispatcherWin32::processEvents(QFlags&l
t;enum
>  > QEventLoop::ProcessEventsFlag> flags={...}) 
Line 1087 + 0x15
>  > bytes C++
>  >      
QtCored4.dll!QEventLoop::processEvents(QFlags<enum
>  > QEventLoop::ProcessEventsFlag> flags={...}) 
Line 150 C++
>  >      
QtCored4.dll!QEventLoop::exec(QFlags<enum
>  > QEventLoop::ProcessEventsFlag> flags={...}) 
Line 200 + 0x1c bytes    C++
>  >       QtCored4.dll!QCoreApplication::exec()  Line
845 + 0x15 bytes    C++
>  >       QtGuid4.dll!QApplication::exec()  Line 3299
    C++
>  >       rsdss.exe!MainApplication::main()  Line 219
    C++
>  >       rsdss.exe!main(int argc=0x00000001, char *
* argv=0x002e5508)  Line
>  > 16    C++ rsdss.exe!__tmainCRTStartup()  Line 582
+ 0x19 bytes        C
>  >       rsdss.exe!mainCRTStartup()  Line 399    C
>  >       kernel32.dll!770a3833()
>  >       ntdll.dll!76f3a9bd()
>
> > _______________________________________________
>  > Delta mailing list
>  > Deltalists.affinix.com
>  > http://lists.affinix.com/listinfo.cgi/delta-affinix.com
>  _______________________________________________
>  Delta mailing list
>  Deltalists.affinix.com
>  http://lists.affinix.com/listinfo.cgi/delta-affinix.com
>
_______________________________________________
Delta mailing list
Deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Thursday 10 April 2008 12:57 pm, optimism_ wrote:
> qmake seems to be adding qca2.lib instead of qcad2.lib
when generating
> the vs project files.
> I manually changed the lib file, and it runs now, so
well spotted.
>
> Why would qmake be adding the wrong library to the
linker options? Is
> it likely that i've made a mistake in my pro file?

Did you add one of 'debug' or 'release' to the CONFIG
variable in your .pro 
file?
_______________________________________________
Delta mailing list
Deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

I have lots of pro files in my workspace, and im using QCA
in two of
them. One had debug, one had neither, both were linking
against
qca2.lib and neither against the debug version

On 10/04/2008, Justin Karneges <justin-psi2affinix.com> wrote:
> On Thursday 10 April 2008 12:57 pm, optimism_ wrote:
>  > qmake seems to be adding qca2.lib instead of
qcad2.lib when generating
>  > the vs project files.
>  > I manually changed the lib file, and it runs now,
so well spotted.
>  >
>  > Why would qmake be adding the wrong library to
the linker options? Is
>  > it likely that i've made a mistake in my pro
file?
>
>
> Did you add one of 'debug' or 'release' to the CONFIG
variable in your .pro
>  file?
>
> _______________________________________________
>  Delta mailing list
>  Deltalists.affinix.com
>  http://lists.affinix.com/listinfo.cgi/delta-affinix.com
>
_______________________________________________
Delta mailing list
Deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Thursday 10 April 2008 3:33 pm, optimism_ wrote:
> I have lots of pro files in my workspace, and im using
QCA in two of
> them. One had debug, one had neither, both were linking
against
> qca2.lib and neither against the debug version

And how were you linking in QCA?  Just adding 'crypto' to
CONFIG?
_______________________________________________
Delta mailing list
Deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

yes, is that wrong?

On 11/04/2008, Justin Karneges <justin-psi2affinix.com> wrote:
> On Thursday 10 April 2008 3:33 pm, optimism_ wrote:
>  > I have lots of pro files in my workspace, and im
using QCA in two of
>  > them. One had debug, one had neither, both were
linking against
>  > qca2.lib and neither against the debug version
>
>
> And how were you linking in QCA?  Just adding 'crypto'
to CONFIG?
>
> _______________________________________________
>  Delta mailing list
>  Deltalists.affinix.com
>  http://lists.affinix.com/listinfo.cgi/delta-affinix.com
>
_______________________________________________
Delta mailing list
Deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Thursday 10 April 2008 5:02 pm, optimism_ wrote:
> On 11/04/2008, Justin Karneges <justin-psi2affinix.com> wrote:
> > On Thursday 10 April 2008 3:33 pm, optimism_
wrote:
> >  > I have lots of pro files in my workspace,
and im using QCA in two of
> >  > them. One had debug, one had neither, both
were linking against
> >  > qca2.lib and neither against the debug
version
> >
> > And how were you linking in QCA?  Just adding
'crypto' to CONFIG?
>
> yes, is that wrong?

It's correct.  The crypto.prf file has the rules for
choosing the 'd' library 
based on the build mode.  I'm not sure how the wrong library
is used then.

-Justin
_______________________________________________
Delta mailing list
Deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

I've just looked in crypto.prf and seen the following
construct:

CONFIG(debug, debug|release) {
	windows:LINKAGE = -lqcad
	mac:LINKAGE = -lqca_debug
}


I knew i'd seen something about that on the qt mailing list
so ive dug
up the post i recalled, and included it below. I think the
construct
used to select debug mode might be broken on windows.


---------- Forwarded message ----------
From: Massimo Nespolo <massimo_nespololibero.it>
Date: 6 Mar 2008 19:44
Subject: R: Missing Qt documentation
To: qt4-preview-feedbacktrolltech.com


> You still need to run make docs or nmake docs before
you can use
 > assistant, if you're using a snapshot.

 I downloaded the current snapshot
 (qt-win-opensource-src-4.4.0-snapshot-20080306.zip) this
morning, but I had
 to make a small correction in the doc.pri file: since the
"debug" version of
 the tools is usually not built under Windows, I replaced

 win32 {
    QT_WINCONFIG = release
    CONFIG(debug, debug|release) {
        QT_WINCONFIG = release
    }
 }

 With

 win32 {
    QT_WINCONFIG = release
 }

 After this, I modified the .qmake.cache as you said
yesterday, I ran "nmake
 docs", and the documentation was built!

 Thank you very much for your suggestions!


 Massimo

 To unsubscribe - send "unsubscribe" in the
subject to
qt4-preview-feedback-requesttrolltech.com



On 11/04/2008, Justin Karneges <justin-psi2affinix.com> wrote:
> On Thursday 10 April 2008 5:02 pm, optimism_ wrote:
>  > On 11/04/2008, Justin Karneges
<justin-psi2affinix.com> wrote:
>  > > On Thursday 10 April 2008 3:33 pm, optimism_
wrote:
>  > >  > I have lots of pro files in my
workspace, and im using QCA in two of
>  > >  > them. One had debug, one had neither,
both were linking against
>  > >  > qca2.lib and neither against the debug
version
>  > >
>  > > And how were you linking in QCA?  Just
adding 'crypto' to CONFIG?
>  >
>
> > yes, is that wrong?
>
>  It's correct.  The crypto.prf file has the rules for
choosing the 'd' library
>  based on the build mode.  I'm not sure how the wrong
library is used then.
>
>
>  -Justin
>
> _______________________________________________
>  Delta mailing list
>  Deltalists.affinix.com
>  http://lists.affinix.com/listinfo.cgi/delta-affinix.com
>
_______________________________________________
Delta mailing list
Deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

Weird.  This code was pretty much taken from what I saw Qt
itself doing.  I'm 
not a member of the Qt 4 preview list.  Are you using a 4.4
prerelease?  You 
might post asking what the "correct" qmake code
is, if for some reason they 
changed it.

On Thursday 10 April 2008 5:29 pm, optimism_ wrote:
> I've just looked in crypto.prf and seen the following
construct:
>
> CONFIG(debug, debug|release) {
> 	windows:LINKAGE = -lqcad
> 	mac:LINKAGE = -lqca_debug
> }
>
>
> I knew i'd seen something about that on the qt mailing
list so ive dug
> up the post i recalled, and included it below. I think
the construct
> used to select debug mode might be broken on windows.
>
>
> ---------- Forwarded message ----------
> From: Massimo Nespolo <massimo_nespololibero.it>
> Date: 6 Mar 2008 19:44
> Subject: R: Missing Qt documentation
> To: qt4-preview-feedbacktrolltech.com
>
> > You still need to run make docs or nmake docs
before you can use
> >
>  > assistant, if you're using a snapshot.
>
>  I downloaded the current snapshot
>  (qt-win-opensource-src-4.4.0-snapshot-20080306.zip)
this morning, but I
> had to make a small correction in the doc.pri file:
since the "debug"
> version of the tools is usually not built under
Windows, I replaced
>
>  win32 {
>     QT_WINCONFIG = release
>     CONFIG(debug, debug|release) {
>         QT_WINCONFIG = release
>     }
>  }
>
>  With
>
>  win32 {
>     QT_WINCONFIG = release
>  }
>
>  After this, I modified the .qmake.cache as you said
yesterday, I ran
> "nmake docs", and the documentation was
built!
>
>  Thank you very much for your suggestions!
>
>
>  Massimo
>
>  To unsubscribe - send "unsubscribe" in the
subject to
> qt4-preview-feedback-requesttrolltech.com
>
> On 11/04/2008, Justin Karneges <justin-psi2affinix.com> wrote:
> > On Thursday 10 April 2008 5:02 pm, optimism_
wrote:
> >  > On 11/04/2008, Justin Karneges
<justin-psi2affinix.com> wrote:
> >  > > On Thursday 10 April 2008 3:33 pm,
optimism_ wrote:
> >  > >  > I have lots of pro files in my
workspace, and im using QCA in two
> >  > >  > of them. One had debug, one had
neither, both were linking
> >  > >  > against qca2.lib and neither
against the debug version
> >  > >
> >  > > And how were you linking in QCA?  Just
adding 'crypto' to CONFIG?
> > >
> > > yes, is that wrong?
> >
> >  It's correct.  The crypto.prf file has the rules
for choosing the 'd'
> > library based on the build mode.  I'm not sure how
the wrong library is
> > used then.
> >
> >
> >  -Justin
> >
> > _______________________________________________
> >  Delta mailing list
> >  Deltalists.affinix.com
> >  http://lists.affinix.com/listinfo.cgi/delta-affinix.com
>
> _______________________________________________
> Delta mailing list
> Deltalists.affinix.com
> http://lists.affinix.com/listinfo.cgi/delta-affinix.com
_______________________________________________
Delta mailing list
Deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com