problems integrating Win7x64

[John-Michael Fischer]

Hi All, we were recently excited to discover qextserialport. In building and linking I had a few problems and so have tried two approaches. Neither is working.

Environment is MSVC 2010 SP1Rel, Qt 4.8.1, Win 7x64 only

Approach 1 - Build .lib's and link against them, include headers.
Built libs using Qt creator after double clicking on qextserialport.pro. It then prompted me to configured my targets, which I did. Click on the hammer to build. In my c++ solution I included src as includes, and copied over freshly built .lib's to debug+release libs respectively. I then ensured these libs were linked against in the configuration properties (standard practice, we have lots of third-party stuff). Functions are not found when I try and link against them.

DeviceFramework.lib(MySerialClass.obj) : error LNK2019: unresolved external symbol "public: class QByteArray __cdecl QextSerialPort::readAll(void)" (?readAll@QextSerialPort@@QEAA?AVQByteArray@@XZ) referenced in function "public: void __cdecl MySerialClass::logAndPassData(void)" (?logAndPassData@MySerialClass@@QEAAXXZ)
3>DeviceFramework.lib(MySerialClass.obj) : error LNK2019: unresolved external symbol "public: __cdecl QextSerialPort::QextSerialPort(class QString const &,struct PortSettings const &,enum QextSerialPort::QueryMode,class QObject *)" (??0QextSerialPort@@QEAA@AEBVQString@@AEBUPortSettings@@W4QueryMode@0@PEAVQObject@@@Z) referenced in function "protected: virtual bool __cdecl MySerialClass::initialize(void)" (?initialize@MySerialClass@@MEAA_NXZ)

Approach 2 - Include sources in our project (already using Qt, so why not) then build and link against them in our project.
Moc'ing is successful, and then when building the compile complains about QextSerialPortPrivate not being defined. Please note that I have removed some PII From the paths below, but on my screen I can confirm they are correct :)

1> moc_qextserialenumerator.cpp
1> moc_qextserialport.cpp
1> moc_qextwineventnotifier_p.cpp
1> qextserialenumerator.cpp
1> qextserialenumerator_win.cpp
1> qextserialport.cpp
1> qextserialport_win.cpp
1> qextwineventnotifier_p.cpp
1>GeneratedFiles\Debug\moc_qextserialport.cpp(122): error C2027: use of undefined type 'QextSerialPortPrivate'
1> c:\users\USERNAME\SOMEPATH\framework\qextserialport\generatedfiles\debug\../../qextserialport.h(168) : see declaration of 'QextSerialPortPrivate'
1>GeneratedFiles\Debug\moc_qextserialport.cpp(122): error C2227: left of '->_q_onWinEvent' must point to class/struct/union/generic type
1>GeneratedFiles\Debug\moc_qextserialport.cpp(122): error C2061: syntax error : identifier 'HANDLE'
1>GeneratedFiles\Debug\moc_qextserialport.cpp(123): error C2027: use of undefined type 'QextSerialPortPrivate'
1> c:\users\USERNAME\SOMEPATH\framework\qextserialport\generatedfiles\debug\../../qextserialport.h(168) : see declaration of 'QextSerialPortPrivate'
1>GeneratedFiles\Debug\moc_qextserialport.cpp(123): error C2227: left of '->_q_canRead' must point to class/struct/union/generic type
1> The command exited with code 2.
1>Done executing task "CL" -- FAILED.
1>Done building target "ClCompile" in project "QextSerialPort.vcxproj" -- FAILED.

After some digging, QextSerialPortPrivate is forward declared in qextserialport.h, and then the header is defined in qextserialport_p.h. The implementation lies in qextserialport.cpp and somehow I think the compiler is getting confused.

Thoughts? (on either approach...) Approach 1 is greatly preferable for obvious reasons.

[Lisandro Damián Nicanor Pérez Meyer]

Try starting again using the .pro inside buildlib/

I haven't tried (nor will I ;) ) inside Windows, but that should be the
correct approach.

Another approach is directly using qmake inside the aforementioned directory.

Kinds regards, Lisandro.

--
1: Una computadora sirve:
* Para tratar de dominar el mundo, un caso conocido de esto fue el de
Skinet
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[1+1=2]

Hi,

As I don't have a Win7 X64 OS, I could not reproduce the problem ;-(

