"procedure entry point could not be located ..."

[ambershark]

@drmhkelley Yea you are most definitely mixing Qt dlls. So what you can try is to clear your path and then run your binary. It will want dlls to support it, it will tell you which at each run. Copy those specific ones into your local dir and keep running until you get it all set up.

This will prove that it is working properly and that you are mixing dlls, however figuring out where you are mixing dlls, you will need to find where they are in your PATH variable.

To clear your path, just open a cmd and type set PATH="". Then type path, it should show you PATH="". Now you can run your binary from that cmd window i.e. mybinary.exe and it will pop up an error telling you which dlls are missing (1 at a time).

After you figure that out just go through with that dir command I put above, or using find figure out where all the Qt dlls are on your system and find which ones are in the PATH.

Should be nice and easy. Good luck! :)

[drmhkelley]

@ambershark
I'm pretty sure this thread has gone off-track somewhere and that I need to be considering other directions for solution.

I am quite familiar with how to keep paths and libraries straight, so lets start from scratch and consider the following.

1. I have a newly downloaded and installed Qt package, Qt 5.10.1, located in c:/Qt-5.10.1
2. PATH variable is clean, making no reference to mingw. to Qt. or anything else now required for Windows to work.
3. New copy of the widgets/widgets/lineedits example app.
4. Two .bat files, one to build the app and one to run the resulting executable.
5. The build .bat file appends the following to the clean PATH in order for "mingw32-make" to work: c:/Qt-5.10.1/Tools/mingw530_32/bin.
6. The run .bat file appends c:/Qt-5.10.1/5.10.1/mingw53_32/bin to my clean PATH variable so the Qt libs can be found. It then runs either the debug or the release version of the app.

The debug version works, the release version doesn't.

I don't see where in this process there is any opportunity for .dll confusions. If you do, please enlighten me.

[drmhkelley]

@hskoglund
Well, may not always work for qtcreator.

New installation of Qt 5.10.1, "pristine" PATH, run QtCreator, load example .pro. Build debug, works. Build release, fails.

I'm really at a loss to see where I've hidden the trap I'm tripping over.

[ambershark]

I'm pretty sure this thread has gone off-track somewhere and that I need to be considering other directions for solution.

I am quite familiar with how to keep paths and libraries straight, so lets start from scratch and consider the following.

That's good, however the error you are getting is from mixing dlls. We just need to figure out where/why they are being mixed.

4. Two .bat files, one to build the app and one to run the resulting executable.

Can you share these 2 batch files?

The debug version works, the release version doesn't.

2 different sets of dlls. This doesn't surprise me as you may have dirty release dlls but clean debug ones.

I don't see where in this process there is any opportunity for .dll confusions. If you do, please enlighten me.

Possibly in the build itself then. Maybe linking with libs from one Qt which don't match the DLL that is being used at run time. Hard to know without seeing the build process or environment.

[JKSH]

@drmhkelley said in "procedure entry point could not be located ...":

I am quite familiar with how to keep paths and libraries straight, so lets start from scratch and consider the following.

1. I have a newly downloaded and installed Qt package, Qt 5.10.1, located in c:/Qt-5.10.1
2. PATH variable is clean, making no reference to mingw. to Qt. or anything else now required for Windows to work.
3. New copy of the widgets/widgets/lineedits example app.
4. Two .bat files, one to build the app and one to run the resulting executable.
5. The build .bat file appends the following to the clean PATH in order for "mingw32-make" to work: c:/Qt-5.10.1/Tools/mingw530_32/bin.
6. The run .bat file appends c:/Qt-5.10.1/5.10.1/mingw53_32/bin to my clean PATH variable so the Qt libs can be found. It then runs either the debug or the release version of the app.

This procedure looks very solid. However, for some reason your release build is still not linking to the correct version of Qt5Core.dll. We know this because _ZN10QArrayData10deallocateEPS_jj is from the MinGW version of Qt5Core.dll.

We need to figure out if something in your system is interfering with your DLL linking process, or if your copy of Qt5Core.dll itself has been corrupted.

Questions:

