Skip to content
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

Closed
p5pRT opened this issue May 22, 2017 · 23 comments
Closed

perlio.c: PerlIOStdio_invalidate_fileno: g++ build failure on FreeBSD-10.3 #15985

p5pRT opened this issue May 22, 2017 · 23 comments

Comments

@p5pRT
Copy link

p5pRT commented May 22, 2017

Migrated from rt.perl.org#131345 (status was 'resolved')

Searchable as RT131345$

@p5pRT
Copy link
Author

p5pRT commented May 22, 2017

From @jkeenan

In December 2015, perlio.c's PerlIOStdio_invalidate_fileno() function
was modified to take advantage of the fdclose() function which was had
become available in FreeBSD as of FreeBSD-10.2.

#####
$ git show --format=fuller 36b1c89 |cat
commit 36b1c89
Author​: Andy Dougherty <doughera@​lafayette.edu>
AuthorDate​: Tue Dec 29 22​:47​:42 2015 -0500
Commit​: Andy Dougherty <doughera@​lafayette.edu>
CommitDate​: Mon Jan 4 11​:10​:33 2016 -0500

  PATCH​: Re​: [perl #126847] fdclose(3) patch

  This patch uses the fdclose() function from FreeBSD if it
  is available. It is based on the original patch supplied
  by Mariusz Zaborski <oshogbo@​FreeBSD.org> in the RT ticket.

  The next patch will add Configure support for HAS_FDCLOSE.

Inline Patch
diff --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 
well. */   f\->\_\_filedes = \-1;   return 1; \#\#\#\#\#

In the next commit, support for fdclose() was added to Configure and
related files.

#####
commit 8b8c6ab
Author​: Andy Dougherty <doughera@​lafayette.edu>
AuthorDate​: Tue Dec 29 22​:58​:51 2015 -0500
Commit​: Andy Dougherty <doughera@​lafayette.edu>
CommitDate​: Mon Jan 4 11​:10​:34 2016 -0500

  Add Configure support for fdclose() for [perl #126847].

  This patch also adjusts the generated files suggested by
  Porting/checkcfgvar.pl.
#####

These revisions were made as a resolution to
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126847, in which Mariusz
Zaborski wrote​:

"Some time ago we add to FreeBSD a function called fdclose(3). Idea of
this function is to free FILE structure but leave/return underlining
descriptor. This is *cleaner* way instead messing in FILE structure."

After some discussion, Andy Dougherty created the smoke-me/andyd/fdclose
branch to smoke-test the patches that were ultimately merged into blead.
  It should be noted that at that time there was no one smoke-testing on
any version of FreeBSD. (See​:
http​://perl.develop-help.com/?b=smoke-me%2Fandyd%2Ffdclose) So the
patches were never tested at all on the OS for which they were
originally suggested. All appeared to be well and on Jan 18 2016 RT
126847 was marked Resolved (by me, AAMOF).

In the course of working on
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131336 I have had occasion to
try to configure, build and test perl on FreeBSD-10.3 using g++ as the
C-compiler. This is the environment and how I configure​:

#####
$ uname -mrs
FreeBSD 10.3-RELEASE amd64

$ g++ --version
g++ (FreeBSD Ports Collection) 4.8.5

$ sh ./Configure -des -Dusedevel \
  -Duseithreads \
  -Doptimize="-O2 -pipe -fstack-protector -fno-strict-aliasing" \
  -Dcc="g++"
#####

In RT 131336 I have reported that when, on Oct 07 2015, we merged CPAN
distribution Encode version 2.78 into blead, we became unable to build
perl using g++ on FreeBSD-10.3. That failure occurs relatively late in
the 'make' process.

It turns out that the application -- three months later -- of the
fdclose-related patches caused a 'make' to fail during a g++ build on
FreeBSD-10.3 *much earlier* during the 'make' process. As of commit
8b8c6ab, 'make' fails in a g++ build on
FreeBSD-10.3 at the following point​:

#####
g++ -c -DPERL_CORE -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv
-fno-strict-aliasing -pipe -fstack-pro
tector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2 -ansi -O2 -pipe
-fstack-protector -fno-strict-al
iasing -Wall -Werror=declaration-after-statement -Wextra -Wwrite-strings
perlio.c
perlio.c​: In function 'int
PerlIOStdio_invalidate_fileno(PerlInterpreter*, FILE*)'​:
perlio.c​:3130​:27​: error​: 'fdclose' was not declared in this scope
  return fdclose(f, NULL) == 0 ? 1 : 0;
  ^
perlio.c​:3200​:1​: warning​: control reaches end of non-void function
[-Wreturn-type]
  }
  ^
*** Error code 1
#####

Attachment​: 55121b6.perl.V.txt # the last successful g++ build on
FreeBSD-10.3
Attachment​: gpp_configure.8b8c6ab.config.sh
Attachment​: gpp_configure.make.8b8c6ab.log

It is interesting to note that if I configure on the same version of the
same OS at the same git revision but use gcc instead of g++, I only get
a warning, not an error​:

#####
gcc -c -DPERL_CORE -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv
-fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include
-D_FORTIFY_SOURCE=2 -std=c89 -O2 -pipe -fstack-protector
-fno-strict-aliasing -Wall -Werror=declaration-after-statement -Wextra
-Wc++-compat -Wwrite-strings perlio.c
perlio.c​: In function 'PerlIOStdio_invalidate_fileno'​:
perlio.c​:3130​:5​: warning​: implicit declaration of function 'fdclose'
[-Wimplicit-function-declaration]
  return fdclose(f, NULL) == 0 ? 1 : 0;
#####

With gcc rather than g++, 'make' completes successfully and 'make
test_harness' PASSes.

On this version of this operating system, using g++ to configure, 'make'
continues to fail in the same way to this day. As noted in RT 131336,
the default C-compiler on FreeBSD is clang, not g++ and not gcc. Hence,
this defect isn't seriously impeding anyone from using perl on FreeBSD-10.3.

But it does indicate that we don't understand something about the
interaction of g++ and fdclose. This should be investigated in the
5.27-5.28 development cycle.

And when we resolve it, we will probably still be getting a 'make'
failure with g++ on FreeBSD-10.3 -- the failure reported in RT 131336,
which now has a dependency on this new RT!

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented May 22, 2017

From @jkeenan

Summary of my perl5 (revision 5 version 23 subversion 4) configuration​:
  Commit id​: 55121b6
  Platform​:
  osname=freebsd, osvers=10.3-release, archname=amd64-freebsd-thread-multi
  uname='freebsd localhost 10.3-release freebsd 10.3-release #0 r297264​: fri mar 25 02​:10​:02 utc 2016 root@​releng1.nyi.freebsd.org​:usrobjusrsrcsysgeneric amd64 '
  config_args='-des -Dusedevel -Duseithreads -Doptimize=-O2 -pipe -fstack-protector -fno-strict-aliasing -Dcc=g++'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='g++', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2',
  optimize='-O2 -pipe -fstack-protector -fno-strict-aliasing',
  cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
  ccversion='', gccversion='4.8.5', 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='ld', ldflags ='-pthread -Wl,-E -fstack-protector-strong -L/usr/local/lib'
  libpth=/usr/lib /usr/local/lib /usr/local/lib/gcc48/include/c++/ /usr/local/lib/gcc48/include/c++//x86_64-portbld-freebsd10.1 /usr/local/lib/gcc48/include/c++//backward /usr/local/lib /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.5/include-fixed /usr/lib
  libs=-lpthread -lgdbm -lm -lcrypt -lutil
  perllibs=-lpthread -lgdbm -lm -lcrypt -lutil
  libc=, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_none.xs, dlext=none, d_dlsymun=undef, ccdlflags=''
  cccdlflags='-DPIC -fPIC', lddlflags=''

Characteristics of this binary (from libperl)​:
  Compile-time options​: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
  PERL_COPY_ON_WRITE PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
  PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
  PERL_PRESERVE_IVUV PERL_USE_DEVEL 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
  Built under freebsd
  Compiled at May 20 2017 21​:02​:13
  %ENV​:
  PERL_WORKDIR="/home/jkeenan/gitwork/perl"
  @​INC​:
  lib
  /usr/local/lib/perl5/site_perl/5.23.4/amd64-freebsd-thread-multi
  /usr/local/lib/perl5/site_perl/5.23.4
  /usr/local/lib/perl5/5.23.4/amd64-freebsd-thread-multi
  /usr/local/lib/perl5/5.23.4
  .

@p5pRT
Copy link
Author

p5pRT commented May 22, 2017

@p5pRT
Copy link
Author

p5pRT commented May 22, 2017

@p5pRT
Copy link
Author

p5pRT commented May 23, 2017

From @tonycoz

On Mon, 22 May 2017 16​:29​:00 -0700, jkeenan@​pobox.com wrote​:

#####
$ uname -mrs
FreeBSD 10.3-RELEASE amd64

$ g++ --version
g++ (FreeBSD Ports Collection) 4.8.5

$ sh ./Configure -des -Dusedevel \
-Duseithreads \
-Doptimize="-O2 -pipe -fstack-protector -fno-strict-aliasing" \
-Dcc="g++"
#####

...

#####
g++ -c -DPERL_CORE -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv
-fno-strict-aliasing -pipe -fstack-pro
tector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2 -ansi -O2 -pipe
-fstack-protector -fno-strict-al
iasing -Wall -Werror=declaration-after-statement -Wextra -Wwrite-strings
perlio.c
perlio.c​: In function 'int
PerlIOStdio_invalidate_fileno(PerlInterpreter*, FILE*)'​:
perlio.c​:3130​:27​: error​: 'fdclose' was not declared in this scope
return fdclose(f, NULL) == 0 ? 1 : 0;
^
perlio.c​:3200​:1​: warning​: control reaches end of non-void function
[-Wreturn-type]
}
^
*** Error code 1

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

#####
gcc -c -DPERL_CORE -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv
-fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include
-D_FORTIFY_SOURCE=2 -std=c89 -O2 -pipe -fstack-protector
-fno-strict-aliasing -Wall -Werror=declaration-after-statement -Wextra
-Wc++-compat -Wwrite-strings perlio.c
perlio.c​: In function 'PerlIOStdio_invalidate_fileno'​:
perlio.c​:3130​:5​: warning​: implicit declaration of function 'fdclose'
[-Wimplicit-function-declaration]
return fdclose(f, NULL) == 0 ? 1 : 0;
#####

With gcc rather than g++, 'make' completes successfully and 'make
test_harness' PASSes.

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​:

...
/*
* Routines that are purely local.
*/
#if __BSD_VISIBLE
int asprintf(char **, const char *, ...) __printflike(2, 3);
char *ctermid_r(char *);
void fcloseall(void);
int fdclose(FILE *, int *);
char *fgetln(FILE *, size_t *);
const char *fmtcheck(const char *, const char *) __format_arg(2);
int fpurge(FILE *);
void setbuffer(FILE *, char *, int);
...

__BSD_VISIBLE is defined non-zero by sys/cdefs.h if none of _ANSI_SOURCE, _C99_SOURCE nor _C11_SOURCE is defined​:

...
#if defined(_ANSI_SOURCE) /* Hide almost everything. */
#define __POSIX_VISIBLE 0
#define __XSI_VISIBLE 0
#define __BSD_VISIBLE 0
#define __ISO_C_VISIBLE 1990
#elif defined(_C99_SOURCE) /* Localism to specify strict C99 env. */
#define __POSIX_VISIBLE 0
#define __XSI_VISIBLE 0
#define __BSD_VISIBLE 0
#define __ISO_C_VISIBLE 1999
#elif defined(_C11_SOURCE) /* Localism to specify strict C11 env. */
#define __POSIX_VISIBLE 0
#define __XSI_VISIBLE 0
#define __BSD_VISIBLE 0
#define __ISO_C_VISIBLE 2011
#else /* Default environment​: show everything. */
#define __POSIX_VISIBLE 200809
#define __XSI_VISIBLE 700
#define __BSD_VISIBLE 1
#define __ISO_C_VISIBLE 2011
#endif
#endif
...

I thought it might be the -ansi setting _ANSI_SOURCE, but my successful build includes that option too.

Tony

@p5pRT
Copy link
Author

p5pRT commented May 23, 2017

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented May 23, 2017

From @jkeenan

On Tue, 23 May 2017 01​:46​:41 GMT, tonyc wrote​:

On Mon, 22 May 2017 16​:29​:00 -0700, jkeenan@​pobox.com wrote​:

#####
$ uname -mrs
FreeBSD 10.3-RELEASE amd64

$ g++ --version
g++ (FreeBSD Ports Collection) 4.8.5

$ sh ./Configure -des -Dusedevel \
-Duseithreads \
-Doptimize="-O2 -pipe -fstack-protector -fno-strict-
aliasing" \
-Dcc="g++"
#####

...

#####
g++ -c -DPERL_CORE -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv
-fno-strict-aliasing -pipe -fstack-pro
tector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2 -ansi -O2
-pipe
-fstack-protector -fno-strict-al
iasing -Wall -Werror=declaration-after-statement -Wextra -Wwrite-
strings
perlio.c
perlio.c​: In function 'int
PerlIOStdio_invalidate_fileno(PerlInterpreter*, FILE*)'​:
perlio.c​:3130​:27​: error​: 'fdclose' was not declared in this scope
return fdclose(f, NULL) == 0 ? 1 : 0;
^
perlio.c​:3200​:1​: warning​: control reaches end of non-void function
[-Wreturn-type]
}
^
*** Error code 1

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

