QtCreator 4.1.0 Qt 5.7.0 Windows 10 MinGW problem
-
Well I do not know how to answer you JKSH.
It seems the LIBS statement is not interpreting the path and .dll name correctly for FFTW3 dll's. As you pointed out earlier, if the correct syntax is used, the linker does not find the libraries. When specified as -L<path>/<libname.dll> the linker seems to find the libraries and tries to link with them. Not sure if that is a bug in the Windows 32 bit version of qmake or something else. It needs to work as advertised but doesn't.
I also notice that if a substitution like $$FFTW3_LIB_PATH is used but not defined, the qmake hangs indefinitely without giving a message. Something new I just discovered.
I will also say that in desperation, I have uninstalled Qt, cleaned the registry and file system, and reinstalled Qt with no change in the problem.
At this point I believe the LIBS problem is a bug and possibly the substitution problem as well.
@ad5xj said in QtCreator 4.1.0 Qt 5.7.0 Windows 10 MinGW problem:
When specified as -L<path>/<libname.dll> the linker seems to find the libraries and tries to link with them.
How do you know that the linker found the libraries? What messages do you get?
If you see "Undefined references", that means your linker couldn't find the libraries.
I also notice that if a substitution like $$FFTW3_LIB_PATH is used but not defined, the qmake hangs indefinitely without giving a message. Something new I just discovered.
Hmm... sounds like a bug, but I wouldn't worry about it for now.
At this point I believe the LIBS problem is a bug and possibly the substitution problem as well.
That's why I asked you to get rid of substitution and use hard-coded paths like
LIBS += -LC:/FFTW3 -lfftw3-3You can also try
LIBS += C:/FFTW3/libfftw3-3.dll(don't write "-L")Well I do not know how to answer you JKSH.
The answer is, "No, the problems are not yet gone" ;)
We'll get there eventually, I'm sure.
-
Well I do not know how to answer you JKSH.
It seems the LIBS statement is not interpreting the path and .dll name correctly for FFTW3 dll's. As you pointed out earlier, if the correct syntax is used, the linker does not find the libraries. When specified as -L<path>/<libname.dll> the linker seems to find the libraries and tries to link with them. Not sure if that is a bug in the Windows 32 bit version of qmake or something else. It needs to work as advertised but doesn't.
I also notice that if a substitution like $$FFTW3_LIB_PATH is used but not defined, the qmake hangs indefinitely without giving a message. Something new I just discovered.
I will also say that in desperation, I have uninstalled Qt, cleaned the registry and file system, and reinstalled Qt with no change in the problem.
At this point I believe the LIBS problem is a bug and possibly the substitution problem as well.
@ad5xj said in QtCreator 4.1.0 Qt 5.7.0 Windows 10 MinGW problem:
It seems the LIBS statement is not interpreting the path and .dll name correctly for FFTW3 dll's.
What statement are you using? One doesn't link to
.dllfiles, and one doesn't need a path to a.dllfile for linkage.When specified as -L<path>/<libname.dll> the linker seems to find the libraries and tries to link with them.
That most certainly isn't true.
-Lis for specifying only additional link directories.It needs to work as advertised but doesn't.
How is it advertised?
-
JKSH
I created a much smaller sub-project with only one form (mainwindow) and tested to see what would happen with the two different LIBS statements.
When stated: LIBS += -L$${FFTW3_LIB_PATH}/ -llibfftw3-3.dll
The linker does not find the dll.
When stated: LIBS += -L$${FFTW3_LIB_PATH}/libfftw3-3.dll
The linker finds the dll and successfully links the exe. It does run as expected.
However, in the larger project, this approach does not work - it does have the undefined reference error messages for the FFTW3 functions with the latter form of the LIBS statement and does not find the dlls (link output - file not found) with the former.
kshegunov
Your message seems contradictory to the thread messages so far. I have tried to eliminate the LIBS statement referencing the dlls but that does not even work at all.
Ken AD5XJ
-
JKSH
I created a much smaller sub-project with only one form (mainwindow) and tested to see what would happen with the two different LIBS statements.
When stated: LIBS += -L$${FFTW3_LIB_PATH}/ -llibfftw3-3.dll
The linker does not find the dll.
When stated: LIBS += -L$${FFTW3_LIB_PATH}/libfftw3-3.dll
The linker finds the dll and successfully links the exe. It does run as expected.
However, in the larger project, this approach does not work - it does have the undefined reference error messages for the FFTW3 functions with the latter form of the LIBS statement and does not find the dlls (link output - file not found) with the former.
kshegunov
Your message seems contradictory to the thread messages so far. I have tried to eliminate the LIBS statement referencing the dlls but that does not even work at all.
Contradictory? Redundant is more like it. Let me quote a couple:
@VRonin said in QtCreator 4.1.0 Qt 5.7.0 Windows 10 MinGW problem:
also you never set the
LIBSvariableLIBS += -L$${QWT_LIB_PATH} -L$${QWT_LIB_PATH} -lfftw3-3 -lqwt@kshegunov said in QtCreator 4.1.0 Qt 5.7.0 Windows 10 MinGW problem:
should be:
LIBS += -L$${FFTW3_LIB_PATH} -lfftw3-3 -lfftw3l-3 -lfftw3f-3And then I added:
And you should have the appropriate .lib (or .a if you're using mingw) files in
$${FFTW3_LIB_PATH}.Here's the
qmakevariable reference, as you can see yourself there's no guesswork involved in all this. -
JKSH
I created a much smaller sub-project with only one form (mainwindow) and tested to see what would happen with the two different LIBS statements.
When stated: LIBS += -L$${FFTW3_LIB_PATH}/ -llibfftw3-3.dll
The linker does not find the dll.
When stated: LIBS += -L$${FFTW3_LIB_PATH}/libfftw3-3.dll
The linker finds the dll and successfully links the exe. It does run as expected.
However, in the larger project, this approach does not work - it does have the undefined reference error messages for the FFTW3 functions with the latter form of the LIBS statement and does not find the dlls (link output - file not found) with the former.
kshegunov
Your message seems contradictory to the thread messages so far. I have tried to eliminate the LIBS statement referencing the dlls but that does not even work at all.
@ad5xj said in QtCreator 4.1.0 Qt 5.7.0 Windows 10 MinGW problem:
However, in the larger project, this approach does not work
Did you set
$${FFTW3_LIB_PATH}to different values in the 2 different projects?C:/FFTW3/is not equal toC:/FFTW3When stated: LIBS += -L$${FFTW3_LIB_PATH}/ -llibfftw3-3.dll
The linker does not find the dll.
That should be
-lfftw3-3, not-llibfftw3-3.dll -
kshegunov
You must be confused. The thread has moved far past the VRonin post.
As to your reference to the qmake variable reference; here is the quote from the docs:
"LIBS
Specifies a list of libraries to be linked into the project. If you use the Unix -l (library) and -L (library path) flags, qmake handles the libraries correctly on Windows (that is, passes the full path of the library to the linker). The library must exist for qmake to find the directory where a -l lib is located.
For example:unix:LIBS += -L/usr/local/lib -lmath
win32:LIBS += c:/mylibs/math.lib
"
You can plainly see the full pathname including the file name is in the LIBS statement. I understand the example is a static library reference and not a dll but there is no such distiinction made - with or without the .dll extension.I did not feel that LIBS += $${FFTW3_LIB_PATH}/libfftw3-3.dll violated that example. It seems you have another idea and I would like to hear it. I am just looking for the correct way to get this done. The docs do not seem to contradict my use of the above statement, but I am open to a different way of doing it. Doing what you indicate does not work either.
I have -- several times at suggestions from other posts -- eliminated the dll reference from the .pro file. As stated this does not work.
Now, whether this is a bug or some quirk of qmake I do not know. I just want it to work.
JKSH
No. The same .pri was used to define the variables in the sub-project. So no there essentially no difference in the variable substitution value.
Ken AD5XJ
-
kshegunov
You must be confused. The thread has moved far past the VRonin post.
As to your reference to the qmake variable reference; here is the quote from the docs:
"LIBS
Specifies a list of libraries to be linked into the project. If you use the Unix -l (library) and -L (library path) flags, qmake handles the libraries correctly on Windows (that is, passes the full path of the library to the linker). The library must exist for qmake to find the directory where a -l lib is located.
For example:unix:LIBS += -L/usr/local/lib -lmath
win32:LIBS += c:/mylibs/math.lib
"
You can plainly see the full pathname including the file name is in the LIBS statement. I understand the example is a static library reference and not a dll but there is no such distiinction made - with or without the .dll extension.I did not feel that LIBS += $${FFTW3_LIB_PATH}/libfftw3-3.dll violated that example. It seems you have another idea and I would like to hear it. I am just looking for the correct way to get this done. The docs do not seem to contradict my use of the above statement, but I am open to a different way of doing it. Doing what you indicate does not work either.
I have -- several times at suggestions from other posts -- eliminated the dll reference from the .pro file. As stated this does not work.
Now, whether this is a bug or some quirk of qmake I do not know. I just want it to work.
JKSH
No. The same .pri was used to define the variables in the sub-project. So no there essentially no difference in the variable substitution value.
@ad5xj said in QtCreator 4.1.0 Qt 5.7.0 Windows 10 MinGW problem:
You must be confused.
I must have been.
-
kshegunov
You must be confused. The thread has moved far past the VRonin post.
As to your reference to the qmake variable reference; here is the quote from the docs:
"LIBS
Specifies a list of libraries to be linked into the project. If you use the Unix -l (library) and -L (library path) flags, qmake handles the libraries correctly on Windows (that is, passes the full path of the library to the linker). The library must exist for qmake to find the directory where a -l lib is located.
For example:unix:LIBS += -L/usr/local/lib -lmath
win32:LIBS += c:/mylibs/math.lib
"
You can plainly see the full pathname including the file name is in the LIBS statement. I understand the example is a static library reference and not a dll but there is no such distiinction made - with or without the .dll extension.I did not feel that LIBS += $${FFTW3_LIB_PATH}/libfftw3-3.dll violated that example. It seems you have another idea and I would like to hear it. I am just looking for the correct way to get this done. The docs do not seem to contradict my use of the above statement, but I am open to a different way of doing it. Doing what you indicate does not work either.
I have -- several times at suggestions from other posts -- eliminated the dll reference from the .pro file. As stated this does not work.
Now, whether this is a bug or some quirk of qmake I do not know. I just want it to work.
JKSH
No. The same .pri was used to define the variables in the sub-project. So no there essentially no difference in the variable substitution value.
@ad5xj said in QtCreator 4.1.0 Qt 5.7.0 Windows 10 MinGW problem:
I did not feel that LIBS += $${FFTW3_LIB_PATH}/libfftw3-3.dll violated that example.
OK, first things first: I'm seeing small but important inconsistencies in your various posts, such as:
LIBS += -L$${FFTW3_LIB_PATH}/libfftw3-3.dllvs.LIBS += $${FFTW3_LIB_PATH}/libfftw3-3.dll
...and...
-lfftw3-3vs.-llibfftw3-3.dll
It's not clear to me: Are those are typos in this thread, or did you tried both in your .pro file?
another idea ... I would like to hear it.
I've mentioned this a few times before, but I haven't seen you try it yet: Hard code your paths.
LIBS += -LC:/FFTW3 -lfftw3-3and/orLIBS += C:/FFTW3/libfftw3-3.dll
Also, close Qt Creator, delete your
*.pro.userfile, delete yourbuild-*folder, and then try building from scratch.No. The same .pri was used to define the variables in the sub-project. So no there essentially no difference in the variable substitution value.
I don't see any *.pri files in this thread. Please post your latest *.pro and *.pri files.
-
SUCCESS!
It seems I was so focused on the problem I did not listen to the complete answer enough to put it all together.
Before your last post JKSH I did go back and combine all the permutations of the posted suggestions. It winds up that your last post is exactly what I got to work completely.
I want to thank all of you for your patience.
But this does raise some questions. Why is the qmake syntax check so dumb? Why is the Linux qmake so different and even overly forgiving of what could be common mistakes like this (yes I am admitting it is my mistake)? Why default path checking to the linker when that is way too late?
Oh well, I don't run things at Digia so this is what we have. Thanks to all and i really do appreciate this forum.
Ken AD5XJ
-
SUCCESS!
It seems I was so focused on the problem I did not listen to the complete answer enough to put it all together.
Before your last post JKSH I did go back and combine all the permutations of the posted suggestions. It winds up that your last post is exactly what I got to work completely.
I want to thank all of you for your patience.
But this does raise some questions. Why is the qmake syntax check so dumb? Why is the Linux qmake so different and even overly forgiving of what could be common mistakes like this (yes I am admitting it is my mistake)? Why default path checking to the linker when that is way too late?
Oh well, I don't run things at Digia so this is what we have. Thanks to all and i really do appreciate this forum.
@ad5xj said in QtCreator 4.1.0 Qt 5.7.0 Windows 10 MinGW problem:
SUCCESS!
Awesome :)
Don't keep us in suspense: What was the missing ingredient?
It seems I was so focused on the problem I did not listen to the complete answer enough to put it all together.
Moral of the story: Be systematic; Try every suggestion one by one, and provide feedback one by one.
Why is the qmake syntax check so dumb?
You provided valid qmake syntax. qmake simply passes your parameters on to the linker.
qmake does not truly understand what the linker wants or needs. (It's the same principle as writing your own custom MAKEFILE: The
maketool simply calls the commands that you specified, but it can't check your parameters)I agree that it would be nice if the linker could give better feedback.
Why is the Linux qmake so different and even overly forgiving of what could be common mistakes like this (yes I am admitting it is my mistake)?
The Linux qmake is the same as the Windows qmake -- they have the same source code.
However, Linux binaries are structured differently from Windows binaries. As a result, Windows needs to resolve 3rd-party function calls at build-time, but Linux only needs to do that at load-time (when you run the application).
Why default path checking to the linker when that is way too late?
Again, qmake's job is to pass your parameters to the relevant low-level tools (and it supports many many different kinds of tools). It doesn't make sense to ask it to check your parameters.
-
Ok, as I explained...I tried the individual suggestions one at a time. But what I did not do is mentally connect several that wound up being the solution:
As to qmake; quite often qmake emits console messages in the Application Output tab when there are syntax error unliike the ones I mentioned. In this case I was thinking that it should be possible for qmake to determine a problem with errors in the LIBS line just the same. Evidently not.
Ok, if qmake is the same on Linux as Windows then it has to be the GCC g++ compiler or linker that is so different. Something is different because they certainly do not produce the same indications with the same code.
In any event I can now proceed and it is thanks to all of you.
