New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perlio.c: PerlIOStdio_invalidate_fileno: g++ build failure on FreeBSD-10.3 #15985
Comments
From @jkeenanIn December 2015, perlio.c's PerlIOStdio_invalidate_fileno() function ##### PATCH: Re: [perl #126847] fdclose(3) patch This patch uses the fdclose() function from FreeBSD if it The next patch will add Configure support for HAS_FDCLOSE. Inline Patchdiff --git a/perlio.c b/perlio.c
index 343c62e..69f3755 100644
--- a/perlio.c
+++ b/perlio.c
@@ -3126,7 +3126,9 @@ PerlIOStdio_invalidate_fileno(pTHX_ FILE *f)
/* XXX this could use PerlIO_canset_fileno() and
* PerlIO_set_fileno() support from Configure
*/
-# if defined(__UCLIBC__)
+# if defined(HAS_FDCLOSE)
+ return fdclose(f, NULL) == 0 ? 1 : 0;
+# elif defined(__UCLIBC__)
/* uClibc must come before glibc because it defines __GLIBC__ as
In the next commit, support for fdclose() was added to Configure and ##### Add Configure support for fdclose() for [perl #126847]. This patch also adjusts the generated files suggested by These revisions were made as a resolution to "Some time ago we add to FreeBSD a function called fdclose(3). Idea of After some discussion, Andy Dougherty created the smoke-me/andyd/fdclose In the course of working on ##### $ g++ --version $ sh ./Configure -des -Dusedevel \ In RT 131336 I have reported that when, on Oct 07 2015, we merged CPAN It turns out that the application -- three months later -- of the ##### Attachment: 55121b6.perl.V.txt # the last successful g++ build on It is interesting to note that if I configure on the same version of the ##### With gcc rather than g++, 'make' completes successfully and 'make On this version of this operating system, using g++ to configure, 'make' But it does indicate that we don't understand something about the And when we resolve it, we will probably still be getting a 'make' Thank you very much. |
From @jkeenanSummary of my perl5 (revision 5 version 23 subversion 4) configuration: Characteristics of this binary (from libperl): |
From @tonycozOn Mon, 22 May 2017 16:29:00 -0700, jkeenan@pobox.com wrote:
...
I haven't been able to reproduce this on FreeBSD 10.3 i386. Installing the gcc 4.8 port didn't add gcc/g++ to the PATH, so I had to refer to g++ as "g++48": ./Configure -des -Dusedevel -Dcc=g++48 -Dusethreads -Doptimize="-O2 -pipe -fstack-protector -fno-strict-aliasing" && make perlio.o
The warning here has the same cause as the error in the g++ build: the compiler isn't seeing the declaration for fdclose(). On my freebsd 10.3 it can be found in stdio.h: ... __BSD_VISIBLE is defined non-zero by sys/cdefs.h if none of _ANSI_SOURCE, _C99_SOURCE nor _C11_SOURCE is defined: ... I thought it might be the -ansi setting _ANSI_SOURCE, but my successful build includes that option too. Tony |
The RT System itself - Status changed from 'new' to 'open' |
From @jkeenanOn Tue, 23 May 2017 01:46:41 GMT, tonyc wrote:
On #nycbug, I was just coached through this: ##### I got those results on both 10.3 and 11.0. So, in principle, I *should* be able to use fdclose(). Thank you very much. -- |
From @jkeenanAn additional complication: As Andy Dougherty noted in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126847#txn-1382644, the critical part of perlio.c is not exercised by the test suite. In the jkeenan/131345-perlio-go-BOOM branch, I added some crude debugging statements (see attachment). A run of the test suite shows that those which are not commented out are never reached. Would anyone know how to write tests for this? Thank you very much. -- |
From @jkeenan0001-Add-diagnostics-to-determine-whether-test-suite-exer.patchFrom 8ccdf1185d1dccd7488b6251aeb6e03baa42cc5a Mon Sep 17 00:00:00 2001
From: James E Keenan <jkeenan@cpan.org>
Date: Tue, 23 May 2017 08:38:00 -0400
Subject: [PATCH] Add diagnostics to determine whether test suite exercises
code.
One 'fprintf' statement is reached and generates errors in t/io/error.t. It
is commented out.
The other 'fprintf' statements are uncommented -- but never reached. This
impedes our ability to validate any possible solution for
https://rt.perl.org/Ticket/Display.html?id=131345.
---
perlio.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/perlio.c b/perlio.c
index e9d3700..3717408 100644
--- a/perlio.c
+++ b/perlio.c
@@ -3175,6 +3175,7 @@ PerlIOStdio_invalidate_fileno(pTHX_ FILE *f)
* PerlIO_set_fileno() support from Configure
*/
# if defined(HAS_FDCLOSE)
+ fprintf(stderr, "BOOM! BOOM! BOOM!\n");
return fdclose(f, NULL) == 0 ? 1 : 0;
# elif defined(__UCLIBC__)
/* uClibc must come before glibc because it defines __GLIBC__ as well. */
@@ -3251,6 +3252,11 @@ IV
PerlIOStdio_close(pTHX_ PerlIO *f)
{
FILE * const stdio = PerlIOSelf(f, PerlIOStdio)->stdio;
+ /* The following line demonstrates that the test suite exercises
+ * PerlIOStdio_close(). In the process test failures are generated in
+ * t/io/error.t.
+ */
+ /* fprintf(stderr, "ROOM! ROOM! ROOM!\n"); */
if (!stdio) {
errno = EBADF;
return -1;
@@ -3271,6 +3277,8 @@ PerlIOStdio_close(pTHX_ PerlIO *f)
*/
int optval;
Sock_size_t optlen = sizeof(int);
+ /* Line below is not exercised by test suite. */
+ fprintf(stderr, "LOOM! LOOM! LOOM!\n");
if (getsockopt(fd, SOL_SOCKET, SO_TYPE, (void *) &optval, &optlen) == 0)
invalidate = 1;
#endif
@@ -3317,6 +3325,8 @@ PerlIOStdio_close(pTHX_ PerlIO *f)
*/
result = PerlIO_flush(f);
SAVE_ERRNO;
+ /* Line below is not exercised by test suite. */
+ fprintf(stderr, "DOOM! DOOM! DOOM!\n");
invalidate = PerlIOStdio_invalidate_fileno(aTHX_ stdio);
if (!invalidate) {
dupfd = PerlLIO_dup(fd);
--
2.7.4
|
From @jkeenanAttaching a patch submitted by Andy Dougherty. Not yet tested. |
From @jkeenan131345-fbsd-11-detect-gpp.diffdiff --git a/hints/freebsd.sh b/hints/freebsd.sh
index e5ecea8..47ad3ec 100644
--- a/hints/freebsd.sh
+++ b/hints/freebsd.sh
@@ -320,3 +320,13 @@ d_printf_format_null='undef'
# As of 10.3-RELEASE FreeBSD. See [perl #128867]
d_uselocale='undef'
+
+# First noticed in 11.0-CURRENT with g++-4.8.5:
+# If using g++, the Configure scan for dlopen() fails.
+# Easier for now to just to forcibly set it.
+case "$cc" in
+*g++*)
+ d_dlopen='define'
+ ;;
+esac
+
|
From [Unknown Contact. See original ticket]Attaching a patch submitted by Andy Dougherty. Not yet tested. |
From @tonycozOn Mon, 22 May 2017 19:57:06 -0700, jkeenan wrote:
The obvious thing to test here is whether you can call it: #include <stdio.h> void f(void) { int main(void) $ g++48 -o fdclose fdclose.c If you can then it's some other header or option setting one of the _*_SOURCE macros. The gcc 4.8 port here uses modified versions of some of the standard library headers, you might want to check if any of those define the symbols, though they don't here. To get a list of the system headers used for perlio.c mention these symbols, after Configure / makedepend: grep '^perlio.*/' makefile | sed 's/^.*: //' | xargs grep -E '_(ANSI|C11|C99)_SOURCE' and see if any of those define those symbols (they don't here). Tony |
From @jkeenanOn Wed, 24 May 2017 01:10:43 GMT, tonyc wrote:
[cpp] $ uname -mrs [cpp] $ g++ --version | head -2 [cpp] $ cat fdclose.cpp void f(void) { int main(void) [cpp] $ g++ -o fdclose fdclose.cpp I know little C++. What does this suggest? Thank you very much. -- |
From @khwilliamsonOn 5/23/2017 7:45 PM, James E Keenan via RT wrote:
It means that fdclose is not on the system, or is in a different header |
From @jkeenanOn Wed, 24 May 2017 02:13:18 GMT, public@khwilliamson.com wrote:
Hmmm. It appears that we were misinformed in RT #126847 as to the availability of fdlose() on FreeBSD earlier than 11.0. # On FreeBSD-10.3 [cpp] $ uname -mrs # On FreeBSD-11.0 [cpp] $ uname -mrs ##### FreeBSD 11.0 July 4, 2015 -- |
From @tonycozOn Tue, May 23, 2017 at 07:34:49PM -0700, James E Keenan via RT wrote:
$ uname -mrs NAME LIBRARY SYNOPSIS int int It seems to have been backported to the 10.x branch: https://svnweb.freebsd.org/base?view=revision&revision=291602 https://github.com/freebsd/freebsd/blame/releng/10.3/lib/libc/stdio/fclose.c#L88 I suspect your 4.8 gcc build is using an old "fixed" version of the /usr/local/lib/gcc48/gcc/i386-portbld-freebsd10.3/4.8.5/include-fixed/stdio.h while the system stdio.h is: /usr/include/stdio.h If they both exist on your system could you grep both for "fdclose"? They both declare fdclose() here: $ grep fdclose /usr/local/lib/gcc48/gcc/i386-portbld-freebsd10.3/4.8.5/include-fixed/stdio.h If the first doesn't exist, see what stdio.h perlio$(OBJ_EXT) depends $ grep perlio.*/stdio.h makefile Tony |
From @jkeenanOn Wed, 24 May 2017 04:16:21 GMT, tonyc wrote:
[jkeenan] $ uname -mrs [jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs ls -l [jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs grep -n fdclose
[perl] $ grep perlio.*/stdio.h makefile
-- |
From @tonycozOn Wed, 24 May 2017 05:12:46 -0700, jkeenan wrote:
So it looks like you're using the ("fixed") 10.1 headers rather than the 10.3 headers. You might want to run mkheaders to update them: https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Fixed-Headers.html Tony |
From @jkeenanOn Thu, 25 May 2017 00:38:27 GMT, tonyc wrote:
Tony, that strikes me as being not the right way to go. In effect, you're saying that the operating system -- or at least its userland -- must change because, at this point in time, Configure is unable to discover certain facts about the OS. I believe that it is Configure that ought to change so as to better understand the OS and its userland. My VMs are set up to work with images of FreeBSD supplied by the FreeBSD project. I'm not interested in tinkering with the OS or its userland *at all*. I want to treat them as givens to which Perl must adapt. (That, of course, is the way that the vast majority of Perl users treat their OSes.) Perl is what we are responsible for and what we control. In this case, I think we have to improve Configure so that it knows that it may have to look in more than one location for its headers. Thank you very much. -- |
From @tonycozOn Thu, 01 Jun 2017 18:33:09 -0700, jkeenan wrote:
It is discoving certain facts about the OS, unfortunately the 10.1 headers you're using are breaking C++ builds. Running mkheaders again after installing a new system version is explicity called out by the GCC maintainers: "If you update the system's header files, such as by installing a new system version, the fixed header files of GCC are not automatically updated. They can be updated using the mkheaders script installed in libexecdir/gcc/target/version/install-tools/. "
That isn't the problem here, the problem you have is g++ gives priority to its "fixed" headers, overriding the system provided headers. The closest we could get is to try and compile a program using each function using the headers needed for that function, but that would require a massive re-work of the code that looks for functions in the general case: the csym macro would need to include those headers and every use of csym (and inlibc) would need to provide a list of headers. This is a lot of work to detect broken systems. Tony |
From @jkeenanOn Mon, 05 Jun 2017 02:05:59 GMT, tonyc wrote:
So today I finally got up the nerve to run mkheaders in my FreeBSD-10.3 VM. ##### I breathed a sigh of relief when it ran silently. I then configured and built with clang -- the FreeBSD default C-compiler -- and then with each of gcc and g++. On blead: $ gcc_configure && make test_prep $ gpp_configure && make test_prep That last result was what we were hoping for: blead built when compiled with g++ on FreeBSD-10.3. make test_harness subsequently PASSed as well. Similar results for perl-5.24.1 (by tag): make test_harness PASSed here as well. I subsequently did a smoke test run and, with the exception of one often slow-running test, got good results there. See: http://perl5.test-smoke.org/report/56185. No change needed in Perl. Marking ticket Resolved. Thank you very much. -- |
@jkeenan - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#131345 (status was 'resolved')
Searchable as RT131345$
The text was updated successfully, but these errors were encountered: