Dear All,
after a very tedious search for the problem with the MSYS2 build, I
finally found the culprit: it seems that a rogue virus protection
(Symantec Endpoint Protection) blocked ~one in a thousand linking
of executables. It blocked preferably the ones used by autotools
"configure", which led auto-tools to believe that the system would
not have certain basic types like int32_t or ptrdiff_t etc, and which
in turn broke the build. It was not sufficient to disable Symantec
Endpoint Protection for the build directory, there was still some
active protection that made 'ld' fail. Finally the solution was to
uninstall Symantec Endpoint Protection to make the builds work.
I hope this may help somebody else in the future...
Cheers,
Mario
On 02.03.2017 21:56, Mario Emmenlauer wrote:
>
> Dear all,
>
> when trying to build a larger set of mingw-w64-packages from my own CI
> system on Windows 7 using an x86_64 install of MSYS2, I currently run
> into a number of difficulties, mostly around binutils, or more concretely
> with nm and ld. See my corresponding issue reports here [2] [3] [4] [5].
> I can not shake off the feeling that possibly its not a mingw-w64 problem,
> but that my build system is at fault. So I'd like to kindly pick your
> brains for insight:
>
> - my CI system has .../msys2/usr/bin in the path, and starts bash from
> there. I use "bash --login -c 'my-build-script.sh'". Is that sensible,
> or does this ring any alarm signs for anyone?
>
> - Is it recommended that I set MSYSTEM="MINGW64" and explicitly source
> /etc/profile before using makepkg-mingw? I found the excellent posts
> from Ray Donnely and Matthieu Vachon at [1], and my understanding is
> that plain "bash --login -c" should be a good environment for
> makepkg-mingw. But there are some hints that i.e. adding /mingw64 at
> the end of the path might be useful in case an msys2 is missing and
> the mingw64 counterpart can jump in. I did not test this yet... but
> any such "black magic" is very welcome right now if you believe it
> can help me out.
>
> - I assume my CI is using the standard Windows command prompt. Is
> there something that could go wrong with a bad cmd interpreter or
> an incorrectly picked 32bit vs 64bit cmd or something? I guess the
> fact that bash starts and does something means that the environment
> should be ok? Or is there possibly some "bad karma" that I might
> inherit from using a "wrong" cmd interpreter?
>
> - The CI should start the process as my Windows GUI user. The account has
> the system logon permission set, and has a password set for logon. I
> chose this user because I read something about possible permission
> issues when running on Windows as a pure system user account. But since
> the user account is the same for GUI and CI, there should not be any
> such problems, or should there?
>
> - Is it legal to copy msys2 to a new directory and use it from there?
> I used grep/perl to fixed some references to the official build repo
> path C:/building/msys64, but other than that I could not find hard-
> coded paths. Should the copy of msys2 work, or is a re-install required?
>
> All the best,
>
> Mario Emmenlauer
>
>
> [1] https://sourceforge.net/p/msys2/discussion/general/thread/dcf8f4d3/
> [2] https://github.com/Alexpux/MINGW-packages/issues/2186
> [3] https://github.com/Alexpux/MINGW-packages/issues/2196
> [4] https://github.com/Alexpux/MINGW-packages/issues/2234
> [5] https://github.com/Alexpux/MINGW-packages/issues/2244
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Msys2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/msys2-users
