[f5soh]

The usual method to install a downloaded package will be like this :

Code: [Select]

pacman -U mingw-w64-i686-openssl-1.0.2.p-1-any.pkg.tar.xz
No need Winzip

[karla]

Oh okay, I better do that then.
What shell shall I start then doing that?

D:\msys32\msys2_shell.cmd -mingw32

D:\msys32\msys2_shell.cmd -msys

Does it matter, which one?

[f5soh]

mingw-w64-i686-openssl

mingw + i686 = mingw32

[karla]

Okay.

When I run it now, it complains that several file are already existing.
Probably since I already have copied all files on to the mingw32.

So maybe I just let it be for now, since it seems to be able to successfully compile and build the whole package with - make package.

Thanks you.

Code: [Select]

mingw-w64-i686-openssl: /mingw32/share/man/man3/X509_STORE_CTX_set_chain.3ssl.gz exists in filesystem
mingw-w64-i686-openssl: /mingw32/share/man/man3/X509_STORE_CTX_trusted_stack.3ssl.gz exists in filesystem
Errors occurred, no packages were upgraded.

ABC@DESKTOP-CDUNNSL MINGW32 ~
#


[karla]

My 32bit version installation worked fine for a while,
but then got corrupt and no longer want to start any wingw32 shells, only Msys2 shells.

So I have made new efforts to insall the 64 bit version, that should be suitable for my Win10 64 bit version OS, and get a proper local dev environment.

I have been doning this whole process
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/14876735/Windows+Building+and+Packaging
several times, so I am getting familiar to it.

And also changing the known broken things with
1.

Code: [Select]

pacman -S mingw-w64-i686-python2 2.

Code: [Select]

GCS_WITH_OSGEARTH := 0
and getting the 64 bit bit version of this file to the mingw64/bin directory
3.

Code: [Select]

/bin/ssleay32.dll
but when i do 'make package' it result in this error, after more than 1h of compilation:

Code: [Select]

...

D:/msys64/mingw64/bin/python D:/msys64/home/ABC/librepilot/make/copy_dependencies.py --dest "D:/msys64/home/ABC/librepilot/build/librepilot-gcs_release/bin" --files "D:/msys64/mingw64/bin/Qt5Qml.dll" --excludes OPENGL32.DLL > "D:/msys64/home/ABC/librepilot/build/librepilot-gcs_release/deps/Qt5Qml.dll.deps"
cp -f "D:/msys64/mingw64/bin/ssleay32.dll" "D:/msys64/home/ABC/librepilot/build/librepilot-gcs_release/bin/ssleay32.dll"
mingw32-make[2]: *** No rule to make target 'D:/msys64/mingw64/bin/libeay32.dll', needed by 'D:/msys64/home/ABC/librepilot/build/librepilot-gcs_release/bin/libeay32.dll'.  Stop.
mingw32-make[2]: Leaving directory 'D:/msys64/home/ABC/librepilot/build/librepilot-gcs_release'
mingw32-make[1]: *** [Makefile:83: sub-copydata-pro-make_first-ordered] Error 2
mingw32-make[1]: Leaving directory 'D:/msys64/home/ABC/librepilot/build/librepilot-gcs_release'
mingw32-make: *** [Makefile:308: gcs] Error 2

ABC@DESKTOP-CDUNNSL MINGW64 ~/librepilot
$

Any suggestion what to try?
... much appretiated.

[TheOtherCliff]

It's a tiny bit suspicious that it is looking for a 32 bit library in a 64 bit directory.  Maybe install both 32 and 64 bit?  No.  I am pretty sure that GCS is still a 32 bit exe, so I would think you need the 32 bit version of OpenSSL, not the 64 bit version?

I would scan all my drives for ssleay32.dll and examine D:/msys64/home/ABC/librepilot/make/copy_dependencies.py to see how it determines where is is installed.  Maybe an environment variable.

You mentioned copying it to /bin/ssleay32.dll.  I guess you meant copying it to
D:/msys64/mingw64/bin/ssleay32.dll
which is where the error message says it is trying to find it.

My very old msys32 setup has it at msys32/mingw32/bin/ssleay32.dll so I am running everything 32 bit (on 64 bit Linux with Wine).

[karla]

yes, I copied the file to that directory.
But isnt the error msg complaining about another file - libeay32.dll ?

I will try to add that file.


about the 32 vs 64 bits,
I was thinking you can install any of those two MinGW versions on your developer machine but complile and build both 32 and 64 bit software packages. The 'make' command we use for Librepilot, regardless of installation is always

Code: [Select]

Every time you need a 'make' command you need to run the mingw version of make, which is `mingw32-make`I just assumed we always make 32 bit LP software (on windows).
The flight controllers are 32 bit right? so it makes some sense.
But since I am working on a 64 bit OS there should be some advantage with that over 32? Maybe faster compilation?
Maybe i got it wrong.

[TheOtherCliff]

You are right.  Sorry.

The error seems to be saying that it can't find "D:/msys64/mingw64/bin/libeay32.dll"

Google says that libeay32.dll is another OpenSSL file.  Whether you get it when installing 64 bit or not, I don't know, so I don't know if you need to install just 64 bit or both 32 and 64.

Does libeay32.dll exist in that location?  Maybe find all the versions of that file and make sure they are the same and copy it to "D:/msys64/mingw64/bin" ?  That seems like a hack, but may fix it.

( I was wanting to build Windows packages under Linux.  About three years ago I was advised to install and use the 32 bit versions (mingw and msys), and that even for that, the install program (maybe just under Linux and Wine) didn't work right and you had to copy or unpack the directory structure by hand rather than running the install program.  And to use mingw not msys once it was all installed?  Since then, I have upgraded my Linux and my Mingw doesn't work right now. )

[karla]

Haha don't be sorry my friend

I am very happy
after adding that file it compiled the package

Code: [Select]

Total size:                108396090 / 382084389 bytes (28.3%)

1 warning:
  Generating version information for language "0000-TradChinese" without standard key "FileVersion"

ABC@DESKTOP-CDUNNSL MINGW64 ~/librepilot
$

I am back in business

[karla]

I do see the build is dirty
I assume that is because the change I made to
osgearth from 1 to 0


Could that be plausible?

Should I worry?

[TheOtherCliff]

Yes.  If you change any file that git knows about then it is dirty.  The build scripts ask git whether it is dirty or not when deciding what the file name should be.

Glad you got it working. 

[karla]

Got it.
That git guy is not easily fooled right.
Not sure that is good or bad
Thanks a lot!

[TheOtherCliff]

I would guess that there is an environment variable that you could set while building, that has the same effect as setting osgearth to 0 in the build scripts.

Why do you want osgearth disabled?  Does it try to load even if osge is not actually configured to run on e.g. the flight page?

[karla]

Oh, its not that I desire to disable it:)
Its another fix mentioned by filnet, at beginning of this thread, to sort another build error.

...
The other compilation error is due to a recent upgrade of osg to version 3.6.1.
This broke osgEarth. I'll get it sorted out.
In the meantime, you can edit the LP Makefile and change the line 146 from:

Code: [Select]

GCS_WITH_OSGEARTH := 1to

Code: [Select]

GCS_WITH_OSGEARTH := 0