Open p5pRT opened 6 years ago
A vanilla build of blead on:
$ uname -a CYGWIN_NT-6.1 phobos 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin
Fails with:
$ make locale.o
gcc -c -DPERL_CORE -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -std=c89 -O3 -Wall -Werror=declaration-after-statement -Werror=pointer-arith -Wextra -Wc++-compat -Wwrite-strings locale.c
In file included from /usr/include/ssp/stdlib.h:4:0\,
from /usr/include/stdlib.h:338\,
from perl.h:819\,
from locale.c:49:
/usr/include/ssp/wchar.h:78:1: error: conflicting types for âfgetwsâ
__ssp_decl(wchar_t *\, fgetws\, (wchar_t *__restrict __buf\, int __wlen\, FILE *__restrict __fp))
^
In file included from locale.c:54:0:
/usr/include/wchar.h:228:10: note: previous declaration of âfgetwsâ was here
wchar_t *fgetws (wchar_t *__restrict\, int\, __FILE *__restrict);
^~
In file included from /usr/include/ssp/stdlib.h:4:0\,
from /usr/include/stdlib.h:338\,
from perl.h:819\,
from locale.c:49:
/usr/include/ssp/wchar.h:86:1: error: conflicting types for âfgetws_unlockedâ
__ssp_decl(wchar_t *\, fgetws_unlocked\, (wchar_t *__buf\, int __wlen\, FILE *__fp))
^
In file included from locale.c:54:0:
/usr/include/wchar.h:261:10: note: previous declaration of âfgetws_unlockedâ was here
wchar_t *fgetws_unlocked (wchar_t *__restrict\, int\, __FILE *__restrict);
^~~~~~~
make: *** [GNUmakefile:245: locale.o] Error 1
If I modify locale.c to skip the brokeness that is nostdio.h then locale.o builds successfully:
tony@phobos ~/dev/perl/git/perl $ make locale.o gcc -c -DPERL_CORE -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -std=c89 -O3 -Wall -Werror=declaration-after-statement -Werror=pointer-arith -Wextra -Wc++-compat -Wwrite-strings locale.c
tony@phobos ~/dev/perl/git/perl $ git diff
But POSIX.o fails with the same problem:
gcc -c -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wall -Werror=declaration-after-statement -Werror=pointer-arith -Wextra -Wc++-compat -Wwrite-strings -DUSEIMPORTLIB -O3 -DVERSION=\"1.84\" -DXS_VERSION=\"1.84\" "-I../.." POSIX.c
In file included from /usr/include/sys/time.h:268:0\,
from /usr/include/sys/resource.h:12\,
from /usr/include/sys/wait.h:13\,
from ../../perl.h:842\,
from POSIX.xs:19:
POSIX.xs:1351:7: warning: â_tznameâ redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
char *tzname[] = { "" \, "" };
^
POSIX.xs:1351:20: warning: initialization discards âconstâ qualifier from pointer target type [-Wdiscarded-qualifiers]
char *tzname[] = { "" \, "" };
^~
POSIX.xs:1351:25: warning: initialization discards âconstâ qualifier from pointer target type [-Wdiscarded-qualifiers]
char *tzname[] = { "" \, "" };
^~
In file included from /usr/include/ssp/stdlib.h:4:0\,
from /usr/include/stdlib.h:338\,
from ../../perl.h:819\,
from POSIX.xs:19:
/usr/include/ssp/wchar.h:78:1: error: conflicting types for âfgetwsâ
__ssp_decl(wchar_t *\, fgetws\, (wchar_t *__restrict __buf\, int __wlen\, FILE *__restrict __fp))
^
In file included from POSIX.c:4457:0:
/usr/include/wchar.h:228:10: note: previous declaration of âfgetwsâ was here
wchar_t *fgetws (wchar_t *__restrict\, int\, __FILE *__restrict);
^~
In file included from /usr/include/ssp/stdlib.h:4:0\,
from /usr/include/stdlib.h:338\,
from ../../perl.h:819\,
from POSIX.xs:19:
/usr/include/ssp/wchar.h:86:1: error: conflicting types for âfgetws_unlockedâ
__ssp_decl(wchar_t *\, fgetws_unlocked\, (wchar_t *__buf\, int __wlen\, FILE *__fp))
^
In file included from POSIX.c:4457:0:
/usr/include/wchar.h:261:10: note: previous declaration of âfgetws_unlockedâ was here
wchar_t *fgetws_unlocked (wchar_t *__restrict\, int\, __FILE *__restrict);
^~~~~~~
POSIX.xs: In function âXS_POSIX_cuseridâ:
POSIX.xs:3712:12: warning: implicit declaration of function âcuseridâ [-Wimplicit-function-declaration]
RETVAL = cuserid(s);
^~~
POSIX.xs:3712:10: warning: assignment makes pointer from integer without a cast -Wint-conversion]
RETVAL = cuserid(s);
^
POSIX.xs: In function âmy_rintâ:
POSIX.xs:1082:1: warning: control reaches end of non-void function [-Wreturn-typ ]
}
^
make[1]: *** [Makefile:335: POSIX.o] Error 1
make[1]: Leaving directory '/home/tony/dev/perl/git/perl/ext/POSIX'
Unsuccessful make(ext/POSIX): code=512 at make_ext.pl line 570.
make: *** [GNUmakefile:585: lib/auto/POSIX/POSIX.dll] Error 2
Tony
$ ./miniperl -Ilib -V Summary of my perl5 (revision 5 version 28 subversion 0) configuration: Derived from: 71e845c3420f2496b845cf717d584dcaa063f4bf Platform: osname=cygwin osvers=2.10.0(0.32553) archname=cygwin-thread-multi uname='cygwin_nt-6.1 phobos 2.10.0(0.32553) 2018-02-02 15:16 x86_64 cygwin ' config_args='-des -Dusedevel' hint=recommended useposix=true d_sigaction=define useithreads=define usemultiplicity=define use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='gcc' ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2' optimize='-O3' cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong' ccversion='' gccversion='6.4.0' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='g++' ldflags =' -Wl\,--enable-auto-import -Wl\,--export-all-symbols -Wl\,--enable-auto-image-base -fstack-protector-strong -L/usr/local/lib' libpth=/usr/lib /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../lib/../include/w32api /usr/local/lib /lib libs=-lpthread -ldl perllibs=-lpthread -ldl libc=/usr/lib/libc.a so=dll useshrplib=true libperl=cygperl5_28_0.dll gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=dll d_dlsymun=undef ccdlflags=' ' cccdlflags=' ' lddlflags=' --shared -Wl\,--enable-auto-import -Wl\,--export-all-symbols -Wl\,--enable-auto-image-base -L/usr/local/lib -fstack-protector-strong'
Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_DONT_CREATE_GVSV PERL_EXTERNAL_GLOB PERL_IMPLICIT_CONTEXT PERL_IS_MINIPERL PERL_MALLOC_WRAP PERL_OP_PARENT PERL_PRESERVE_IVUV PERL_USE_DEVEL PERL_USE_SAFE_PUTENV USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API USE_SITECUSTOMIZE Built under cygwin Compiled at Apr 25 2018 10:01:22 @INC: /home/tony/dev/perl/git/perl/cpan/AutoLoader/lib /home/tony/dev/perl/git/perl/dist/Carp/lib /home/tony/dev/perl/git/perl/dist/PathTools /home/tony/dev/perl/git/perl/dist/PathTools/lib /home/tony/dev/perl/git/perl/cpan/ExtUtils-Install/lib /home/tony/dev/perl/git/perl/cpan/ExtUtils-MakeMaker/lib /home/tony/dev/perl/git/perl/cpan/ExtUtils-Manifest/lib /home/tony/dev/perl/git/perl/cpan/File-Path/lib /home/tony/dev/perl/git/perl/ext/re /home/tony/dev/perl/git/perl/dist/Term-ReadLine/lib /home/tony/dev/perl/git/perl/dist/Exporter/lib /home/tony/dev/perl/git/perl/ext/File-Find/lib /home/tony/dev/perl/git/perl/cpan/Text-Tabs/lib /home/tony/dev/perl/git/perl/dist/constant/lib /home/tony/dev/perl/git/perl/cpan/version/lib /home/tony/dev/perl/git/perl/lib .
What can be done about this? -- Karl Williamson
The RT System itself - Status changed from 'new' to 'open'
On Tue\, Apr 24\, 2018 at 05:18:24PM -0700\, Tony Cook (via RT) wrote:
$ make locale.o gcc -c -DPERL_CORE -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -std=c89 -O3 -Wall -Werror=declaration-after-statement -Werror=pointer-arith -Wextra -Wc++-compat -Wwrite-strings locale.c In file included from /usr/include/ssp/stdlib.h:4:0\, from /usr/include/stdlib.h:338\, from perl.h:819\, from locale.c:49: /usr/include/ssp/wchar.h:78:1: error: conflicting types for âfgetwsâ __ssp_decl(wchar_t *\, fgetws\, (wchar_t *__restrict __buf\, int __wlen\, FILE *__restrict __fp)) ^ In file included from locale.c:54:0: /usr/include/wchar.h:228:10: note: previous declaration of âfgetwsâ was here wchar_t *fgetws (wchar_t *__restrict\, int\, __FILE *__restrict); ^
~
Do you know any of:
* what the ssp/ include files are for\, * why they have alternate definitions of fgetws etc\, * why perl redefining a bunch of stdio macros cause both versions to be included?
-- "There's something wrong with our bloody ships today\, Chatfield." -- Admiral Beatty at the Battle of Jutland\, 31st May 1916.
Dave Mitchell writes:
On Tue\, Apr 24\, 2018 at 05:18:24PM -0700\, Tony Cook (via RT) wrote:
$ make locale.o gcc -c -DPERL_CORE -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -std=c89 -O3 -Wall -Werror=declaration-after-statement -Werror=pointer-arith -Wextra -Wc++-compat -Wwrite-strings locale.c In file included from /usr/include/ssp/stdlib.h:4:0\, from /usr/include/stdlib.h:338\, from perl.h:819\, from locale.c:49: /usr/include/ssp/wchar.h:78:1: error: conflicting types for âfgetwsâ __ssp_decl(wchar_t *\, fgetws\, (wchar_t *__restrict __buf\, int __wlen\, FILE *__restrict __fp)) ^ In file included from locale.c:54:0: /usr/include/wchar.h:228:10: note: previous declaration of âfgetwsâ was here wchar_t *fgetws (wchar_t *__restrict\, int\, __FILE *__restrict); ^
~Do you know any of:
* what the ssp/ include files are for\,
That's an implementation detail of how the fortified versions of those functions are provided. AFAIK\, ssp == stack smashing protection.
* why they have alternate definitions of fgetws etc\,
That's what you get when fortification is requested.
* why perl redefining a bunch of stdio macros cause both versions to be included?
You'd have to ask someone who knows the details of how the feature test macros work\, probably Yaakov Selkowitz. And no\, I don't think you should redefine any macros that are already existing.
Regards\, Achim. -- +\<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
On 04/30/2018 12:29 PM\, Achim Gratz wrote:
Dave Mitchell writes:
On Tue\, Apr 24\, 2018 at 05:18:24PM -0700\, Tony Cook (via RT) wrote:
$ make locale.o gcc -c -DPERL_CORE -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -D_FORTIFY_SOURCE=2 -std=c89 -O3 -Wall -Werror=declaration-after-statement -Werror=pointer-arith -Wextra -Wc++-compat -Wwrite-strings locale.c In file included from /usr/include/ssp/stdlib.h:4:0\, from /usr/include/stdlib.h:338\, from perl.h:819\, from locale.c:49: /usr/include/ssp/wchar.h:78:1: error: conflicting types for âfgetwsâ __ssp_decl(wchar_t *\, fgetws\, (wchar_t *__restrict __buf\, int __wlen\, FILE *__restrict __fp)) ^ In file included from locale.c:54:0: /usr/include/wchar.h:228:10: note: previous declaration of âfgetwsâ was here wchar_t *fgetws (wchar_t *__restrict\, int\, __FILE *__restrict); ^
~Do you know any of:
* what the ssp/ include files are for\,
That's an implementation detail of how the fortified versions of those functions are provided. AFAIK\, ssp == stack smashing protection.
* why they have alternate definitions of fgetws etc\,
That's what you get when fortification is requested.
* why perl redefining a bunch of stdio macros cause both versions to be included?
You'd have to ask someone who knows the details of how the feature test macros work\, probably Yaakov Selkowitz. And no\, I don't think you should redefine any macros that are already existing.
So a potential fix for this is to not fortify the source for this platform?
Karl Williamson writes:
You'd have to ask someone who knows the details of how the feature test macros work\, probably Yaakov Selkowitz. And no\, I don't think you should redefine any macros that are already existing.
So a potential fix for this is to not fortify the source for this platform?
No\, the platform default is FORTIFY_SOURCE=2 adn I'd not veer from it for such a key piece of the whole. I haven't yet had the chance to look into what exactly happens\, but at least until the recently released 5.26.2 fortification was possible and produced no such errors; that was using the same Cygwin and compiler version I think.
Regards\, Achim. -- +\<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
On Tue\, 01 May 2018 11:56:06 -0700\, Stromeko@nexgo.de wrote:
Karl Williamson writes:
You'd have to ask someone who knows the details of how the feature test macros work\, probably Yaakov Selkowitz. And no\, I don't think you should redefine any macros that are already existing.
So a potential fix for this is to not fortify the source for this platform?
No\, the platform default is FORTIFY_SOURCE=2 adn I'd not veer from it for such a key piece of the whole. I haven't yet had the chance to look into what exactly happens\, but at least until the recently released 5.26.2 fortification was possible and produced no such errors; that was using the same Cygwin and compiler version I think.
There's two issues here:
1) cygwin declares fgetws() when stdlib.h is included\, but that name isn't reserved to the implementation unless wchar.h is included (C11 7.1.3)
So a C program that defines a fgetws() function but doesn't include wchar.h would be conforming\, but this would break if stdlib.h is included\, making cygwin non-conforming.
But I wouldn't be too surprised to find other implementations leak in similar ways.
2) Perl includes wchar.h which uses the FILE type (you're meant to #include stdio.h to use the I/O functions with the C standard[2]\, but POSIX requires wchar.h to define the FILE type)\, but nostdio.h defines a macro FILE\, using a named reserved to the implementation[1].
I think the real fix is probably to eliminate nostdio.h - its use of reserved names leads to random issues as we update perl and as platforms update their implementations.
The attached patch doesn't remove nostdio.h\, it just prevents perlio.h from including it.
Tony
[1] we use some other names more indirectly reserved\, eg. nostdio.h defines _CANNOT and __STDIO_LOADED
[2] I couldn't find wording for that\, but every I/O function synopsis in C11 that I looked at for wchar.h includes stdio.h then wchar.h
"Tony Cook via RT" writes:
1) cygwin declares fgetws() when stdlib.h is included\, but that name isn't reserved to the implementation unless wchar.h is included (C11 7.1.3)
So a C program that defines a fgetws() function but doesn't include wchar.h would be conforming\, but this would break if stdlib.h is included\, making cygwin non-conforming.
But I wouldn't be too surprised to find other implementations leak in similar ways.
For starters\, unless you request strict POSIX/ANSI behaviour from the compiler\, that line of argumentation can't be conclusive. IIRC\, you've been compiling with GNU_SOURCE at least\, so that may already poke holes in the conformance. Anyway\, whether there is a bug or not I can't really tell myself and will defer to Yaakov or Eric\, who are the Cygwin experts on these topics.
2) Perl includes wchar.h which uses the FILE type (you're meant to #include stdio.h to use the I/O functions with the C standard[2]\, but POSIX requires wchar.h to define the FILE type)\, but nostdio.h defines a macro FILE\, using a named reserved to the implementation[1].
I think the real fix is probably to eliminate nostdio.h - its use of reserved names leads to random issues as we update perl and as platforms update their implementations.
The attached patch doesn't remove nostdio.h\, it just prevents perlio.h from including it.
What is nostdio.h useful for anyway? Just asking.
Regards\, Achim. -- +\<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
On Wed\, 02 May 2018 11:56:02 -0700\, Stromeko@nexgo.de wrote:
"Tony Cook via RT" writes:
1) cygwin declares fgetws() when stdlib.h is included\, but that name isn't reserved to the implementation unless wchar.h is included (C11 7.1.3)
So a C program that defines a fgetws() function but doesn't include wchar.h would be conforming\, but this would break if stdlib.h is included\, making cygwin non-conforming.
But I wouldn't be too surprised to find other implementations leak in similar ways.
For starters\, unless you request strict POSIX/ANSI behaviour from the compiler\, that line of argumentation can't be conclusive. IIRC\, you've been compiling with GNU_SOURCE at least\, so that may already poke holes in the conformance. Anyway\, whether there is a bug or not I can't really tell myself and will defer to Yaakov or Eric\, who are the Cygwin experts on these topics.
You're probably right - I only tested within the perl build\, and didn't test a strict ANSI build.
2) Perl includes wchar.h which uses the FILE type (you're meant to #include stdio.h to use the I/O functions with the C standard[2]\, but POSIX requires wchar.h to define the FILE type)\, but nostdio.h defines a macro FILE\, using a named reserved to the implementation[1].
I think the real fix is probably to eliminate nostdio.h - its use of reserved names leads to random issues as we update perl and as platforms update their implementations.
The attached patch doesn't remove nostdio.h\, it just prevents perlio.h from including it.
What is nostdio.h useful for anyway? Just asking.
From the header itself:
/* * Strong denial of stdio - make all stdio calls (we can think of) errors */ /* This is a 1st attempt to stop other include files pulling in real \<stdio.h>. A more ambitious set of possible symbols can be found in sfio.h (inside an _cplusplus gard). It is completely pointless as we have already included it ourselves. */
I assume it was more justifiable when PerlIO was new to enforce perl's implementation using PerlIO rather than stdio.
Tony
On Tue\, May 01\, 2018 at 06:50:13PM -0700\, Tony Cook via RT wrote:
There's two issues here:
1) cygwin declares fgetws() when stdlib.h is included\, but that name isn't reserved to the implementation unless wchar.h is included (C11 7.1.3)
So a C program that defines a fgetws() function but doesn't include wchar.h would be conforming\, but this would break if stdlib.h is included\, making cygwin non-conforming.
But I wouldn't be too surprised to find other implementations leak in similar ways.
2) Perl includes wchar.h which uses the FILE type (you're meant to #include stdio.h to use the I/O functions with the C standard[2]\, but POSIX requires wchar.h to define the FILE type)\, but nostdio.h defines a macro FILE\, using a named reserved to the implementation[1].
I think the real fix is probably to eliminate nostdio.h - its use of reserved names leads to random issues as we update perl and as platforms update their implementations.
The attached patch doesn't remove nostdio.h\, it just prevents perlio.h from including it.
I propose that this ticket be moved from the 5.30.0 to the 5.32.0 blockers list.
-- This email is confidential\, and now that you have read it you are legally obliged to shoot yourself. Or shoot a lawyer\, if you prefer. If you have received this email in error\, place it in its original wrapping and return for a full refund. By opening this email\, you accept that Elvis lives.
Migrated from rt.perl.org#133152 (status was 'open')
Searchable as RT133152$