On Thu, Aug 9, 2012 at 1:09 AM, John-Michael Fischer
<johnmicha...@gmail.com> wrote:
> Hi All, we were recently excited to discover qextserialport. In building and linking I had a few problems and so have tried two approaches. Neither is working.
>
> Environment is MSVC 2010 SP1Rel, Qt 4.8.1, Win 7x64 only
>
> Approach 1 - Build .lib's and link against them, include headers.
> Built libs using Qt creator after double clicking on qextserialport.pro. It then prompted me to configured my targets, which I did. Click on the hammer to build. In my c++ solution I included src as includes, and copied over freshly built .lib's to debug+release libs respectively. I then ensured these libs were linked against in the configuration properties (standard practice, we have lots of third-party stuff). Functions are not found when I try and link against them.
>
> DeviceFramework.lib(MySerialClass.obj) : error LNK2019: unresolved external symbol "public: class QByteArray __cdecl QextSerialPort::readAll(void)" (?readAll@QextSerialPort@@QEAA?AVQByteArray@@XZ) referenced in function "public: void __cdecl MySerialClass::logAndPassData(void)" (?logAndPassData@MySerialClass@@QEAAXXZ)
> 3>DeviceFramework.lib(MySerialClass.obj) : error LNK2019: unresolved external symbol "public: __cdecl QextSerialPort::QextSerialPort(class QString const &,struct PortSettings const &,enum QextSerialPort::QueryMode,class QObject *)" (??0QextSerialPort@@QEAA@AEBVQString@@AEBUPortSettings@@W4QueryMode@0@PEAVQObject@@@Z) referenced in function "protected: virtual bool __cdecl MySerialClass::initialize(void)" (?initialize@MySerialClass@@MEAA_NXZ)
>

You can run
@
dumpbin /EXPORTS qextserialport-1.2.dll
@
or using
@
dependency walker
@
to see whether these symbols are exported or not.

If they have been exported, perhaps your linker didn't found the
proper qextserialport-1.2(d).lib

>
> Approach 2 - Include sources in our project (already using Qt, so why not) then build and link against them in our project.
> Moc'ing is successful, and then when building the compile complains about QextSerialPortPrivate not being defined. Please note that I have removed some PII From the paths below, but on my screen I can confirm they are correct :)
>
> 1> moc_qextserialenumerator.cpp
> 1> moc_qextserialport.cpp
> 1> moc_qextwineventnotifier_p.cpp
> 1> qextserialenumerator.cpp
> 1> qextserialenumerator_win.cpp
> 1> qextserialport.cpp
> 1> qextserialport_win.cpp
> 1> qextwineventnotifier_p.cpp
> 1>GeneratedFiles\Debug\moc_qextserialport.cpp(122): error C2027: use of undefined type 'QextSerialPortPrivate'
> 1> c:\users\USERNAME\SOMEPATH\framework\qextserialport\generatedfiles\debug\../../qextserialport.h(168) : see declaration of 'QextSerialPortPrivate'
> 1>GeneratedFiles\Debug\moc_qextserialport.cpp(122): error C2227: left of '->_q_onWinEvent' must point to class/struct/union/generic type
> 1>GeneratedFiles\Debug\moc_qextserialport.cpp(122): error C2061: syntax error : identifier 'HANDLE'
> 1>GeneratedFiles\Debug\moc_qextserialport.cpp(123): error C2027: use of undefined type 'QextSerialPortPrivate'
> 1> c:\users\USERNAME\SOMEPATH\framework\qextserialport\generatedfiles\debug\../../qextserialport.h(168) : see declaration of 'QextSerialPortPrivate'
> 1>GeneratedFiles\Debug\moc_qextserialport.cpp(123): error C2227: left of '->_q_canRead' must point to class/struct/union/generic type
> 1> The command exited with code 2.
> 1>Done executing task "CL" -- FAILED.
> 1>Done building target "ClCompile" in project "QextSerialPort.vcxproj" -- FAILED.
>
> After some digging, QextSerialPortPrivate is forward declared in qextserialport.h, and then the header is defined in qextserialport_p.h. The implementation lies in qextserialport.cpp and somehow I think the compiler is getting confused.
>

It looks rather strange. In fact, moc_qextserialport.cpp is not a
compile unit, which can be thought as a header file, so it should not
be compiled independently.
If you have read the source code of qextserialport.cpp, you can found
following line
@
#include "moc_qextserialport.cpp"
@
So the problem is, why the compiler want to compile it.


Regards,

Debao

[John-Michael Fischer]

Several updates.  Summary: got linker running in non-official way.

I first wanted to attempt compilation using the built in projects and attempt to solve the linker errors.

Using the .pro's in buildlib yielded me import libraries with DLL's.  I couldn't link these against my program.  I saw in the README the possibility to generate static libraries.  Following the instructions of creating a separate .pri using the values in config_example, and then including them in the buildlib/buildlib.pro being very careful to locate my include statement as indicated in the comments -- yielded a still non-static build.  

I ended up removing my include statement in buildlib.pro and collapsing the if statement directly into 

CONFIG += static

Build's now produced static libraries. Yay.

copy them over, and link against them.  Linker finds the files, but cannot find symbols to link against.

The linker complains it cannot match this symbol