• How did you install Qt 5.10.1?
• What is the size (exact number of bytes) or MD5 checksum of your copy of Qt5Core.dll? (I'm not in front of a PC at the moment, but when I get home I can check my copy. Or someone else on this forum can check)

Another check: While your debug build is running, use Process Explorer or ListDLLs (both tools by SysInternals) to see the exact paths of the DLLs used. Repeat this while the error dialog is open for your Release build. Are all of your Qt DLLs being loaded from c:/Qt-5.10.1/5.10.1/mingw53_32/bin ?

[hskoglund]

Hi, just to add to @JKSH, usually the reason why the debug version works (but not the release) is that the Qt5Cored.dll (i.e. the debug flavor) is not as widely spread/deployed as Qt5Core.dll (the release version). Qt5 is quite popular among Microsoft's developers, for example.

I've encountered the same problem (the release version tanks but not the debug) due to OneDrive from Microsoft also having copy of the Qt libraries (MSVC version, not MinGW). And OneDrive was listed in the PATH from a factory installation, so when you tried to run your MinGW Qt program it failed, because OneDrive was listed in the PATH before the MinGW Qt libraries so the wrong Qt5Core.dll was picked up :-(

You could try: in your .bat file used to run your Qt program, instead of appending ";c:/Qt-5.10.1/5.10.1/mingw53_32/bin" try prepending it so it listed in the PATH as the first directory...

[drmhkelley]

@ambershark

I'm happy to provide whatever details are useful figuring this out. Unfortunately, I don't really know how best to include some potentially relevant files. I'll just include them inline and hope that the inclusion of separator lines of stars will make it clear what I mean.

1. Here is the Makefile I use (named myMakefile)

***************************************************************************
BUILDTYPE ?= debug

ifeq ($(BUILDTYPE),standalone)
DEFINES       = -DUNICODE -D_UNICODE -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN
LIBTYPE = lib
QTTYPE = Static
else
DEFINES       = -DUNICODE -D_UNICODE -DQT_QML_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN
LIBTYPE = dll
QTTYPE = 
endif

ifeq ($(BUILDTYPE),debug)
DEBUGINFO    = -g
DEBUGFLAG    = d
OPTIMIZEFLAG = -O0
else
DEBUGINFO    = 
DEBUGFLAG    = 
OPTIMIZEFLAG = -O2
endif

QTHOME = c:/Qt-5.10.1/5.10.1/mingw53_32

MINGWHOME = c:/Qt-5.10.1/Tools/mingw530_32
MINGWINCLUDE  = $(MINGWHOME)/i686-w64-mingw32/include

####### Compiler, tools and options

CC            = gcc
CPP           = g++


CFLAGS        = -fno-keep-inline-dllexport $(DEBUGINFO) $(OPTIMIZEFLAG) -Wextra -Wall -W $(DEFINES)
LD	      = $(CPP)

INCPATH	      = -I. \
		-I/Users/Owner/Documents/Mike/src/include \
		-isystem $(QTHOME)/include \
		-isystem $(QTHOME)/include/QtPrintSupport \
		-isystem $(QTHOME)/include/QtWidgets \
		-isystem $(QTHOME)/include/QtGui \
		-isystem $(QTHOME)/include/QtCore \
		-Idebug \
		-isystem $(QTHOME)/mkspecs/win32-g++ 

MINGWINCPATH  = -I$(MINGWHOME)/lib/gcc/i686-w64-mingw32/7.1.0/include/c++ \
	-I$(MINGWHOME)/lib/gcc/i686-w64-mingw32/7.1.0/include/c++/i686-w64-mingw32 \
	-I$(MINGWHOME)/lib/gcc/i686-w64-mingw32/7.1.0/include/c++/backward \
	-I$(MINGWHOME)/lib/gcc/i686-w64-mingw32/7.1.0/include \
	-I$(MINGWHOME)/lib/gcc/i686-w64-mingw32/7.1.0/include-fixed \
	-I$(MINGWHOME)/i686-w64-mingw32/include

MOC_INCPATH   = $(BUILDTYPE)/moc_predefs.h \
		-I$(QTHOME)/mkspecs/win32-g++ \
		-I/Users/Owner/Documents/Mike/src/Qt/lineedits \
		-I/Users/Owner/Documents/Mike/src/include \
		-I$(QTHOME)/include \
		-I$(QTHOME)/include/QtPrintSupport \
		-I$(QTHOME)/include/QtWidgets \
		-I$(QTHOME)/include/QtGui \
		-I$(QTHOME)/include/QtCore \
		$(MINGWINCPATH)

CPPFLAGS = -fno-keep-inline-dllexport \
	$(DEBUGINFO) \
	$(OPTIMIZEFLAG) \
	-Wextra \
	-Wall \
	-W \
	-fexceptions \
	-mthreads \
	$(DEFINES) \
	$(INCPATH) \
	-std=c++11

LINKER = g++
LFLAGS = -Wl,-subsystem,windows -mthreads
LIBS  = -lglu32 \
	-lopengl32 \
	-lgdi32 \
	-luser32 \
	-lmingw32 \
	$(QTHOME)/lib/libqtmain$(DEBUGFLAG).a \
	-L$(QTHOME)/lib \
	$(QTHOME)/lib/libQt5PrintSupport$(DEBUGFLAG).a \
	$(QTHOME)/lib/libQt5Widgets$(DEBUGFLAG).a \
	$(QTHOME)/lib/libQt5Gui$(DEBUGFLAG).a \
	$(QTHOME)/lib/libQt5Core$(DEBUGFLAG).a

QMAKE         = $(QTHOME)/bin/qmake.exe
IDC           = idc
IDL           = midl
ZIP           = zip -r -9
DEF_FILE      = 
RES_FILE      = 
COPY          = copy /y
SED           = $(QMAKE) -install sed
COPY_FILE     = copy /y
COPY_DIR      = xcopy /s /q /y /i
DEL_FILE      = del
DEL_DIR       = rmdir
MOVE          = move
CHK_DIR_EXISTS= if not exist
MKDIR         = mkdir
INSTALL_FILE    = copy /y
INSTALL_PROGRAM = copy /y
INSTALL_DIR     = xcopy /s /q /y /i
QINSTALL        = $(QTHOME)/bin/qmake.exe -install qinstall
QINSTALL_PROGRAM = $(QTHOME)/bin/qmake.exe -install qinstall -exe

####### Output directory

OBJECTS_DIR   = $(BUILDTYPE)

####### Files

SOURCES       = window.cpp \
		main.cpp

MOC_SOURCES   = $(BUILDTYPE)/moc_window.cpp

OBJECTS       =	$(BUILDTYPE)/window.o \
		$(BUILDTYPE)/main.o

MOC_OBJECTS   = $(BUILDTYPE)/moc_window.o

QMAKE_TARGET  = lineedits
DESTDIR        = $(BUILDTYPE)/ #avoid trailing-slash linebreak
TARGET         = lineedits.exe
DESTDIR_TARGET = $(BUILDTYPE)/lineedits.exe

DEPDIR := $(BUILDTYPE)\.d
DEPFLAGS = -MT $@ -MMD -MP -MF $(DEPDIR)/$*.Td

POSTCOMPILE = move $(DEPDIR)\$*.Td $(DEPDIR)\$*.d

$(BUILDTYPE)/%.o : %.cpp
$(BUILDTYPE)/%.o : %.cpp $(DEPDIR)/%.d $(BUILDTYPE)/moc_predefs.h
	$(CPP) -c $(DEPFLAGS) $(CPPFLAGS) -o $(BUILDTYPE)/$*.o $<
	$(POSTCOMPILE)
	$(QTHOME)/bin/moc.exe $(DEFINES) --include $(MOC_INCPATH) $*.hpp -o $(BUILDTYPE)/moc_$*.cpp
	$(CPP) -c $(CPPFLAGS) -o $(BUILDTYPE)/moc_$*.o $(BUILDTYPE)/moc_$*.cpp

$(DEPDIR)/%.d: ;
.PRECIOUS: $(DEPDIR)/%.d


####### Build rules


first: all

all: $(DESTDIR_TARGET)
$(DESTDIR_TARGET):  $(OBJECTS) 
	$(LINKER) $(LFLAGS) -o $(DESTDIR_TARGET) $(OBJECTS) $(MOC_OBJECTS) $(SHAREDFLAG) $(LIBS)

clean: compiler_clean 
	-$(DEL_FILE) $(BUILDTYPE)\*.o
	-$(DEL_FILE) $(BUILDTYPE)\$(TARGET)

mocclean: compiler_moc_header_clean compiler_moc_source_clean

mocables: compiler_moc_header_make_all compiler_moc_source_make_all

check: first

benchmark: first

compiler_no_pch_compiler_make_all:
compiler_no_pch_compiler_clean:
compiler_rcc_make_all:
compiler_rcc_clean:
compiler_moc_predefs_make_all: $(BUILDTYPE)/moc_predefs.h
compiler_moc_predefs_clean:
	-$(DEL_FILE) $(BUILDTYPE)\moc_predefs.h

$(BUILDTYPE)/moc_predefs.h: $(QTHOME)/mkspecs/features/data/dummy.cpp
	g++ -fno-keep-inline-dllexport -g -Wextra -Wall -W -dM -E -o $(BUILDTYPE)/moc_predefs.h $(QTHOME)/mkspecs/features/data/dummy.cpp

compiler_moc_header_make_all: $(MOC_SOURCES)

compiler_moc_header_clean:
	-$(DEL_FILE) $(BUILDTYPE)\moc_*.cpp

compiler_moc_objc_header_make_all:
compiler_moc_objc_header_clean:
compiler_moc_source_make_all:
compiler_moc_source_clean:
compiler_uic_make_all:
compiler_uic_clean:
compiler_yacc_decl_make_all:
compiler_yacc_decl_clean:
compiler_yacc_impl_make_all:
compiler_yacc_impl_clean:
compiler_lex_make_all:
compiler_lex_clean:
compiler_clean: compiler_moc_predefs_clean compiler_moc_header_clean 

####### Compile

$(BUILDTYPE)/main.o : main.cpp $(DEPDIR)/main.d
	$(CPP) -c -MT $(BUILDTYPE)/main.o -MMD -MP -MF $(DEPDIR)/main.Td $(CPPFLAGS) -o $(BUILDTYPE)/main.o main.cpp
	move $(DEPDIR)\main.Td $(DEPDIR)\main.d

####### Install

include $(wildcard $(patsubst %,$(DEPDIR)/%.d,$(basename $(SOURCES))))
***************************************************************************

2. to make the apps, i use this .bat file

****************************************************************************set GEORGE=%PATH%
PATH=%PATH%;c:/Qt-5.10.1/Tools/mingw530_32/bin/

mingw32-make -f myMakefile BUILDTYPE=debug   all
mingw32-make -f myMakefile BUILDTYPE=release all

set PATH=%GEORGE%
****************************************************************************

3. to run the built app, I use either

****************************************************************************set GEORGE=%PATH%
PATH=%PATH%;c:/Qt-5.10.1/5.10.1/mingw53_32/bin

debug\lineedits.exe

set PATH=%GEORGE%
****************************************************************************
or
****************************************************************************set GEORGE=%PATH%
PATH=%PATH%;c:/Qt-5.10.1/5.10.1/mingw53_32/bin

release\lineedits.exe

set PATH=%GEORGE%
**********************************************************************

4. the output from the build process is

**********************************************************************
C:\Users\Owner\Documents\Mike\src\Qt\lineedits>makeall

C:\Users\Owner\Documents\Mike\src\Qt\lineedits>set GEORGE=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Users\Owner\Documents\Mike\python\MainInstallation\Scripts\;C:\Users\Owner\Documents\Mike\python\MainInstallation\;C:\Users\Owner\AppData\Local\Microsoft\WindowsApps;

C:\Users\Owner\Documents\Mike\src\Qt\lineedits>PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Users\Owner\Documents\Mike\python\MainInstallation\Scripts\;C:\Users\Owner\Documents\Mike\python\MainInstallation\;C:\Users\Owner\AppData\Local\Microsoft\WindowsApps;;c:/Qt-5.10.1/Tools/mingw530_32/bin/

C:\Users\Owner\Documents\Mike\src\Qt\lineedits>mingw32-make -f myMakefile BUILDTYPE=debug   all
g++ -fno-keep-inline-dllexport -g -Wextra -Wall -W -dM -E -o debug/moc_predefs.h c:/Qt-5.10.1/5.10.1/mingw53_32/mkspecs/features/data/dummy.cpp
g++ -c -MT debug/window.o -MMD -MP -MF debug\.d/window.Td -fno-keep-inline-dllexport -g -O0 -Wextra -Wall -W -fexceptions -mthreads -DUNICODE -D_UNICODE -DQT_QML_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN -I. -I/Users/Owner/Documents/Mike/src/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtPrintSupport -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtWidgets -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtGui -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtCore -Idebug -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/mkspecs/win32-g++  -std=c++11 -o debug/window.o window.cpp
move debug\.d\window.Td debug\.d\window.d
        1 file(s) moved.
c:/Qt-5.10.1/5.10.1/mingw53_32/bin/moc.exe -DUNICODE -D_UNICODE -DQT_QML_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN --include debug/moc_predefs.h -Ic:/Qt-5.10.1/5.10.1/mingw53_32/mkspecs/win32-g++ -I/Users/Owner/Documents/Mike/src/Qt/lineedits -I/Users/Owner/Documents/Mike/src/include -Ic:/Qt-5.10.1/5.10.1/mingw53_32/include -Ic:/Qt-5.10.1/5.10.1/mingw53_32/include/QtPrintSupport -Ic:/Qt-5.10.1/5.10.1/mingw53_32/include/QtWidgets -Ic:/Qt-5.10.1/5.10.1/mingw53_32/include/QtGui -Ic:/Qt-5.10.1/5.10.1/mingw53_32/include/QtCore -Ic:/Qt-5.10.1/Tools/mingw530_32/lib/gcc/i686-w64-mingw32/7.1.0/include/c++ -Ic:/Qt-5.10.1/Tools/mingw530_32/lib/gcc/i686-w64-mingw32/7.1.0/include/c++/i686-w64-mingw32 -Ic:/Qt-5.10.1/Tools/mingw530_32/lib/gcc/i686-w64-mingw32/7.1.0/include/c++/backward -Ic:/Qt-5.10.1/Tools/mingw530_32/lib/gcc/i686-w64-mingw32/7.1.0/include -Ic:/Qt-5.10.1/Tools/mingw530_32/lib/gcc/i686-w64-mingw32/7.1.0/include-fixed -Ic:/Qt-5.10.1/Tools/mingw530_32/i686-w64-mingw32/include window.hpp -o debug/moc_window.cpp
g++ -c -fno-keep-inline-dllexport -g -O0 -Wextra -Wall -W -fexceptions -mthreads -DUNICODE -D_UNICODE -DQT_QML_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN -I. -I/Users/Owner/Documents/Mike/src/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtPrintSupport -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtWidgets -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtGui -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtCore -Idebug -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/mkspecs/win32-g++  -std=c++11 -o debug/moc_window.o debug/moc_window.cpp
g++ -c -MT debug/main.o -MMD -MP -MF debug\.d/main.Td -fno-keep-inline-dllexport -g -O0 -Wextra -Wall -W -fexceptions -mthreads -DUNICODE -D_UNICODE -DQT_QML_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN -I. -I/Users/Owner/Documents/Mike/src/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtPrintSupport -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtWidgets -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtGui -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtCore -Idebug -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/mkspecs/win32-g++  -std=c++11 -o debug/main.o main.cpp
move debug\.d\main.Td debug\.d\main.d
        1 file(s) moved.
g++ -Wl,-subsystem,windows -mthreads -o debug/lineedits.exe debug/window.o debug/main.o debug/moc_window.o  -lglu32 -lopengl32 -lgdi32 -luser32 -lmingw32 c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libqtmaind.a -Lc:/Qt-5.10.1/5.10.1/mingw53_32/lib c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5PrintSupportd.a c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5Widgetsd.a c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5Guid.a c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5Cored.a

C:\Users\Owner\Documents\Mike\src\Qt\lineedits>mingw32-make -f myMakefile BUILDTYPE=release all
g++ -fno-keep-inline-dllexport -g -Wextra -Wall -W -dM -E -o release/moc_predefs.h c:/Qt-5.10.1/5.10.1/mingw53_32/mkspecs/features/data/dummy.cpp
g++ -c -MT release/window.o -MMD -MP -MF release\.d/window.Td -fno-keep-inline-dllexport  -O2 -Wextra -Wall -W -fexceptions -mthreads -DUNICODE -D_UNICODE -DQT_QML_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN -I. -I/Users/Owner/Documents/Mike/src/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtPrintSupport -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtWidgets -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtGui -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtCore -Idebug -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/mkspecs/win32-g++  -std=c++11 -o release/window.o window.cpp
move release\.d\window.Td release\.d\window.d
        1 file(s) moved.
c:/Qt-5.10.1/5.10.1/mingw53_32/bin/moc.exe -DUNICODE -D_UNICODE -DQT_QML_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN --include release/moc_predefs.h -Ic:/Qt-5.10.1/5.10.1/mingw53_32/mkspecs/win32-g++ -I/Users/Owner/Documents/Mike/src/Qt/lineedits -I/Users/Owner/Documents/Mike/src/include -Ic:/Qt-5.10.1/5.10.1/mingw53_32/include -Ic:/Qt-5.10.1/5.10.1/mingw53_32/include/QtPrintSupport -Ic:/Qt-5.10.1/5.10.1/mingw53_32/include/QtWidgets -Ic:/Qt-5.10.1/5.10.1/mingw53_32/include/QtGui -Ic:/Qt-5.10.1/5.10.1/mingw53_32/include/QtCore -Ic:/Qt-5.10.1/Tools/mingw530_32/lib/gcc/i686-w64-mingw32/7.1.0/include/c++ -Ic:/Qt-5.10.1/Tools/mingw530_32/lib/gcc/i686-w64-mingw32/7.1.0/include/c++/i686-w64-mingw32 -Ic:/Qt-5.10.1/Tools/mingw530_32/lib/gcc/i686-w64-mingw32/7.1.0/include/c++/backward -Ic:/Qt-5.10.1/Tools/mingw530_32/lib/gcc/i686-w64-mingw32/7.1.0/include -Ic:/Qt-5.10.1/Tools/mingw530_32/lib/gcc/i686-w64-mingw32/7.1.0/include-fixed -Ic:/Qt-5.10.1/Tools/mingw530_32/i686-w64-mingw32/include window.hpp -o release/moc_window.cpp
g++ -c -fno-keep-inline-dllexport  -O2 -Wextra -Wall -W -fexceptions -mthreads -DUNICODE -D_UNICODE -DQT_QML_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN -I. -I/Users/Owner/Documents/Mike/src/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtPrintSupport -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtWidgets -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtGui -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtCore -Idebug -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/mkspecs/win32-g++  -std=c++11 -o release/moc_window.o release/moc_window.cpp
g++ -c -MT release/main.o -MMD -MP -MF release\.d/main.Td -fno-keep-inline-dllexport  -O2 -Wextra -Wall -W -fexceptions -mthreads -DUNICODE -D_UNICODE -DQT_QML_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN -I. -I/Users/Owner/Documents/Mike/src/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtPrintSupport -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtWidgets -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtGui -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/include/QtCore -Idebug -isystem c:/Qt-5.10.1/5.10.1/mingw53_32/mkspecs/win32-g++  -std=c++11 -o release/main.o main.cpp
move release\.d\main.Td release\.d\main.d
        1 file(s) moved.
g++ -Wl,-subsystem,windows -mthreads -o release/lineedits.exe release/window.o release/main.o release/moc_window.o  -lglu32 -lopengl32 -lgdi32 -luser32 -lmingw32 c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libqtmain.a -Lc:/Qt-5.10.1/5.10.1/mingw53_32/lib c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5PrintSupport.a c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5Widgets.a c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5Gui.a c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5Core.a

C:\Users\Owner\Documents\Mike\src\Qt\lineedits>set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Users\Owner\Documents\Mike\python\MainInstallation\Scripts\;C:\Users\Owner\Documents\Mike\python\MainInstallation\;C:\Users\Owner\AppData\Local\Microsoft\WindowsApps;

C:\Users\Owner\Documents\Mike\src\Qt\lineedits>
**********************************************************************

[~ambershark]: added code tags to make it easier to read.

[drmhkelley]

@JKSH
I installed Qt 5.10.1 using the Qt on-line installer qt-unified-windows-x86-3.0.2-online.exe

I don't know how where to find the MD5 checksums, but here is some info about Qt5Core and Qt5Widgets, both of which are relevant.

-rw-rw-rw- 1 Owner None 121510926 03-10 10:20 Qt5Cored.dll
-rw-rw-rw- 1 Owner None 6180864 03-10 10:19 Qt5Core.dll
-rw-rw-rw- 1 Owner None 167921455 02-09 04:36 Qt5Widgetsd.dll
-rw-rw-rw- 1 Owner None 6232576 02-09 04:36 Qt5Widgets.dll

Sorry, I don't understand your request about "process explorer", but hopefully the info I provided in my prior post has equivalent information.

Also, your info about OneDrive is interesting, but I'm not sure it is relevant to my situation.

However, I think I tested the essence of you suggesting by modifying the .bat files I submitted earlier. Instead of appending the relevant mingw or Qt folders to my PATH, I simply set PATH to just those locations.

Behavior was the same.

If this isn't clear, I will be happy to make it more explicit.

[ambershark]

@drmhkelley So the weird thing is it looks (based on your build log) that you are building statically. So there shouldn't even be any dll loading or entry point issues. That makes it even more suspicious.

Can you try this:

1. Put your application in it's own standalone dir, just the lineedits.exe
2. in a cmd, set PATH="" then lineedits.exe

What does it show on the screen then?

[ambershark]

@drmhkelley Oh and here is a link to the listdlls tool that @jksh mentioned. Which should help show what dlls are loaded when your debug build is running and when your release build is running. This will help us figure out what is going on.

https://docs.microsoft.com/en-us/sysinternals/downloads/listdlls

[JKSH]

@drmhkelley said in "procedure entry point could not be located ...":

@JKSH
I installed Qt 5.10.1 using the Qt on-line installer qt-unified-windows-x86-3.0.2-online.exe

I don't know how where to find the MD5 checksums, but here is some info about Qt5Core and Qt5Widgets, both of which are relevant.

-rw-rw-rw- 1 Owner None 121510926 03-10 10:20 Qt5Cored.dll
-rw-rw-rw- 1 Owner None 6180864 03-10 10:19 Qt5Core.dll
-rw-rw-rw- 1 Owner None 167921455 02-09 04:36 Qt5Widgetsd.dll
-rw-rw-rw- 1 Owner None 6232576 02-09 04:36 Qt5Widgets.dll

I can confirm that my DLLs for the MinGW build of Qt 5.10.1 are exactly those sizes too. Your installation looks sound.

Sorry, I don't understand your request about "process explorer"

Process Explorer and ListDLLs are two tools by SysInternals that are very helpful with investigating DLL linkage issues:

• https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
• https://docs.microsoft.com/en-us/sysinternals/downloads/listdlls

Process Explorer has a decent GUI; it's easier for a newcomer to discover its functionality.

ListDLLs is a console application and prints to stdout, which makes it easier to collect data to post on a forum.

but hopefully the info I provided in my prior post has equivalent information.

What you have provided previously is not quite equivalent. They show your intentions and instructions for your system, but they don't show what your system actually does.

Do try Process Explorer or ListDLLs. Even if all of our attempts so far have missed the mark, you might spot a vital clue by looking through their outputs. In particular, see if these tools show any difference between your Debug build and your Release build (aside from the fact that the Debug DLLs have a -d suffix).

Also, your info about OneDrive is interesting, but I'm not sure it is relevant to my situation.

If there is something in your system that's "injecting" the wrong DLL into your application Process Explorer or ListDLLs will reveal the culprit.

P.S. Credit where credit is due: @hskoglund is the one who highlighted this possibility.

However, I think I tested the essence of you suggesting by modifying the .bat files I submitted earlier. Instead of appending the relevant mingw or Qt folders to my PATH, I simply set PATH to just those locations.

My initial feeling is that setting the PATH to just those locations should have done the trick... yet somehow your issue remains.

I'm still convinced that you somehow have a DLL linkage issue. Process Explorer or ListDLLs will prove conclusively if I'm right or wrong.

@drmhkelley said in "procedure entry point could not be located ...":

ifeq ($(BUILDTYPE),standalone)
...
LIBTYPE = lib
QTTYPE = Static
else
...
LIBTYPE = dll
QTTYPE = 
endif

I'm not familiar with these options. What do they do? Which set do you use?

[drmhkelley]

@ambershark, @JKSH
For some reason, this site will only let me post once every 5 minutes, so I'm bundling this response to both of your comments.

1. ambershark, what in the log indicates a static build? I have done that in the past and intend to do it in the future, but I don't at present have a static build Qt. Last time I had that was for Qt 4.x. So if my basic build process has gone awry, I want to fix that anyway.

2. running the executable with a null path was a good idea and may provide insight, but I don't yet know what to make of it. For the debug version, I get errors that Qt5Cored.dll, Qt5Widgetsd.dll, Qt5Guid.dll, and libgcc_s_dw2_1.dll are missing. The release version is different, missing libgcc_s_dw2-1.dll and libstdc++-6.dll, but no reference (?yet?) to the Qt5 libs.

3. Both, thanks for the links to process-explorer and listdlls - I'm not familiar with these tools but it sounds like I could be putting them to good use. I may or may have time today to use them but will do so and report back.

4. jksh, your comment about the OneDrive example hits what has become a major concern for me. Whatever problem I'm bumping into really seems to be independent of Qt. The two tools you've suggested should help ferret that out.

5. The snippet from the Makefile is a holdover from a prior attempt to build statically-linked apps. I never quite got that working reliably (some apps worked, some didn't, never quite figured out the differences and gave up on it for now). The LIBTYPE and QTYPE variables would be used to assemble the correct path name for the relevant libraries, completely analogous to how DEBUGFLAG and other variables are used. Presently, I'm only building a debug and a release package - standalone would by my statically-linked version of release. It is the second set is presently used, LIBTYPE=dll and QTYPE="".

[drmhkelley]

@JKSH
Well, ProcessExplorer seems to have provided an important clue - thanks a bazillion for the pointer.

Seems that the debug version finds the Qt5 libs in their expected location: c:/Qt-5.10.1/Tools/mingw530_32\bin. Unfortunately, the release version does not. The appear to have been found in: C:\Users\Owner\AppData\Local\Microsoft\OneDrive\18.025.0204.0009

Without this new tool, I would likely never have found that clue.

Couple of obvious followup questions.

1. Can I safely just delete those files from AppData?
2. Any clue how they might have gotten there - if they got there once they'll probably show up again.

This may also answer my question to ambershark about a static build. My makefile (and this part I copied from the compile log in Qt Creator) explicitly links libQt5Core.a, etc. I had searched for all instances of those libraries, but not for Qt5Core.dll, etc. So I never saw found these files. I've never really understood the relationship between the libxxxx.a and xxxx.dll libraries, but clearly need to understand that a bit more.

[drmhkelley]

@ambershark, @JKSH

FYI, I temporarily (probably permanently) moved the bogus .dlls out of the AppData folder. That seems to have resolved the failure of the release version of my apps.

I will consider this issue resolved, but would appreciate any follow-on comments you might have on how they got there and any obvious confusions I have displayed about the .a vs .dll libraries.

[ambershark]

@drmhkelley Lol @hskoglund said:

I've encountered the same problem (the release version tanks but not the debug) due to OneDrive from Microsoft also having copy of the Qt libraries

He totally called it.

Anyway, as we all said it was most definitely an issue of mixed Qt dlls. We've all seen it a bunch with similar errors. We just needed to find out where you were getting the bad dlls from. That is why I suggested clearing your PATH to test.

ambershark, what in the log indicates a static build? I have done that in the past and intend to do it in the future, but I don't at present have a static build Qt. Last time I had that was for Qt 4.x. So if my basic build process has gone awry, I want to fix that anyway.

So all of your linking lines have .a at the end. Those are static libs. Here's an example from your build log.

g++ -Wl,-subsystem,windows -mthreads -o release/lineedits.exe release/window.o release/main.o release/moc_window.o  -lglu32 -lopengl32 -lgdi32 -luser32 -lmingw32 c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libqtmain.a -Lc:/Qt-5.10.1/5.10.1/mingw53_32/lib c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5PrintSupport.a c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5Widgets.a c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5Gui.a c:/Qt-5.10.1/5.10.1/mingw53_32/lib/libQt5Core.a

All of your Qt is linked to static i.e. libQt5Core.a as opposed to libQt5Core.so or libQt5Core.dll.

running the executable with a null path was a good idea and may provide insight, but I don't yet know what to make of it. For the debug version, I get errors that Qt5Cored.dll, Qt5Widgetsd.dll, Qt5Guid.dll, and libgcc_s_dw2_1.dll are missing. The release version is different, missing libgcc_s_dw2-1.dll and libstdc++-6.dll, but no reference (?yet?) to the Qt5 libs.

This is because without a PATH it can't find your dlls. This would be equivalent to installing it on a customer/user machine. You need to provide all the supporting files for it to work. I detailed that process in my post above.

Both, thanks for the links to process-explorer and listdlls - I'm not familiar with these tools but it sounds like I could be putting them to good use. I may or may have time today to use them but will do so and report back.

They are AWESOME tools! Now that you know about sysinternals you will be able to find a lot of weird stuff with your system and programs in the future. They help a ton in diagnosing things.

The snippet from the Makefile is a holdover from a prior attempt to build statically-linked apps. I never quite got that working reliably (some apps worked, some didn't, never quite figured out the differences and gave up on it for now). The LIBTYPE and QTYPE variables would be used to assemble the correct path name for the relevant libraries, completely analogous to how DEBUGFLAG and other variables are used. Presently, I'm only building a debug and a release package - standalone would by my statically-linked version of release. It is the second set is presently used, LIBTYPE=dll and QTYPE="".

It seems to be "working" now since it looks like your build output as covered above is all static linking to Qt.

Honestly I would recommend using cmake or qmake instead of makefiles. Makefiles are really rough. I've used them for many many years but once I got into Qt and qmake I haven't touched them since. I'm now a cmake user and love it. qmake or cmake will make your build process much easier and much easier to maintain and understand. Cmake is the more powerful and flexible of the 2 and isn't locked into just Qt like qmake is. However it is the way more complicated of the 2. Qmake is nice and easy and will make your makefiles for you.

Anyway, glad you finally got it fixed! :D

[ambershark]

@drmhkelley said in "procedure entry point could not be located ...":

Couple of obvious followup questions.

Can I safely just delete those files from AppData?
Any clue how they might have gotten there - if they got there once they'll probably show up again.

This may also answer my question to ambershark about a static build. My makefile (and this part I copied from the compile log in Qt Creator) explicitly links libQt5Core.a, etc. I had searched for all instances of those libraries, but not for Qt5Core.dll, etc. So I never saw found these files. I've never really understood the relationship between the libxxxx.a and xxxx.dll libraries, but clearly need to understand that a bit more.

Sorry didn't address these in my last post ...

1. You should not delete Qt from AppData. That is required for OneDrive usage. You could remove that from your PATH though. Or you could uninstall OneDrive. If you deleted Qt's dlls from there though it would no longer work. So you have to determine whether or not you need OneDrive before you do that.

2. They got there because OneDrive was developed with Qt and those are the distributed supporting dlls. They however don't match the version you were trying to use. :) (Assumptions here I'm not 100% sure on what was used by MS to write OneDrive).

Finally, so .a files are "archives" which are groups of object files (.o). This is a linux/osx thing mostly, but because mingw uses that same linuxy technology they use it too. It is basically a static library (archive). A .so (shared object) or .dll (dynamic link library) are the dynamic (non-static) libs.

From the looks of it, if you can't actually find things like libQt5Core.dll or libQt5Core.so in your Qt install, then you probably have a static only install of Qt. Just guessing here though. Usually you have to explicitly build Qt for static like that because using it statically is not covered under the LGPL licenses. You have to have a commercial license to link statically.

Oh and I upvoted some of your posts, which should let you post more than once every 5 min. :)

[drmhkelley]

@ambershark
Many thanks. But I'm back to confused. This confusion may be off-topic for this thread - if so, sorry.

1. I haven't a clue how the AppData gets into my PATH. I set the Path variable through the Windows "System Properties" dialog. I've always been curious why a command window has additional paths added on top of that. Specifically, I get two paths for python libraries and one named C:\Users\Owner\AppData\Local\Microsoft\WindowsApps. I knew there wasn't anything in there and didn't worry about it. Is my presumption correct that this is just a placeholder for anything in the Microsoft directory?

2. Even so, the Qt path is listed earlier in PATH than the AppData directory, so I'll need to figure that little detail out.

3. I'll fully admit to significant confusion around static vs dynamic linking. I used the .a libraries because that's what Qt Creator was using. But the apps certainly don't seem to be statically linked - otherwise I would expect errors about missing .dlls.

4. I had missed that important detail about static linking violating the open source license agreement. I had intended to do that for personal convenience, since I use these apps on a number of different systems, not all of which grant me full administrative privileges. Going forward, I'll just stick with dynamic linking and be more explicit about which libraries I have to carry around.

5. I appreciate your perspective on cmake and qmake. They've been on my list to explore, but that list is very much longer than the amount of time I have to dedicate to what is really just a hobby. So until I find the appropriate document or example that shows me at a glance what I need to know about either, I'll stick with make, with which I'm pretty comfortable - despite limitations.

6. Given how much effort it was to create the static build of Qt 4.x, I'll be really surprised to learn that I have a "static" build of Qt5.10.1. Do you have a comparable Qt Creator build log so I can see what that looks like? Do you know where in the Creator configuration I would specify stuff like that? I've always used Creator "out of the box" and don't have a clue where those details get set.

[drmhkelley]

@ambershark
BTW - Do you know what part of OneDrive should fail without the Qt libs? Superficially, it appears to work just fine without them. But I haven't been exercising it very hard so far.

[ambershark]

@drmhkelley said in "procedure entry point could not be located ...":

@ambershark
Many thanks. But I'm back to confused. This confusion may be off-topic for this thread - if so, sorry.

1. I haven't a clue how the AppData gets into my PATH. I set the Path variable through the Windows "System Properties" dialog. I've always been curious why a command window has additional paths added on top of that. Specifically, I get two paths for python libraries and one named C:\Users\Owner\AppData\Local\Microsoft\WindowsApps. I knew there wasn't anything in there and didn't worry about it. Is my presumption correct that this is just a placeholder for anything in the Microsoft directory?

Good question here. I'm not a big windows user so I don't have an answer for this. It sounds like the OneDrive stuff wasn't even in your path. Which definitely makes me wonder how it was picking up those Qt dlls.

2. Even so, the Qt path is listed earlier in PATH than the AppData directory, so I'll need to figure that little detail out.

From what I saw in your build, you PATH=%PATH%;c:/Qt-5.10.1/Tools/mingw530_32/bin/ So it would actually put Qt at the end and not the beginning of the path. If you reversed that and did PATH=c:/Qt-5.10.1/Tool/mingw530_32/bin;%PATH% and still had an issue that would be much more confusing.

Normally DLLs would be grabbed from the first place they were found. So if your Qt path was before the OneDrive one then it should have used yours. If it wasn't that is very confusing as to what OneDrive is doing that causes that.

3. I'll fully admit to significant confusion around static vs dynamic linking. I used the .a libraries because that's what Qt Creator was using. But the apps certainly don't seem to be statically linked - otherwise I would expect errors about missing .dlls.

This is a good point. There are also stub libs that are static. It could be that is what those .a libs are. Although I thought (again not a huge windows user here) that stub libs were a Visual Studio thing and had no place in mingw. I could be wrong, but that is my only guess since it does indeed seem like it is not statically linked but the command line is saying it is. It's also possible you only statically linked some of the libs and then it is pulling dlls for the rest. My money is more on stub libs though and I just didn't realize that is how mingw works too. Again I just don't do enough development in Windows to notice this kind of stuff regularly. And my most recent windows stuff is all MSVC (yuck!).

4. I had missed that important detail about static linking violating the open source license agreement. I had intended to do that for personal convenience, since I use these apps on a number of different systems, not all of which grant me full administrative privileges. Going forward, I'll just stick with dynamic linking and be more explicit about which libraries I have to carry around.

If it's for personal use I wouldn't worry about it. It's more a distribution requirement. I'm sure it is against the license even for personal use but honestly nobody is going to care or ever even notice since you're the only one using that app. Just be careful if you ever distribute it. Oh and standard disclaimer: I'm not a lawyer! :)