#####
gcc -c -DPERL_CORE -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv
-fno-strict-aliasing -pipe -fstack-protector-strong
-I/usr/local/include
-D_FORTIFY_SOURCE=2 -std=c89 -O2 -pipe -fstack-protector
-fno-strict-aliasing -Wall -Werror=declaration-after-statement
-Wextra
-Wc++-compat -Wwrite-strings perlio.c
perlio.c​: In function 'PerlIOStdio_invalidate_fileno'​:
perlio.c​:3130​:5​: warning​: implicit declaration of function 'fdclose'
[-Wimplicit-function-declaration]
return fdclose(f, NULL) == 0 ? 1 : 0;
#####

With gcc rather than g++, 'make' completes successfully and 'make
test_harness' PASSes.

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​:

...
/*
* Routines that are purely local.
*/
#if __BSD_VISIBLE
int asprintf(char **, const char *, ...) __printflike(2, 3);
char *ctermid_r(char *);
void fcloseall(void);
int fdclose(FILE *, int *);
char *fgetln(FILE *, size_t *);
const char *fmtcheck(const char *, const char *) __format_arg(2);
int fpurge(FILE *);
void setbuffer(FILE *, char *, int);
...

__BSD_VISIBLE is defined non-zero by sys/cdefs.h if none of
_ANSI_SOURCE, _C99_SOURCE nor _C11_SOURCE is defined​:

