libtool could not find -lwinmm and produced the following message:
*** Warning: linker path does not have real file for library -lwinmm.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libwinmm and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib/mxe/usr/lib/gcc/i686-w64-mingw32.shared/5.2.0/../../../../i686-w64-mingw32.shared/lib//libwinmm.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
After that, it created a static library instead of shared one.
Even -no-undefined did not help.
* fixes "~winpthreads changes ~pthread_signal.h" etc. reported by build-pkg
mingw-w64 installs dummy headers if winpthreads isn't built
* enables libgomp to avoid double-build (see #331)
* no change in openmp-validation (still 20 failures - taken with a grain of
salt as the batch file test runner isn't a reliable perl substitute)
* pthreads virtual package kept for future testing
Example: "4_1_3" -> "4.1.3-20151028".
Adding build-unique (making two builds in one day is unlikely)
Debian patch version tells APT that the package was updated.
Underscores in versions were previously replaced with dashes.
Example: 4_1_3 -> 4-1-3 (package winpcap).
"-3" is interpreted as Debian patch version, which is wrong.
Move common code (making a directory, control file, running tar,
dpkg-deb, etc) to function makePackage(). This function is used
by functions makeDeb() and makeMxeRequirementsDeb().
When the client library of PostgreSQL is compiled with a MinGW-w64
environment the resulting libpq does not work. This has been reported
upstream with two bug reports and a patch was submitted by
Michael Cronenworth <mike(at)cchtml(dot)com> (1) but it has not been
picked up by upstream.
This is confirmed to build on Arch Linux x64 with targets:
x86_64-w64-mingw32.static and i686-w64-mingw32.static
and works under Wine, Windows 7 and Windows 10 (both 32/64bit binaries)
(1) http://www.postgresql.org/message-id/520EBC3D.1010103@cchtml.comfixes#690
"make target~pkg" doesn't work if target is not in
MXE_TARGETS. I believe such behaviout to be a feature
not a bug, because it seems to work faster with lesser
MXE_TARGETS.
str:match(pattern) treats pattern as a regular expression.
str:find(substring, 1, true) searches for a substring.
The latter is needed to check if a filename contains a target.
1. Remove common packages.
Common packages served a replacement for native target.
Now we have native target and don't need common packages.
Existing common files (ncurses) have to be fixed.
2. Package -> Item.
Item means a string "target~package".
All functions which used packages now use items.
3. One build list instead of 4 build lists.
All items are sorted and built together without separation
by target.
4. No module-global variable "target".
All functions using target now get "item" and target is
extracted from item. All remaining module-global variables
don't change (are constants) or are created in the bottom
of the module.
5. MXE_MAX_PACKAGES -> MXE_MAX_ITEMS
see #925
see #919
Boris Nagaev
Timothy Gu
Rémy Roy
MXEBot as Travis CI
Mark Brand
Tony Theodore
Engine Feeder