5. I appreciate your perspective on cmake and qmake. They've been on my list to explore, but that list is very much longer than the amount of time I have to dedicate to what is really just a hobby. So until I find the appropriate document or example that shows me at a glance what I need to know about either, I'll stick with make, with which I'm pretty comfortable - despite limitations.

Oh if you are comfortable with autotools and makefiles, by all means go for it. They are just about 10x harder than the more modern alternatives. Qmake is very very easy. You could possibly get a working project just by running qmake -project to generate a pro file for you. Then modify that to include the components you use, i.e. QT += core widgets gui and it should be good to go. You then just run qmake and it generates a Makefile for you. You don't ever modify that makefile though so you never have to deal with the complex relationships makefiles use in their objects and builds.

6. Given how much effort it was to create the static build of Qt 4.x, I'll be really surprised to learn that I have a "static" build of Qt5.10.1. Do you have a comparable Qt Creator build log so I can see what that looks like? Do you know where in the Creator configuration I would specify stuff like that? I've always used Creator "out of the box" and don't have a clue where those details get set.

Chances of you having a static build are almost 0 at this point. Which means my guess on the .a files being stub libs is more confirmed here. If I had qt creator I'd check for you but I don't use it, I prefer CLion, SlickEdit, and even just raw vim for development. Someone else can chime in, but I'm betting I was just wrong on the static libs and that they are interface/stub libs. Sorry for confusing you. :)

[viktorcsimma]

@hskoglund You have saved my day; they really were from the QtCreator folder... after replacing them with the ones from the Qt bin folder, it was fine. Thank you:)