Windows application compiled on msys64 does not start

advanced
#1

I compile application under msis64 fresh version, openframe version 0.11.2. I’m running the application from mingw64 (“make RunRelease”). The application starts normally.
I copy the necessary libraries (“make copy_dlls”) and run the app from windows.The application crashes without saying anything. By trial and error, I figured out that if I erase the libcrypto-3-x64.dll library, the application starts normally. I found all copies of the library on the disk, tried to substitute the library. Still won’t launch. I erase - it starts. Perhaps my application picks up this library somewhere else, it in turn uses other libraries.

It won’t work on another computer either. If I delete libcrypto-3-x64.dll, it swears that it is not there.

#2

Hi @Igor_Boolygin welcome!!

Can you try out 0.12.0 Release Candidate.
There is a good chance this is fixed in the upcoming release.

Adding @oxillo in case this is something he’s run into.

Thanks!!
Theo

#3

Hello @Igor_Boolygin,

I’ve never enccountered such case.
libcrypto generally comes as a dependency of libcurl.
in a mingw64 shell, you may run ntldd to see which dll your application is using :

cd <yourapp>/bin
ntldd --recursive <yourapp>.exe

that should result in a long list

	ADVAPI32.dll => C:\Windows\SYSTEM32\ADVAPI32.dll (0x0000019390160000)
	 ntdll.dll => C:\Windows\SYSTEM32\ntdll.dll (0x0000019390c20000)
	 KERNELBASE.dll => C:\Windows\SYSTEM32\KERNELBASE.dll (0x0000019390c20000)
	  ext-ms-win-advapi32-registry-l1-1-0.dll => not found
	...
	libcurl-4.dll (0x0000019390160000)
	 libbrotlidec.dll (0x000001938ff50000)
	  libbrotlicommon.dll (0x0000019390b80000)
	 libcrypto-3-x64.dll => C:\N\msys64\mingw64\bin\libcrypto-3-x64.dll (0x0000019390f00000)
	...

The first dlls are Windows system dlls.
libcurl is found in the bin directory (due to make copy_dlls)
libcrypto is used from my mingw64 installation (I’ve voluntarily deleted it from bin folder for illustration purpose !)

I hope it can help you to find the root cause.

#4

guessed to look in the mingw64 shell. I saw the following message there:

terminate called after throwing an instance of ‘Poco::Crypto::CryptoException’
what(): Crypto Exception

#5

It was possible to compile in version 12. Here are the errors:

  1. missing link to json.http.

add to config.make file

PROJECT_CFLAGS=-I/opt/of12/libs/json/include

  1. Swears at the definition of byte in the file:
    mingw64/include/rpcnd.h:63

the problem is that 12 openframework compiles with gcc++17 (in version 11 - gcc++14 (inaccurately)). Version 17 of the compiler has its own std::byte.

So far changed the definition of byte as:
typedef unsigned char byte_17;

and changed its application in files:
objidl.h, wtypesbase.h, objidlbase.h, wtypes.h, oaidl.h

  1. Swears at the absence of the description ofLogVerbose in the line
    49:ofLogVerbose(“ImageUtils::loadHeader”) << "Loading full pixels, may be slow: " << _path;

File: C:\msys64\opt\of12\addons\ofxIO\libs\ofxIO\src\ImageUtils.cpp

cured by inserting "#include “ofMain.h” into the file
C:\msys64\opt\of12\addons\ofxIO\libs\ofxIO\include\ofx\IO\ImageUtils.h

1 Like
#6

Hello,

ofMain.h includes a “using namespace std;” that causes the conflict.

do not include ofMain.h but only the individual needed .h files.