...
#if defined(_ANSI_SOURCE) /* Hide almost everything. */
#define __POSIX_VISIBLE 0
#define __XSI_VISIBLE 0
#define __BSD_VISIBLE 0
#define __ISO_C_VISIBLE 1990
#elif defined(_C99_SOURCE) /* Localism to specify strict C99 env.
*/
#define __POSIX_VISIBLE 0
#define __XSI_VISIBLE 0
#define __BSD_VISIBLE 0
#define __ISO_C_VISIBLE 1999
#elif defined(_C11_SOURCE) /* Localism to specify strict C11 env.
*/
#define __POSIX_VISIBLE 0
#define __XSI_VISIBLE 0
#define __BSD_VISIBLE 0
#define __ISO_C_VISIBLE 2011
#else /* Default environment​: show
everything. */
#define __POSIX_VISIBLE 200809
#define __XSI_VISIBLE 700
#define __BSD_VISIBLE 1
#define __ISO_C_VISIBLE 2011
#endif
#endif
...

I thought it might be the -ansi setting _ANSI_SOURCE, but my
successful build includes that option too.

Tony

On #nycbug, I was just coached through this​:

#####
[perl] $ cat foo.cc
#include <stdio.h>
int main(void)
{
  printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
  return 0;
}
[perl] $ g++ foo.cc -o foo
[perl] $ ./foo
__BSD_VISIBLE​: 1
#####

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.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented May 23, 2017