?readAll@QextSerialPort@@QEAA?AVQByteArray@@XZ (public: class QByteArray __cdecl QextSerialPort::readAll(void))

using dumpbin, I can see that my freshly minted .lib files contain the following signature

?readAll@QextSerialPort@@QAE?AVQByteArray@@XZ (public: class QByteArray __thiscall QextSerialPort::readAll(void))

The only difference is 

"QEAA?" vs "QAE?"

and

" __cdecl" vs " __thiscall"

I don't know how to fix the calling convention issue, and I don't know how the first linker prefix symbols are constructed.

Back to option 2.

Taking Debao's note about the compiler trying to compile the moc file's, I quickly exclude them from the build process (but ensure that the QT add-on is still creating the MOC files).  

Compiler is happy, and linker is happy too!  Yay.

If it's any interest in resolving the linker front, I have attached the dumpbin outputs for the QtCreator generated version, and my working MSVC generated versions.

If anyone has any ideas for me to test regarding the static+linking issues, I am happy to test out some things so that if we find a working procedure I will submit text to update the usage instructions.

Thanks!

[Lisandro Damián Nicanor Pérez Meyer]

On Jue 09 Aug 2012 11:07:07 John-Michael Fischer escribió:
[snip]

> Linker finds the files, but cannot
> find symbols to link against.
> The linker complains it cannot match this symbol
> ?readAll@QextSerialPort@@QEAA?AVQByteArray@@XZ (public: class QByteArray
> __cdecl QextSerialPort::readAll(void))
> using dumpbin, I can see that my freshly minted .lib files contain the
> following signature
> ?readAll@QextSerialPort@@QAE?AVQByteArray@@XZ (public: class QByteArray
> __thiscall QextSerialPort::readAll(void))
> The only difference is
> "QEAA?" vs "QAE?"
> and
> " __cdecl" vs " __thiscall"

It *may* be the same symbols problem I had in Linux. I think the best thing to
do it's to rewrite the .pro files (which are really messy nowadays).

I hope to have some time for this next week.

[John-Michael Fischer]

OK.  I will keep an eye on this thread and can test new stuff on Win7x64+MSVC10 as needed.

[1+1=2]

Hi All,

I have make a cleanup of the build-system.

The usage of the library can be found

http://code.google.com/p/qextserialport/wiki/QextSerialPort_1_2_RC

Hope it's easy to used that beta1 and beta2.

Regards

Debao

> --
> You received this message because you are subscribed to the Google Groups
> "qextserialport" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/qextserialport/-/Mj8NYzPCdQUJ.
>
> To post to this group, send email to qextser...@googlegroups.com.
> To unsubscribe from this group, send email to
> qextserialpor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/qextserialport?hl=en.

[Lisandro Damián Nicanor Pérez Meyer]

On Wed 15 Aug 2012 06:06:38 1+1=2 escribió:
> Hi All,
>
> I have make a cleanup of the build-system.
>
> The usage of the library can be found
>
> http://code.google.com/p/qextserialport/wiki/QextSerialPort_1_2_RC

This fixed the symbols problem!! :-D

I'm about to upload qextserialport as version 1.2.0~beta2+git12-ge279110-1 to
Debian experimental.

Note that I used 1.2.0 (complete major-minor-patch) and ~. This last one is
because of:

foo_1.2.0~beta1 < foo_1.2.0~beta2 < foo_1.2.0

Kinds regards, Lisandro.

--
UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity.
Dennis Ritchie

[John-Michael Fischer]

I wanted to briefly resurrect this thread to update the situation.  

Last week I tried this again and successfully compiled QExtSerialPort as a static library and then linked against said lib using Visual Studio 2010 targeting x64 architecture on Windows 7.  I believe this was the result of the fresh qextserialport packaging/website as well as a new version of QtCreator which has improved the UI for targeting.  Thanks to the team for your updates to the build system and website.  In case anyone else should wish to reproduce this here are the steps.

1. Download your desired qt version/architecture in source form.

2. Compile on windows.  For Qt 4.X versions this is the best guide I found - http://www.holoborodko.com/pavel/2011/02/01/how-to-compile-qt-4-7-with-visual-studio-2010/

3. Install QtCreator from qt-project.

4. Configure Qt version in QtCreator options.  If it complains about needing to run make install, run qmake.exe -query on your freshly compiled version to see where it _expects_ to be.  Make a copy there and try re-adding this qt copy in QtCreator.

5. Configure QtCreator target platform "kit".  For VS2010 choose the Visual C++ 10 compiler.  For x64 only choose VC++10 (amd64).  VS2012 should use VC++11 compilers although I haven't tried it.

6. Download qextserialport1.2rc and open the .pro and select this target "kit".  Uncomment for static lib.  Build (hammer icon).

7. You can now link again these generated .lib's in a VS2010 C++ project targeting x64.

Thanks!