Archived issue #0028352
Qt tutorials cannot be built with nmake
Description
The *.pro files define two library paths separated by a semicolon. If a nmake Makefile is generated with qmake the linking fails with the error message LNK1181 that TKernel.lib cannot be found. Defining both library paths in extra lines solves that problem.
Steps to reproduce
Build Samples
Public activity
10 archived notes
Participants are labeled by their role within this record.
Branch [archived branch] has been created by Author.
[revision removed]
Detailed log of new commits:
Author: Benjamin Bihler
Date: Fri Jan 13 11:42:59 2017 +0100
0028352: Qt tutorials cannot be built with nmake
Library paths are now defined in two separate lines.
[revision removed]
Detailed log of new commits:
Author: Benjamin Bihler
Date: Fri Jan 13 11:42:59 2017 +0100
0028352: Qt tutorials cannot be built with nmake
Library paths are now defined in two separate lines.
Should I be more verbose about what the change is good for?
If someone wants to compile the Qt samples on the command line with nmake, he can modify genproj.bat in the samples directories and replace the line
qmake -tp vc -r -o Tutorial.sln Tutorial0.pro
with
qmake -o Makefile Tutorial0.pro
But then he will get strange error messages during build. The reason is that two library paths are defined in one line in the .pro files which seems not to be compatible with nmake.
If compilation after my changes works also with Visual Studio (which I cannot test here), then my change should be beneficial.
If someone wants to compile the Qt samples on the command line with nmake, he can modify genproj.bat in the samples directories and replace the line
qmake -tp vc -r -o Tutorial.sln Tutorial0.pro
with
qmake -o Makefile Tutorial0.pro
But then he will get strange error messages during build. The reason is that two library paths are defined in one line in the .pro files which seems not to be compatible with nmake.
If compilation after my changes works also with Visual Studio (which I cannot test here), then my change should be beneficial.
Reminder sent to: Commenter 3
Dear kgv,
would you mind having a look at this issue? I have already created a solution for it. Is there a specific reason why it has been ignored?
Thank you,
Benjamin
Dear kgv,
would you mind having a look at this issue? I have already created a solution for it. Is there a specific reason why it has been ignored?
Thank you,
Benjamin
Please check building of Qt samples.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Kirill,
Building by Visual Studio projects
Tutorial and IESample compilation give errors when linking.
It seems now samples do not see path to OCCT libraries
http://jenkins-test-08.nnov.opencascade.com/view/IR-2017-06-22_IR-2017-06-22/view/OCCT%20compile/job/IR-2017-06-22_IR-2017-06-22-OCCT-Windows-64-VC10-sample-qt/9/parsed_console/
Building by Visual Studio projects
Tutorial and IESample compilation give errors when linking.
It seems now samples do not see path to OCCT libraries
http://jenkins-test-08.nnov.opencascade.com/view/IR-2017-06-22_IR-2017-06-22/view/OCCT%20compile/job/IR-2017-06-22_IR-2017-06-22-OCCT-Windows-64-VC10-sample-qt/9/parsed_console/
1>Link: 1> Creating library win64\vc10\bin\\IESample.lib and object win64\vc10\bin\\IESample.exp 1>Translate.obj : error LNK2019: unresolved external symbol "public: enum IFSelect_ReturnStatus __cdecl STEPControl_Writer::Write(char const * const)" (?Write@STEPControl_Writer@@QEAA?AW4IFSelect_ReturnStatus@@QEBD@Z) referenced in function "private: bool __cdecl Translate::exportSTEP(class QString const &,class opencascade::handle<class TopTools_HSequenceOfShape> const &)" (?exportSTEP@Translate@@AEAA_NAEBVQString@@AEBV?$handle@VTopTools_HSequenceOfShape@@@opencascade@@@Z) 1>Translate.obj : error LNK2019: unresolved external symbol "public: enum IFSelect_ReturnStatus __cdecl STEPControl_Writer::Transfer(class TopoDS_Shape const &,enum STEPControl_StepModelType,bool)" (?Transfer@STEPControl_Writer@@QEAA?AW4IFSelect_ReturnStatus@@AEBVTopoDS_Shape@@W4STEPControl_StepModelType@@_N@Z) referenced in function "private: bool __cdecl Translate::exportSTEP(class QString const &,class opencascade::handle<class TopTools_HSequenceOfShape> const &)" (?exportSTEP@Translate@@AEAA_NAEBVQString@@AEBV?$handle@VTopTools_HSequenceOfShape@@@opencascade@@@Z) 1>Translate.obj : error LNK2019: unresolved external symbol "public: __cdecl STEPControl_Writer::STEPControl_Writer(void)" (??0STEPControl_Writer@@QEAA@XZ) referenced in function "private: bool __cdecl Translate::exportSTEP(class QString const &,class opencascade::handle<class TopTools_HSequenceOfShape> const &)" (?exportSTEP@Translate@@AEAA_NAEBVQString@@AEBV?$handle@VTopTools_HSequenceOfShape@@@opencascade@@@Z) 1>Translate.obj : error LNK2019: unresolved external symbol "public: bool __cdecl STEPControl_Reader::TransferRoot(int)" (?TransferRoot@STEPControl_Reader@@QEAA_NH@Z) referenced in function "private: class opencascade::handle<class TopTools_HSequenceOfShape> __cdecl Translate::importSTEP(class QString const &)" (?importSTEP@Translate@@AEAA?AV?$handle@VTopTools_HSequenceOfShape@@@opencascade@@AEBVQString@@@Z) 1>Translate.obj : error LNK2019: unresolved external symbol "public: virtual int __cdecl STEPControl_Reader::NbRootsForTransfer(void)" (?NbRootsForTransfer@STEPControl_Reader@@UEAAHXZ) referenced in function "private: class opencascade::handle<class TopTools_HSequenceOfShape> __cdecl Translate::importSTEP(class QString const &)" (?importSTEP@Translate@@AEAA?AV?$handle@VTopTools_HSequenceOfShape@@@opencascade@@AEBVQString@@@Z) 1>Translate.obj : error LNK2019: unresolved external symbol "public: __cdecl STEPControl_Reader::STEPControl_Reader(void)" (??0STEPControl_Reader@@QEAA@XZ) referenced in function "private: class opencascade::handle<class TopTools_HSequenceOfShape> __cdecl Translate::importSTEP(class QString const &)" (?importSTEP@Translate@@AEAA?AV?$handle@VTopTools_HSequenceOfShape@@@opencascade@@AEBVQString@@@Z) 1>win64\vc10\bin\\IESample.exe : fatal error LNK1120: 6 unresolved externals 1> 1>Build FAILED. 1>
Branch [archived branch] has been updated by Author.
[revision removed]
Detailed log of new commits:
Author: Benjamin Bihler
Date: Tue Jun 27 15:06:58 2017 +0200
0028352: Qt tutorials cannot be built with nmake
Library paths are defined in two separate lines for nmake and in one line
separated by a semicolon for all other cases. The distinction is done by
checking the template string.
[revision removed]
Detailed log of new commits:
Author: Benjamin Bihler
Date: Tue Jun 27 15:06:58 2017 +0200
0028352: Qt tutorials cannot be built with nmake
Library paths are defined in two separate lines for nmake and in one line
separated by a semicolon for all other cases. The distinction is done by
checking the template string.
Kirill,
this is a pity. :-( I have fixed the *.pro files now by introducing a distinction depending on the template string. If the template is "app" then a (nmake) Makefile is created by qmake on Windows (if the MS compiler is present), if the template is "vcapp" then a Visual Studio project is created. I use that for distinction and the created Makefile works now well with nmake. My changes should be transparent to Visual Studio users.
Still... since I seem to be the only one using name, if it bothers you that the *.pro files are cluttered up with several extra lines, you might also decide to reject my solution. I would then do my adaptions locally everytime I want to build the samples.
Benjamin
this is a pity. :-( I have fixed the *.pro files now by introducing a distinction depending on the template string. If the template is "app" then a (nmake) Makefile is created by qmake on Windows (if the MS compiler is present), if the template is "vcapp" then a Visual Studio project is created. I use that for distinction and the created Makefile works now well with nmake. My changes should be transparent to Visual Studio users.
Still... since I seem to be the only one using name, if it bothers you that the *.pro files are cluttered up with several extra lines, you might also decide to reject my solution. I would then do my adaptions locally everytime I want to build the samples.
Benjamin
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]