From @jkeenan

An 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.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented May 23, 2017

From @jkeenan

0001-Add-diagnostics-to-determine-whether-test-suite-exer.patch
From 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

@p5pRT
Copy link
Author

p5pRT commented May 24, 2017

From @jkeenan

Attaching a patch submitted by Andy Dougherty. Not yet tested.

@p5pRT
Copy link
Author

p5pRT commented May 24, 2017

From @jkeenan

131345-fbsd-11-detect-gpp.diff
diff --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
+

@p5pRT
Copy link
Author

p5pRT commented May 24, 2017

From [Unknown Contact. See original ticket]

Attaching a patch submitted by Andy Dougherty. Not yet tested.

@p5pRT
Copy link
Author

p5pRT commented May 24, 2017

From @tonycoz

On Mon, 22 May 2017 19​:57​:06 -0700, jkeenan wrote​:

On #nycbug, I was just coached through this​:

#####
[perl] $ cat foo.cc
#include <stdio.h>
int main(void)
{
printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
return 0;
}
[perl] $ g++ foo.cc -o foo
[perl] $ ./foo
__BSD_VISIBLE​: 1
#####

I got those results on both 10.3 and 11.0. So, in principle, I
*should* be able to use fdclose().

The obvious thing to test here is whether you can call it​:

#include <stdio.h>

void f(void) {
  (void)fdclose(stdout, NULL);
}

int main(void)
{
  printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
  return 0;
}

$ 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

@p5pRT
Copy link
Author

p5pRT commented May 24, 2017

From @jkeenan

On Wed, 24 May 2017 01​:10​:43 GMT, tonyc wrote​:

