* [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 @ 2018-01-16 16:59 Corinna Vinschen 2018-01-17 10:42 ` Houder 2018-01-17 22:29 ` Ken Brown 0 siblings, 2 replies; 15+ messages in thread From: Corinna Vinschen @ 2018-01-16 16:59 UTC (permalink / raw) To: cygwin Hi folks, I uploaded a new Cygwin test release 2.10.0-0.1 I'm planning for a release end of January. Please test. ======================================================================= What's new: ----------- - New open(2) flags O_TMPFILE and O_NOATIME. - scanf/wscanf now handle the POSIX %m modifier. - scanf now handles the %l[ conversion. - New APIs: sigtimedwait, wmempcpy. Bug Fixes --------- - Fix a problem in unlink on NFS. Addresses: Shows up in GAWK testsuite test "testext" - Fix errno setting bug in posix_fadvise and posix_fallocate. Addresses: https://cygwin.com/ml/cygwin-patches/2017-q4/msg00026.html - Fix two bugs in the limit of large numbers of sockets. Addresses: https://cygwin.com/ml/cygwin/2017-11/msg00052.html - Fix a fork failure with private anonymous mmaps. Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00061.html - Remove a call to fflush from ftell{o}, which may result in wrong offsets. Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00151.html - Fix file pointer computation after short writes on block devices. Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00151.html ======================================================================= Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-16 16:59 [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 Corinna Vinschen @ 2018-01-17 10:42 ` Houder 2018-01-17 10:50 ` Corinna Vinschen 2018-01-17 22:29 ` Ken Brown 1 sibling, 1 reply; 15+ messages in thread From: Houder @ 2018-01-17 10:42 UTC (permalink / raw) To: cygwin On Tue, 16 Jan 2018 16:51:08, Corinna Vinschen wrote: > Hi folks, > > > I uploaded a new Cygwin test release 2.10.0-0.1 .. did you really upload it? As the mirror tells me it is not there ... Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-17 10:42 ` Houder @ 2018-01-17 10:50 ` Corinna Vinschen 2018-01-17 11:40 ` Houder 0 siblings, 1 reply; 15+ messages in thread From: Corinna Vinschen @ 2018-01-17 10:50 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 539 bytes --] On Jan 17 11:42, Houder wrote: > On Tue, 16 Jan 2018 16:51:08, Corinna Vinschen wrote: > > Hi folks, > > > > > > I uploaded a new Cygwin test release 2.10.0-0.1 > > .. did you really upload it? As the mirror tells me it is not there ... Thanks for the heads up. I only uploaded the 32 bit version, accidentally. The 64 bit version will be up in a bit, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-17 10:50 ` Corinna Vinschen @ 2018-01-17 11:40 ` Houder 2018-01-17 12:07 ` Houder 0 siblings, 1 reply; 15+ messages in thread From: Houder @ 2018-01-17 11:40 UTC (permalink / raw) To: cygwin On Wed, 17 Jan 2018 11:50:23, Corinna Vinschen wrote: > --+nBD6E3TurpgldQp > Content-Type: text/plain; charset=utf-8 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Jan 17 11:42, Houder wrote: > > On Tue, 16 Jan 2018 16:51:08, Corinna Vinschen wrote: > > > Hi folks, > > >=20 > > >=20 > > > I uploaded a new Cygwin test release 2.10.0-0.1 > >=20 > > .. did you really upload it? As the mirror tells me it is not there ... > > Thanks for the heads up. I only uploaded the 32 bit version, > accidentally. The 64 bit version will be up in a bit, sorry. You are right. It has arrived already! (Twente mirror, the Netherlands) Thanks, Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-17 11:40 ` Houder @ 2018-01-17 12:07 ` Houder 0 siblings, 0 replies; 15+ messages in thread From: Houder @ 2018-01-17 12:07 UTC (permalink / raw) To: cygwin On Wed, 17 Jan 2018 12:40:26, Houder wrote: > On Wed, 17 Jan 2018 11:50:23, Corinna Vinschen wrote: > > --+nBD6E3TurpgldQp > > Content-Type: text/plain; charset=utf-8 > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Jan 17 11:42, Houder wrote: > > > On Tue, 16 Jan 2018 16:51:08, Corinna Vinschen wrote: > > > > Hi folks, > > > >=20 > > > >=20 > > > > I uploaded a new Cygwin test release 2.10.0-0.1 > > >=20 > > > .. did you really upload it? As the mirror tells me it is not there ... > > > > Thanks for the heads up. I only uploaded the 32 bit version, > > accidentally. The 64 bit version will be up in a bit, sorry. > > You are right. It has arrived already! (Twente mirror, the Netherlands) ... although setup.ini still? has to be updated ... Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-16 16:59 [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 Corinna Vinschen 2018-01-17 10:42 ` Houder @ 2018-01-17 22:29 ` Ken Brown 2018-01-18 14:36 ` Ken Brown 1 sibling, 1 reply; 15+ messages in thread From: Ken Brown @ 2018-01-17 22:29 UTC (permalink / raw) To: cygwin On 1/16/2018 10:51 AM, Corinna Vinschen wrote: > Hi folks, > > > I uploaded a new Cygwin test release 2.10.0-0.1 > > I'm planning for a release end of January. Please test. Do we need a new gcc release to go along with the recent ssp changes? STC: $ cat ssp_test.c #define _FORTIFY_SOURCE 1 #include <unistd.h> $ gcc -O1 -c ssp_test.c In file included from /usr/include/sys/unistd.h:592:0, from /usr/include/unistd.h:4, from ssp_test.c:2: /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/include/ssp/unistd.h:38:17: fatal error: ssp.h: No such file or directory #include <ssp.h> ^ Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-17 22:29 ` Ken Brown @ 2018-01-18 14:36 ` Ken Brown 2018-01-18 21:30 ` Yaakov Selkowitz 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2018-01-18 14:36 UTC (permalink / raw) To: cygwin On 1/17/2018 5:29 PM, Ken Brown wrote: > On 1/16/2018 10:51 AM, Corinna Vinschen wrote: >> Hi folks, >> >> >> I uploaded a new Cygwin test release 2.10.0-0.1 >> >> I'm planning for a release end of January. Please test. > > Do we need a new gcc release to go along with the recent ssp changes? The following commit message seems to answer my question: commit 3e8fc7d9f21329d5a98ec3cf6de138bce9bc2c05 Author: Yaakov Selkowitz <yselkowi@redhat.com> Date: Mon Nov 27 23:07:10 2017 -0600 ssp: add Object Size Checking common code [...] Note that this does require building gcc with --disable-libssp and gcc_cv_libc_provides_ssp=yes. Are there plans to coordinate the release of Cygwin 2.10.0 with a new gcc release? In the meantime, I guess package maintainers have to build with -U_FORTIFY_SOURCE in order to test building with Cygwin 2.10.0. Or am I missing something? Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-18 14:36 ` Ken Brown @ 2018-01-18 21:30 ` Yaakov Selkowitz 2018-01-18 23:28 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Yaakov Selkowitz @ 2018-01-18 21:30 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 869 bytes --] On 2018-01-18 08:35, Ken Brown wrote: > On 1/17/2018 5:29 PM, Ken Brown wrote: >> Do we need a new gcc release to go along with the recent ssp changes? > > The following commit message seems to answer my question: > > Note that this does require building gcc with --disable-libssp and > gcc_cv_libc_provides_ssp=yes. Correct. > Are there plans to coordinate the release of Cygwin 2.10.0 with a new > gcc release? In the meantime, I guess package maintainers have to build > with -U_FORTIFY_SOURCE in order to test building with Cygwin 2.10.0. Or > am I missing something? -D_FORTIFY_SOURCE is not the default, so simply omitting it is sufficient. You could also just delete /usr/lib/gcc/*-pc-cygwin/6.4.0/include/ssp, since we won't need it anymore and it wasn't even being used properly in the first place. -- Yaakov [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-18 21:30 ` Yaakov Selkowitz @ 2018-01-18 23:28 ` Ken Brown 2018-01-20 3:27 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2018-01-18 23:28 UTC (permalink / raw) To: cygwin On 1/18/2018 4:30 PM, Yaakov Selkowitz wrote: > On 2018-01-18 08:35, Ken Brown wrote: >> On 1/17/2018 5:29 PM, Ken Brown wrote: >>> Do we need a new gcc release to go along with the recent ssp changes? >> >> The following commit message seems to answer my question: >> >>    Note that this does require building gcc with --disable-libssp and >>    gcc_cv_libc_provides_ssp=yes. > > Correct. > >> Are there plans to coordinate the release of Cygwin 2.10.0 with a new >> gcc release? In the meantime, I guess package maintainers have to build >> with -U_FORTIFY_SOURCE in order to test building with Cygwin 2.10.0. Or >> am I missing something? > > -D_FORTIFY_SOURCE is not the default, so simply omitting it is > sufficient. I was talking about building projects in which _FORTIFY_SOURCE is defined by default. That happens, for instance, in the gnulib subdirectory of the emacs tree, so it may affect other projects that use gnulib also. > You could also just delete > /usr/lib/gcc/*-pc-cygwin/6.4.0/include/ssp, since we won't need it > anymore and it wasn't even being used properly in the first place. That's a simpler workaround than what I was doing. Thanks. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-18 23:28 ` Ken Brown @ 2018-01-20 3:27 ` Ken Brown 2018-01-20 12:23 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2018-01-20 3:27 UTC (permalink / raw) To: cygwin On 1/18/2018 6:28 PM, Ken Brown wrote: > On 1/18/2018 4:30 PM, Yaakov Selkowitz wrote: >> On 2018-01-18 08:35, Ken Brown wrote: >>> On 1/17/2018 5:29 PM, Ken Brown wrote: >>>> Do we need a new gcc release to go along with the recent ssp changes? >>> >>> The following commit message seems to answer my question: >>> >>>     Note that this does require building gcc with --disable-libssp and >>>     gcc_cv_libc_provides_ssp=yes. >> >> Correct. >> >>> Are there plans to coordinate the release of Cygwin 2.10.0 with a new >>> gcc release? In the meantime, I guess package maintainers have to build >>> with -U_FORTIFY_SOURCE in order to test building with Cygwin 2.10.0. Or >>> am I missing something? >> >> -D_FORTIFY_SOURCE is not the default, so simply omitting it is >> sufficient. > > I was talking about building projects in which _FORTIFY_SOURCE is > defined by default. That happens, for instance, in the gnulib > subdirectory of the emacs tree, so it may affect other projects that use > gnulib also. > >> You could also just delete >> /usr/lib/gcc/*-pc-cygwin/6.4.0/include/ssp, since we won't need it >> anymore and it wasn't even being used properly in the first place. > > That's a simpler workaround than what I was doing. Thanks. Here's another issue that's come up with _FORTIFY_SOURCE. One of the emacs source files, fileio.c, makes use of a pointer to readlinkat. [More precisely, the file uses an external function foo() with a parameter 'bar' that's a pointer to a function; foo is called in fileio.c with bar = readlinkat.] When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to `__ssp_protected_readlinkat'" linking error. Does this sound like something that will be fixed with the new gcc release? I realize I haven't given you full details, but it might be a few days until I have a chance to extract an STC for this issue, so I thought I'd give it a shot. If you can't answer the question based on the information above, I'll make an STC as soon as I can. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-20 3:27 ` Ken Brown @ 2018-01-20 12:23 ` Ken Brown 2018-01-20 23:49 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2018-01-20 12:23 UTC (permalink / raw) To: cygwin On 1/19/2018 10:27 PM, Ken Brown wrote: > On 1/18/2018 6:28 PM, Ken Brown wrote: >> On 1/18/2018 4:30 PM, Yaakov Selkowitz wrote: >>> On 2018-01-18 08:35, Ken Brown wrote: >>>> On 1/17/2018 5:29 PM, Ken Brown wrote: >>>>> Do we need a new gcc release to go along with the recent ssp changes? >>>> >>>> The following commit message seems to answer my question: >>>> >>>>     Note that this does require building gcc with --disable-libssp and >>>>     gcc_cv_libc_provides_ssp=yes. >>> >>> Correct. >>> >>>> Are there plans to coordinate the release of Cygwin 2.10.0 with a new >>>> gcc release? In the meantime, I guess package maintainers have to >>>> build >>>> with -U_FORTIFY_SOURCE in order to test building with Cygwin >>>> 2.10.0. Or >>>> am I missing something? >>> >>> -D_FORTIFY_SOURCE is not the default, so simply omitting it is >>> sufficient. >> >> I was talking about building projects in which _FORTIFY_SOURCE is >> defined by default. That happens, for instance, in the gnulib >> subdirectory of the emacs tree, so it may affect other projects that >> use gnulib also. >> >>> You could also just delete >>> /usr/lib/gcc/*-pc-cygwin/6.4.0/include/ssp, since we won't need it >>> anymore and it wasn't even being used properly in the first place. >> >> That's a simpler workaround than what I was doing. Thanks. > > Here's another issue that's come up with _FORTIFY_SOURCE. One of the > emacs source files, fileio.c, makes use of a pointer to readlinkat. > [More precisely, the file uses an external function foo() with a > parameter 'bar' that's a pointer to a function; foo is called in > fileio.c with bar = readlinkat.] > > When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to > `__ssp_protected_readlinkat'" linking error. Does this sound like > something that will be fixed with the new gcc release? > > I realize I haven't given you full details, but it might be a few days > until I have a chance to extract an STC for this issue, so I thought I'd > give it a shot. > > If you can't answer the question based on the information above, I'll > make an STC as soon as I can. I got to this sooner than expected: $ cat ssp_test.c #define _FORTIFY_SOURCE 1 #include <unistd.h> void foo (ssize_t (*preadlinkat) (int, char const *, char *, size_t)); void baz () { foo (readlinkat); } $ gcc -c -O1 ssp_test.c $ objdump -x ssp_test.o | grep readlinkat 6 .rdata$.refptr.__ssp_protected_readlinkat 00000010 0000000000000000 0000000000000000 00000180 2**4 [...] Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-20 12:23 ` Ken Brown @ 2018-01-20 23:49 ` Ken Brown 2018-01-24 19:25 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2018-01-20 23:49 UTC (permalink / raw) To: cygwin On 1/20/2018 7:23 AM, Ken Brown wrote: > On 1/19/2018 10:27 PM, Ken Brown wrote: >> On 1/18/2018 6:28 PM, Ken Brown wrote: >>> On 1/18/2018 4:30 PM, Yaakov Selkowitz wrote: >>>> On 2018-01-18 08:35, Ken Brown wrote: >>>>> On 1/17/2018 5:29 PM, Ken Brown wrote: >>>>>> Do we need a new gcc release to go along with the recent ssp changes? >>>>> >>>>> The following commit message seems to answer my question: >>>>> >>>>>     Note that this does require building gcc with --disable-libssp >>>>> and >>>>>     gcc_cv_libc_provides_ssp=yes. >>>> >>>> Correct. >>>> >>>>> Are there plans to coordinate the release of Cygwin 2.10.0 with a new >>>>> gcc release? In the meantime, I guess package maintainers have to >>>>> build >>>>> with -U_FORTIFY_SOURCE in order to test building with Cygwin >>>>> 2.10.0. Or >>>>> am I missing something? >>>> >>>> -D_FORTIFY_SOURCE is not the default, so simply omitting it is >>>> sufficient. >>> >>> I was talking about building projects in which _FORTIFY_SOURCE is >>> defined by default. That happens, for instance, in the gnulib >>> subdirectory of the emacs tree, so it may affect other projects that >>> use gnulib also. >>> >>>> You could also just delete >>>> /usr/lib/gcc/*-pc-cygwin/6.4.0/include/ssp, since we won't need it >>>> anymore and it wasn't even being used properly in the first place. >>> >>> That's a simpler workaround than what I was doing. Thanks. >> >> Here's another issue that's come up with _FORTIFY_SOURCE. One of the >> emacs source files, fileio.c, makes use of a pointer to readlinkat. >> [More precisely, the file uses an external function foo() with a >> parameter 'bar' that's a pointer to a function; foo is called in >> fileio.c with bar = readlinkat.] >> >> When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to >> `__ssp_protected_readlinkat'" linking error. Does this sound like >> something that will be fixed with the new gcc release? >> >> I realize I haven't given you full details, but it might be a few days >> until I have a chance to extract an STC for this issue, so I thought >> I'd give it a shot. >> >> If you can't answer the question based on the information above, I'll >> make an STC as soon as I can. > > I got to this sooner than expected: > > $ cat ssp_test.c > #define _FORTIFY_SOURCE 1 > #include <unistd.h> > void foo (ssize_t (*preadlinkat) (int, char const *, char *, size_t)); > > void baz () > { >  foo (readlinkat); > } > > $ gcc -c -O1 ssp_test.c > > $ objdump -x ssp_test.o | grep readlinkat >  6 .rdata$.refptr.__ssp_protected_readlinkat 00000010 > 0000000000000000 0000000000000000 00000180 2**4 > [...] And the problem is still there with the new GCC that was just released. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-20 23:49 ` Ken Brown @ 2018-01-24 19:25 ` Ken Brown 2018-01-25 0:16 ` Yaakov Selkowitz 0 siblings, 1 reply; 15+ messages in thread From: Ken Brown @ 2018-01-24 19:25 UTC (permalink / raw) To: cygwin On 1/20/2018 6:49 PM, Ken Brown wrote: > On 1/20/2018 7:23 AM, Ken Brown wrote: >> On 1/19/2018 10:27 PM, Ken Brown wrote: >>> On 1/18/2018 6:28 PM, Ken Brown wrote: >>>> On 1/18/2018 4:30 PM, Yaakov Selkowitz wrote: >>>>> On 2018-01-18 08:35, Ken Brown wrote: >>>>>> On 1/17/2018 5:29 PM, Ken Brown wrote: >>>>>>> Do we need a new gcc release to go along with the recent ssp >>>>>>> changes? >>>>>> >>>>>> The following commit message seems to answer my question: >>>>>> >>>>>>     Note that this does require building gcc with >>>>>> --disable-libssp and >>>>>>     gcc_cv_libc_provides_ssp=yes. >>>>> >>>>> Correct. >>>>> >>>>>> Are there plans to coordinate the release of Cygwin 2.10.0 with a new >>>>>> gcc release? In the meantime, I guess package maintainers have to >>>>>> build >>>>>> with -U_FORTIFY_SOURCE in order to test building with Cygwin >>>>>> 2.10.0. Or >>>>>> am I missing something? >>>>> >>>>> -D_FORTIFY_SOURCE is not the default, so simply omitting it is >>>>> sufficient. >>>> >>>> I was talking about building projects in which _FORTIFY_SOURCE is >>>> defined by default. That happens, for instance, in the gnulib >>>> subdirectory of the emacs tree, so it may affect other projects that >>>> use gnulib also. >>>> >>>>> You could also just delete >>>>> /usr/lib/gcc/*-pc-cygwin/6.4.0/include/ssp, since we won't need it >>>>> anymore and it wasn't even being used properly in the first place. >>>> >>>> That's a simpler workaround than what I was doing. Thanks. >>> >>> Here's another issue that's come up with _FORTIFY_SOURCE. One of the >>> emacs source files, fileio.c, makes use of a pointer to readlinkat. >>> [More precisely, the file uses an external function foo() with a >>> parameter 'bar' that's a pointer to a function; foo is called in >>> fileio.c with bar = readlinkat.] >>> >>> When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to >>> `__ssp_protected_readlinkat'" linking error. Does this sound like >>> something that will be fixed with the new gcc release? >>> >>> I realize I haven't given you full details, but it might be a few >>> days until I have a chance to extract an STC for this issue, so I >>> thought I'd give it a shot. >>> >>> If you can't answer the question based on the information above, I'll >>> make an STC as soon as I can. >> >> I got to this sooner than expected: >> >> $ cat ssp_test.c >> #define _FORTIFY_SOURCE 1 >> #include <unistd.h> >> void foo (ssize_t (*preadlinkat) (int, char const *, char *, size_t)); >> >> void baz () >> { >>   foo (readlinkat); >> } >> >> $ gcc -c -O1 ssp_test.c >> >> $ objdump -x ssp_test.o | grep readlinkat >>   6 .rdata$.refptr.__ssp_protected_readlinkat 00000010 >> 0000000000000000 0000000000000000 00000180 2**4 >> [...] The following patch seems to fix the problem: --- ssp.h~ 2018-01-22 09:18:18.000000000 -0500 +++ ssp.h 2018-01-24 13:44:55.856635800 -0500 @@ -41,7 +41,7 @@ #endif #define __ssp_real(fun) __ssp_real_(fun) -#define __ssp_inline extern __inline__ __attribute__((__always_inline__, __gnu_inline__)) +#define __ssp_inline extern __inline__ __attribute__((__always_inline__)) #define __ssp_bos(ptr) __builtin_object_size(ptr, __SSP_FORTIFY_LEVEL > 1) #define __ssp_bos0(ptr) __builtin_object_size(ptr, 0) I arrived at this by comparing Cygwin's ssp.h with NetBSD's, on which Cygwin's was based, and I noticed that NetBSD didn't use __gnu_inline__. Yaakov, is there a reason that Cygwin needs __gnu_inline__? It apparently prevents fortified functions from being used as function pointers. Using my test case again, here's what happens with and without __gnu_inline__: With: $ gcc -O1 -c ssp_test.c && objdump -x ssp_test.o | grep readlinkat 6 .rdata$.refptr.__ssp_protected_readlinkat 00000010 0000000000000000 0000000000000000 00000180 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA, LINK_ONCE_DISCARD (COMDAT .refptr.__ssp_protected_readlinkat 18) [ 4](sec 7)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x0000000000000000 .rdata$.refptr.__ssp_protected_readlinkat [ 18](sec 7)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 .refptr.__ssp_protected_readlinkat [ 19](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 __ssp_protected_readlinkat 0000000000000007 R_X86_64_PC32 __ssp_protected_readlinkat RELOCATION RECORDS FOR [.rdata$.refptr.__ssp_protected_readlinkat]: 0000000000000000 R_X86_64_64 __ssp_protected_readlinkat Without: $ gcc -O1 -c ssp_test.c && objdump -x ssp_test.o | grep readlinkat [ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x0000000000000000 __ssp_protected_readlinkat [ 27](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 readlinkat 0000000000000005 R_X86_64_PC32 readlinkat Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-24 19:25 ` Ken Brown @ 2018-01-25 0:16 ` Yaakov Selkowitz 2018-01-25 2:42 ` Ken Brown 0 siblings, 1 reply; 15+ messages in thread From: Yaakov Selkowitz @ 2018-01-25 0:16 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 2106 bytes --] On 2018-01-24 13:25, Ken Brown wrote: > On 1/20/2018 6:49 PM, Ken Brown wrote: >> On 1/20/2018 7:23 AM, Ken Brown wrote: >>> On 1/19/2018 10:27 PM, Ken Brown wrote: >>>> Here's another issue that's come up with _FORTIFY_SOURCE. One of the >>>> emacs source files, fileio.c, makes use of a pointer to readlinkat. >>>> When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to >>>> `__ssp_protected_readlinkat'" linking error. Does this sound like >>>> something that will be fixed with the new gcc release? >>> >>> I got to this sooner than expected: >>> >>> $ cat ssp_test.c >>> #define _FORTIFY_SOURCE 1 >>> #include <unistd.h> >>> void foo (ssize_t (*preadlinkat) (int, char const *, char *, size_t)); >>> >>> void baz () >>> { >>> foo (readlinkat); >>> } > > The following patch seems to fix the problem: > > -#define __ssp_inline extern __inline__ __attribute__((__always_inline__, __gnu_inline__)) > +#define __ssp_inline extern __inline__ __attribute__((__always_inline__)) No, that would have other consequences: https://gcc.gnu.org/onlinedocs/gcc/Inline.html > I arrived at this by comparing Cygwin's ssp.h with NetBSD's, on which > Cygwin's was based, and I noticed that NetBSD didn't use __gnu_inline__. The BSDs also stuck with GCC 4.2 due to licensing reasons, so you can't always compare. > Yaakov, is there a reason that Cygwin needs __gnu_inline__? Because the semantics of inline changed in GCC 4.3. > It apparently prevents fortified functions from being used as function pointers. I am currently testing the following, which seems to match glibc in this detail: --- a/newlib/libc/include/ssp/ssp.h +++ b/newlib/libc/include/ssp/ssp.h @@ -51,7 +51,6 @@ __chk_fail() #define __ssp_decl(rtype, fun, args) \ rtype __ssp_real_(fun) args __asm__(__ASMNAME(#fun)); \ -__ssp_inline rtype fun args __asm__(__ASMNAME("__ssp_protected_" #fun)); \ __ssp_inline rtype fun args #define __ssp_redirect_raw(rtype, fun, args, call, cond, bos) \ __ssp_decl(rtype, fun, args) \ -- Yaakov [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 2018-01-25 0:16 ` Yaakov Selkowitz @ 2018-01-25 2:42 ` Ken Brown 0 siblings, 0 replies; 15+ messages in thread From: Ken Brown @ 2018-01-25 2:42 UTC (permalink / raw) To: cygwin On 1/24/2018 7:16 PM, Yaakov Selkowitz wrote: > On 2018-01-24 13:25, Ken Brown wrote: >> On 1/20/2018 6:49 PM, Ken Brown wrote: >>> On 1/20/2018 7:23 AM, Ken Brown wrote: >>>> On 1/19/2018 10:27 PM, Ken Brown wrote: >>>>> Here's another issue that's come up with _FORTIFY_SOURCE. One of the >>>>> emacs source files, fileio.c, makes use of a pointer to readlinkat. >>>>> When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to >>>>> `__ssp_protected_readlinkat'" linking error. Does this sound like >>>>> something that will be fixed with the new gcc release? >>>> >>>> I got to this sooner than expected: >>>> >>>> $ cat ssp_test.c >>>> #define _FORTIFY_SOURCE 1 >>>> #include <unistd.h> >>>> void foo (ssize_t (*preadlinkat) (int, char const *, char *, size_t)); >>>> >>>> void baz () >>>> { >>>>   foo (readlinkat); >>>> } >> >> The following patch seems to fix the problem: >> >> -#define __ssp_inline extern __inline__ __attribute__((__always_inline__, __gnu_inline__)) >> +#define __ssp_inline extern __inline__ __attribute__((__always_inline__)) > > No, that would have other consequences: > > https://gcc.gnu.org/onlinedocs/gcc/Inline.html > >> I arrived at this by comparing Cygwin's ssp.h with NetBSD's, on which >> Cygwin's was based, and I noticed that NetBSD didn't use __gnu_inline__. > > The BSDs also stuck with GCC 4.2 due to licensing reasons, so you can't > always compare. > >> Yaakov, is there a reason that Cygwin needs __gnu_inline__? > > Because the semantics of inline changed in GCC 4.3. > >> It apparently prevents fortified functions from being used as function pointers. > > I am currently testing the following, which seems to match glibc in this > detail: > > --- a/newlib/libc/include/ssp/ssp.h > +++ b/newlib/libc/include/ssp/ssp.h > @@ -51,7 +51,6 @@ > __chk_fail() > #define __ssp_decl(rtype, fun, args) \ > rtype __ssp_real_(fun) args __asm__(__ASMNAME(#fun)); \ > -__ssp_inline rtype fun args __asm__(__ASMNAME("__ssp_protected_" #fun)); \ > __ssp_inline rtype fun args > #define __ssp_redirect_raw(rtype, fun, args, call, cond, bos) \ > __ssp_decl(rtype, fun, args) \ Works for me. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-01-25 2:42 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-16 16:59 [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1 Corinna Vinschen 2018-01-17 10:42 ` Houder 2018-01-17 10:50 ` Corinna Vinschen 2018-01-17 11:40 ` Houder 2018-01-17 12:07 ` Houder 2018-01-17 22:29 ` Ken Brown 2018-01-18 14:36 ` Ken Brown 2018-01-18 21:30 ` Yaakov Selkowitz 2018-01-18 23:28 ` Ken Brown 2018-01-20 3:27 ` Ken Brown 2018-01-20 12:23 ` Ken Brown 2018-01-20 23:49 ` Ken Brown 2018-01-24 19:25 ` Ken Brown 2018-01-25 0:16 ` Yaakov Selkowitz 2018-01-25 2:42 ` Ken Brown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).