Created attachment 497836 [details] libpcre2-10.30.ebuild emerge info build error Hello, I want to report a compile issue I am facing with a fresh built gentoo-prefix under Cygwin64 and Windows 7 Professional. The lib failing to compile is libpcre2-10.30 and gentoo-prefix has been compiled using the regular bootstrap-prefix.sh script. From what I can understand the error is the following: " error: '_O_BINARY' undeclared (first use in this function) _setmode(_fileno(stdout), _O_BINARY);" Find attached `emerge -pqv '=dev-libs/libpcre2-10.30::gentoo_prefix'` and gentoo/var/tmp/portage/dev-libs/libpcre2-10.30/temp/build.log' log file. Please let me know if more info or troubleshooting is needed from my end. Regards, Pietro
(In reply to Pietro from comment #0) > From what I can understand the error is the following: " error: '_O_BINARY' > undeclared (first use in this function) _setmode(_fileno(stdout), > _O_BINARY);" Dear Pietro, You may need to patch libpcre2 to change _O_BINARY (windows) to O_BINARY (posix) or vice-versa, depending on how the code was written. You can try adding a `#define _O_BINARY O_BINARY` in the header that you see the failure. Hope that helps.
(In reply to Guilherme Amadio from comment #1) > (In reply to Pietro from comment #0) > > From what I can understand the error is the following: " error: '_O_BINARY' > > undeclared (first use in this function) _setmode(_fileno(stdout), > > _O_BINARY);" > > Dear Pietro, > > You may need to patch libpcre2 to change _O_BINARY (windows) to O_BINARY > (posix) or vice-versa, depending on how the code was written. You can try > adding a `#define _O_BINARY O_BINARY` in the header that you see the failure. > > Hope that helps. Hello Guilherme, thank you for getting back to me and I do apologize for the extremely late reply. For some reason your reply got lost in my email box. Unfortunately I know nothing about code and I highly doubt I could figure this out on my own. Do you think that dev-libs/libpcre2 Gentoo maintainer could help us out with this? Best Regards, Pietro Sammarco
I just had this on Windows 10, cygwin-2.90 (with gentoo fork patch) and a fresh gentoo prefix install. The reason is, that libpcre2 assumes __CYGWIN__ to be windows (generally correct), and that windows headers are then needed. That is true for Plain Cygwin, but not for Cygwin-on-steroids (aka Gentoo Prefixed). I'll attach a patch that will make it work and cleanly merge in A Cygwin Gentoo Prefix. That patch is only needed in the prefix, as libpcre2 *should* build fine on standard Cygwin.
Created attachment 510034 [details, diff] Enable build in a gentoo prefix on cygwin This patch generally states that windows stuff is only needed if __CYGWIN__ is *not* defined. This will make sure that the build will (AFAIK) fail on MinGW and plain cygwin, so only apply in a gentoo prefix. Fastest way to use, as libpcre2 does not support user patches is: $ ebuild /gentoo/usr/portage/dev-libs/libpcre2/libpcre2-10.30.ebuild prepare $ cd /gentoo/var/tmp/portage/dev-libs/libpcre2-10.30/work/pcre2-10.30 $ patch -p 1 -i /etc/portage/patches/dev-libs/pcre2-10.30/enable_build_on_cygwin_prefix.patch $ cd $ ebuild /gentoo/usr/portage/dev-libs/libpcre2/libpcre2-10.30.ebuild merge
Well, my first thought is that WIN32 actually shouldn't be defined with Cygwin at all. Then I found this upstream bug report: https://bugs.exim.org/show_bug.cgi?id=2152 And indeed, not defining WIN32 with Cygwin does help here.
Created attachment 515160 [details, diff] proposed patch for dev-libs/libpcre2
Please review this patch for Cygwin, proposed upstream in https://bugs.exim.org/show_bug.cgi?id=2152#c13 Thanks!
(In reply to Michael Haubenwallner from comment #7) > Please review this patch for Cygwin, proposed upstream in > https://bugs.exim.org/show_bug.cgi?id=2152#c13 > Thanks! The patch looks good to me. Only the Bugzilla "diff" view is screwed, if anybody wonders. -------- I have to correct myself. While working on a lot packages to play nicely with my gentoo prefixed cygwin, I had to do quite some research and came along some interesting information I wasn't aware of. For instance the "cmake battle" between the cygwin folk and the cmake developers. (This thread: https://cmake.org/pipermail/cmake/2010-October/040353.html ) from 2010 is most telling. My favourite quote is from Yaakov: > We are the distributors of Cygwin. We make Cygwin as a very capable > *NIX/X11 platform. We do not want WIN32 defined on Cygwin. Period. The conclusion, and cmake folks eventually gave in, is the following: A) Some WIN32 details are true for Cygwin, too, because it has to use the Windows kernel and library loader. B) Cygwin is *NOT* WIN32 everywhere else C) Cygwin is as much POSIX/UNIX as it can be (apart from A)
Created attachment 536498 [details, diff] proposed patch for dev-libs/libpcre2-10.31 The patch is committed upstream now: https://bugs.exim.org/show_bug.cgi?id=2152#c14 https://vcs.pcre.org/pcre2?view=revision&revision=939
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fef0e0c22854d149001db13f0e8872c87a6bf68f commit fef0e0c22854d149001db13f0e8872c87a6bf68f Author: Michael Haubenwallner <haubi@gentoo.org> AuthorDate: 2018-01-17 15:21:25 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2018-06-20 09:09:25 +0000 dev-libs/libpcre2: fix cygwin build Closes: https://bugs.gentoo.org/633612 Package-Manager: Portage-2.3.13, Repoman-2.3.3 Closes: https://github.com/gentoo/gentoo/pull/8918 dev-libs/libpcre2/files/libpcre2-10.31-cygwin.patch | 16 ++++++++++++++++ dev-libs/libpcre2/libpcre2-10.31.ebuild | 4 ++++ 2 files changed, 20 insertions(+)