On Mon, 22 May 2017 19​:57​:06 -0700, jkeenan wrote​:

On #nycbug, I was just coached through this​:

#####
[perl] $ cat foo.cc
#include <stdio.h>
int main(void)
{
printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
return 0;
}
[perl] $ g++ foo.cc -o foo
[perl] $ ./foo
__BSD_VISIBLE​: 1
#####

I got those results on both 10.3 and 11.0. So, in principle, I
*should* be able to use fdclose().

The obvious thing to test here is whether you can call it​:

#include <stdio.h>

void f(void) {
(void)fdclose(stdout, NULL);
}

int main(void)
{
printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
return 0;
}

$ g++48 -o fdclose fdclose.c
$

[cpp] $ uname -mrs
FreeBSD 10.3-RELEASE amd64

[cpp] $ g++ --version | head -2
g++ (FreeBSD Ports Collection) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.

[cpp] $ cat fdclose.cpp
#include <stdio.h>

void f(void) {
  (void)fdclose(stdout, NULL);
}

int main(void)
{
  printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
  return 0;
}

[cpp] $ g++ -o fdclose fdclose.cpp
fdclose.cpp​: In function 'void f()'​:
fdclose.cpp​:4​:31​: error​: 'fdclose' was not declared in this scope
  (void)fdclose(stdout, NULL);
  ^

I know little C++. What does this suggest?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented May 24, 2017

From @khwilliamson

On 5/23/2017 7​:45 PM, James E Keenan via RT wrote​:

On Wed, 24 May 2017 01​:10​:43 GMT, tonyc wrote​:

On Mon, 22 May 2017 19​:57​:06 -0700, jkeenan wrote​:

On #nycbug, I was just coached through this​:

#####
[perl] $ cat foo.cc
#include <stdio.h>
int main(void)
{
printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
return 0;
}
[perl] $ g++ foo.cc -o foo
[perl] $ ./foo
__BSD_VISIBLE​: 1
#####

I got those results on both 10.3 and 11.0. So, in principle, I
*should* be able to use fdclose().

The obvious thing to test here is whether you can call it​:

#include <stdio.h>

void f(void) {
(void)fdclose(stdout, NULL);
}

int main(void)
{
printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
return 0;
}

$ g++48 -o fdclose fdclose.c
$

[cpp] $ uname -mrs
FreeBSD 10.3-RELEASE amd64

[cpp] $ g++ --version | head -2
g++ (FreeBSD Ports Collection) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.

[cpp] $ cat fdclose.cpp
#include <stdio.h>

void f(void) {
(void)fdclose(stdout, NULL);
}

int main(void)
{
printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
return 0;
}

[cpp] $ g++ -o fdclose fdclose.cpp
fdclose.cpp​: In function 'void f()'​:
fdclose.cpp​:4​:31​: error​: 'fdclose' was not declared in this scope
(void)fdclose(stdout, NULL);
^

I know little C++. What does this suggest?

Thank you very much.

It means that fdclose is not on the system, or is in a different header
file than <stdio.h>

@p5pRT
Copy link
Author

p5pRT commented May 24, 2017

From @jkeenan

On Wed, 24 May 2017 02​:13​:18 GMT, public@​khwilliamson.com wrote​:

On 5/23/2017 7​:45 PM, James E Keenan via RT wrote​:

On Wed, 24 May 2017 01​:10​:43 GMT, tonyc wrote​:

On Mon, 22 May 2017 19​:57​:06 -0700, jkeenan wrote​:

On #nycbug, I was just coached through this​:

#####
[perl] $ cat foo.cc
#include <stdio.h>
int main(void)
{
printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
return 0;
}
[perl] $ g++ foo.cc -o foo
[perl] $ ./foo
__BSD_VISIBLE​: 1
#####

I got those results on both 10.3 and 11.0. So, in principle, I
*should* be able to use fdclose().

The obvious thing to test here is whether you can call it​:

#include <stdio.h>

void f(void) {
(void)fdclose(stdout, NULL);
}

int main(void)
{
printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
return 0;
}

$ g++48 -o fdclose fdclose.c
$

[cpp] $ uname -mrs
FreeBSD 10.3-RELEASE amd64

[cpp] $ g++ --version | head -2
g++ (FreeBSD Ports Collection) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.

[cpp] $ cat fdclose.cpp
#include <stdio.h>

void f(void) {
(void)fdclose(stdout, NULL);
}

int main(void)
{
printf("__BSD_VISIBLE​: %d\n", __BSD_VISIBLE);
return 0;
}

[cpp] $ g++ -o fdclose fdclose.cpp
fdclose.cpp​: In function 'void f()'​:
fdclose.cpp​:4​:31​: error​: 'fdclose' was not declared in this scope
(void)fdclose(stdout, NULL);
^

I know little C++. What does this suggest?

Thank you very much.

It means that fdclose is not on the system, or is in a different header
file than <stdio.h>

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
FreeBSD 10.3-RELEASE amd64
[cpp] $ man fdclose
No manual entry for fdclose

# On FreeBSD-11.0

[cpp] $ uname -mrs
FreeBSD 11.0-RELEASE-p1 amd64
[cpp] $ man fdclose
# ... a nice man page like https://www.freebsd.org/cgi/man.cgi?query=fdclose&manpath=FreeBSD+11.0-RELEASE+and+Ports
# ... which clearly states​:

#####
The fdclose() function first appeared in FreeBSD 11.0.

FreeBSD 11.0 July 4, 2015
#####

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented May 24, 2017

From @tonycoz

On Tue, May 23, 2017 at 07​:34​:49PM -0700, James E Keenan via RT wrote​:

# On FreeBSD-11.0

[cpp] $ uname -mrs
FreeBSD 11.0-RELEASE-p1 amd64
[cpp] $ man fdclose
# ... a nice man page like https://www.freebsd.org/cgi/man.cgi?query=fdclose&manpath=FreeBSD+11.0-RELEASE+and+Ports
# ... which clearly states​:

#####
The fdclose() function first appeared in FreeBSD 11.0.

FreeBSD 11.0 July 4, 2015
#####

$ uname -mrs
FreeBSD 10.3-RELEASE i386
$ man fclose | head -16
FCLOSE(3) FreeBSD Library Functions Manual FCLOSE(3)

NAME
  fclose, fdclose, fcloseall -- close a stream

LIBRARY
  Standard C Library (libc, -lc)

SYNOPSIS
  #include <stdio.h>

  int
  fclose(FILE *stream);

  int
  fdclose(FILE *stream, int *fdp);

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
stdio headers, on my system the stdio.h used is at​:

/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
int fdclose(FILE *, int *);
$ grep fdclose /usr/include/stdio.h
int fdclose(FILE *, int *);

If the first doesn't exist, see what stdio.h perlio$(OBJ_EXT) depends
on in makefile (not Makefile)

$ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/i386-portbld-freebsd10.3/4.8.5/include-fixed/stdio.h

Tony

@p5pRT
Copy link
Author

p5pRT commented May 24, 2017

From @jkeenan

On Wed, 24 May 2017 04​:16​:21 GMT, tonyc wrote​:

On Tue, May 23, 2017 at 07​:34​:49PM -0700, James E Keenan via RT wrote​:

# On FreeBSD-11.0

[cpp] $ uname -mrs
FreeBSD 11.0-RELEASE-p1 amd64
[cpp] $ man fdclose
# ... a nice man page like
https://www.freebsd.org/cgi/man.cgi?query=fdclose&manpath=FreeBSD+11.0-
RELEASE+and+Ports
# ... which clearly states​:

#####
The fdclose() function first appeared in FreeBSD 11.0.

FreeBSD 11.0 July 4, 2015
#####

$ uname -mrs
FreeBSD 10.3-RELEASE i386
$ man fclose | head -16
FCLOSE(3) FreeBSD Library Functions Manual
FCLOSE(3)

NAME
fclose, fdclose, fcloseall -- close a stream

LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <stdio.h>

int
fclose(FILE *stream);

int
fdclose(FILE *stream, int *fdp);

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
stdio headers, on my system the stdio.h used is at​:

/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
int fdclose(FILE *, int *);
$ grep fdclose /usr/include/stdio.h
int fdclose(FILE *, int *);

[jkeenan] $ uname -mrs
FreeBSD 10.3-RELEASE amd64

[jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs ls -l
-r--r--r-- 1 root wheel 3612 Mar 24 2016 /usr/include/ssp/stdio.h
-r--r--r-- 1 root wheel 16905 Mar 24 2016 /usr/include/stdio.h
-rw-r--r-- 1 root wheel 17249 Jul 27 2016 /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.5/include-fixed/stdio.h
-rw-r--r-- 1 root wheel 3473 Jul 27 2016 /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.5/include/ssp/stdio.h
-rw-r--r-- 1 root wheel 1209 Jul 27 2016 /usr/local/lib/gcc48/include/c++/tr1/stdio.h

[jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs grep -n fdclose
/usr/include/stdio.h​:402​:int fdclose(FILE *, int *);

If the first doesn't exist, see what stdio.h perlio$(OBJ_EXT) depends
on in makefile (not Makefile)

$ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/i386-portbld-
freebsd10.3/4.8.5/include-fixed/stdio.h

[perl] $ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.5/include-fixed/stdio.h

Tony

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented May 25, 2017

From @tonycoz

On Wed, 24 May 2017 05​:12​:46 -0700, jkeenan wrote​:

On Wed, 24 May 2017 04​:16​:21 GMT, tonyc wrote​:

I suspect your 4.8 gcc build is using an old "fixed" version of the
stdio headers, on my system the stdio.h used is at​:

/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
int fdclose(FILE *, int *);
$ grep fdclose /usr/include/stdio.h
int fdclose(FILE *, int *);

[jkeenan] $ uname -mrs
FreeBSD 10.3-RELEASE amd64

[jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs ls -l
-r--r--r-- 1 root wheel 3612 Mar 24 2016 /usr/include/ssp/stdio.h
-r--r--r-- 1 root wheel 16905 Mar 24 2016 /usr/include/stdio.h
-rw-r--r-- 1 root wheel 17249 Jul 27 2016
/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.5/include-
fixed/stdio.h
-rw-r--r-- 1 root wheel 3473 Jul 27 2016
/usr/local/lib/gcc48/gcc/x86_64-portbld-
freebsd10.1/4.8.5/include/ssp/stdio.h
-rw-r--r-- 1 root wheel 1209 Jul 27 2016
/usr/local/lib/gcc48/include/c++/tr1/stdio.h

[jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs grep -n
fdclose
/usr/include/stdio.h​:402​:int fdclose(FILE *, int *);

If the first doesn't exist, see what stdio.h perlio$(OBJ_EXT) depends
on in makefile (not Makefile)

$ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/i386-portbld-
freebsd10.3/4.8.5/include-fixed/stdio.h

[perl] $ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/x86_64-portbld-
freebsd10.1/4.8.5/include-fixed/stdio.h

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

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2017

From @jkeenan

On Thu, 25 May 2017 00​:38​:27 GMT, tonyc wrote​:

On Wed, 24 May 2017 05​:12​:46 -0700, jkeenan wrote​:

On Wed, 24 May 2017 04​:16​:21 GMT, tonyc wrote​:

I suspect your 4.8 gcc build is using an old "fixed" version of the
stdio headers, on my system the stdio.h used is at​:

/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
int fdclose(FILE *, int *);
$ grep fdclose /usr/include/stdio.h
int fdclose(FILE *, int *);

[jkeenan] $ uname -mrs
FreeBSD 10.3-RELEASE amd64

[jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs ls -l
-r--r--r-- 1 root wheel 3612 Mar 24 2016
/usr/include/ssp/stdio.h
-r--r--r-- 1 root wheel 16905 Mar 24 2016 /usr/include/stdio.h
-rw-r--r-- 1 root wheel 17249 Jul 27 2016
/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.5/include-
fixed/stdio.h
-rw-r--r-- 1 root wheel 3473 Jul 27 2016
/usr/local/lib/gcc48/gcc/x86_64-portbld-
freebsd10.1/4.8.5/include/ssp/stdio.h
-rw-r--r-- 1 root wheel 1209 Jul 27 2016
/usr/local/lib/gcc48/include/c++/tr1/stdio.h

[jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs grep -n
fdclose
/usr/include/stdio.h​:402​:int fdclose(FILE *, int *);

If the first doesn't exist, see what stdio.h perlio$(OBJ_EXT)
depends
on in makefile (not Makefile)

$ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/i386-portbld-
freebsd10.3/4.8.5/include-fixed/stdio.h

[perl] $ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/x86_64-portbld-
freebsd10.1/4.8.5/include-fixed/stdio.h

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, 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.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Jun 5, 2017

From @tonycoz

On Thu, 01 Jun 2017 18​:33​:09 -0700, jkeenan wrote​:

On Thu, 25 May 2017 00​:38​:27 GMT, tonyc wrote​:

On Wed, 24 May 2017 05​:12​:46 -0700, jkeenan wrote​:

On Wed, 24 May 2017 04​:16​:21 GMT, tonyc wrote​:

I suspect your 4.8 gcc build is using an old "fixed" version of
the
stdio headers, on my system the stdio.h used is at​:

/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
int fdclose(FILE *, int *);
$ grep fdclose /usr/include/stdio.h
int fdclose(FILE *, int *);

[jkeenan] $ uname -mrs
FreeBSD 10.3-RELEASE amd64

[jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs ls -l
-r--r--r-- 1 root wheel 3612 Mar 24 2016
/usr/include/ssp/stdio.h
-r--r--r-- 1 root wheel 16905 Mar 24 2016 /usr/include/stdio.h
-rw-r--r-- 1 root wheel 17249 Jul 27 2016
/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.5/include-
fixed/stdio.h
-rw-r--r-- 1 root wheel 3473 Jul 27 2016
/usr/local/lib/gcc48/gcc/x86_64-portbld-
freebsd10.1/4.8.5/include/ssp/stdio.h
-rw-r--r-- 1 root wheel 1209 Jul 27 2016
/usr/local/lib/gcc48/include/c++/tr1/stdio.h

[jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs grep -n
fdclose
/usr/include/stdio.h​:402​:int fdclose(FILE *, int *);

If the first doesn't exist, see what stdio.h perlio$(OBJ_EXT)
depends
on in makefile (not Makefile)

$ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/i386-portbld-
freebsd10.3/4.8.5/include-fixed/stdio.h

[perl] $ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/x86_64-portbld-
freebsd10.1/4.8.5/include-fixed/stdio.h

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, 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.

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/. "

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.

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

@p5pRT
Copy link
Author

p5pRT commented Jun 16, 2017

From @jkeenan

On Mon, 05 Jun 2017 02​:05​:59 GMT, tonyc wrote​:

On Thu, 01 Jun 2017 18​:33​:09 -0700, jkeenan wrote​:

On Thu, 25 May 2017 00​:38​:27 GMT, tonyc wrote​:

On Wed, 24 May 2017 05​:12​:46 -0700, jkeenan wrote​:

On Wed, 24 May 2017 04​:16​:21 GMT, tonyc wrote​:

I suspect your 4.8 gcc build is using an old "fixed" version of
the
stdio headers, on my system the stdio.h used is at​:

/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
int fdclose(FILE *, int *);
$ grep fdclose /usr/include/stdio.h
int fdclose(FILE *, int *);

[jkeenan] $ uname -mrs
FreeBSD 10.3-RELEASE amd64

[jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs ls -l
-r--r--r-- 1 root wheel 3612 Mar 24 2016
/usr/include/ssp/stdio.h
-r--r--r-- 1 root wheel 16905 Mar 24 2016
/usr/include/stdio.h
-rw-r--r-- 1 root wheel 17249 Jul 27 2016
/usr/local/lib/gcc48/gcc/x86_64-portbld-
freebsd10.1/4.8.5/include-
fixed/stdio.h
-rw-r--r-- 1 root wheel 3473 Jul 27 2016
/usr/local/lib/gcc48/gcc/x86_64-portbld-
freebsd10.1/4.8.5/include/ssp/stdio.h
-rw-r--r-- 1 root wheel 1209 Jul 27 2016
/usr/local/lib/gcc48/include/c++/tr1/stdio.h

[jkeenan] $ locate stdio.h | grep -E '\/stdio\.h$' | xargs grep
-n
fdclose
/usr/include/stdio.h​:402​:int fdclose(FILE *, int *);

If the first doesn't exist, see what stdio.h perlio$(OBJ_EXT)
depends
on in makefile (not Makefile)

$ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/i386-portbld-
freebsd10.3/4.8.5/include-fixed/stdio.h

[perl] $ grep perlio.*/stdio.h makefile
perlio$(OBJ_EXT)​: /usr/local/lib/gcc48/gcc/x86_64-portbld-
freebsd10.1/4.8.5/include-fixed/stdio.h

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, 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.

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/. "

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.

That isn't the problem here, the problem you have is g++ gives
priority to its "fixed" headers, overriding the system provided
headers.

So today I finally got up the nerve to run mkheaders in my FreeBSD-10.3 VM.

#####
$ sudo /usr/local/libexec/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.5/install-tools/mkheaders
#####

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​:
#####
$ regular_configure && make test_prep
$ ./perl -Ilib -V | grep gccversion
  gccversion='4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)'

$ gcc_configure && make test_prep
$ ./perl -Ilib -V | ack '\b(cc|gccversion)='
  cc='gcc'
  gccversion='4.8.5'

$ gpp_configure && make test_prep
$ ./perl -Ilib -V | ack '\b(cc|gccversion)='
  cc='g++'
  gccversion='4.8.5'
#####

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)​:
#####
$ ./perl -Ilib -V | ack '\b(cc|gccversion)='
  cc='g++', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2',
  ccversion='', gccversion='4.8.5', gccosandvers=''
#####

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.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Jun 16, 2017

@jkeenan - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant