[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #10 from John David Anglin danglin at gcc dot gnu.org --- Author: danglin Date: Mon Oct 13 17:02:35 2014 New Revision: 216152 URL: https://gcc.gnu.org/viewcvs?rev=216152root=gccview=rev Log: PR libfortran/63471 * config/pa/pa-hpux11.h (TARGET_OS_CPP_BUILTINS): Define _REENTRANT when _HPUX_SOURCE is defined. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa-hpux11.h
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from John David Anglin danglin at gcc dot gnu.org --- Fixed.
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #7 from Janne Blomqvist jb at gcc dot gnu.org --- (In reply to dave.anglin from comment #3) On some platforms (MacOS 10.4 and Solaris 11), ttyname_r may return a 'char *', not 'int'. FWIW, libgfortran uses the AC_USE_SYSTEM_EXTENSIONS macro, which on Solaris defines _POSIX_PTHREAD_SEMANTICS making it prefer the POSIX _r functions instead of the POSIX draft _r versions. I'm not sure we care about OS X 10.4 anymore? Newer versions apparently provide the POSIX ttyname_r. So, are you planning on enabling _REENTRANT in the HP-UX 11 driver like you did for 10, or do you want to solve this in some other way?
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #8 from dave.anglin at bell dot net --- On 10/10/2014 3:42 AM, jb at gcc dot gnu.org wrote: So, are you planning on enabling _REENTRANT in the HP-UX 11 driver like you did for 10, or do you want to solve this in some other way? I have it installed for testing and will commit it if I don't see any problems. Dave
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #9 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Janne Blomqvist from comment #7) I'm not sure we care about OS X 10.4 anymore? Newer versions apparently provide the POSIX ttyname_r. I confirm that 10.5 and later Mac OS versions provide ttyname_r with the correct signature, and we don't care about 10.4 anymore.
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #6 from dave.anglin at bell dot net --- On 10/8/2014 11:07 PM, jb at gcc dot gnu.org wrote: That being said, googling this issue I stumbled upon https://gcc.gnu.org/ml/gcc-patches/2011-03/msg00545.html where you fixed a similar issue for hp-ux 10, seemingly by making the driver always set _REENTRANT. Wouldn't a similar thing be the right thing to do for hp-ux 11 as well? If there are no ill effects of always enabling _REENTRANT that would help other software than just libgfortran, as well as eliminating the risk that unconditionally enabling _REENTRANT in libgfortran might break on some other target? It's certainly easy to make the same change to hp-ux 11. I was clearly wrong about the guards being removed. I suspect HP introduced the _REENTRANT guard because they wanted to remove the _r routines: http://h21007.www2.hp.com/portal/download/files/unprot/stk/tru64_stk/impacts/i24.html However, they are not gone so I think we should define _REENTRANT if there are no ill effects. Dave
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #1 from Janne Blomqvist jb at gcc dot gnu.org --- Hmm, any idea how to fix it? Apparently just defining _REENTRANT globally might not be a good idea, as some systems may require linking in some other C library (libc_rt or such) then. We don't want to use the GCC -pthread flag (which should take care of necessary linking magic) either, since on systems with weakref support we want to avoid using mutexes etc. in single-threaded programs.
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org --- Hmm, maybe add something like AC_CHECK_DECLS_ONCE([ttyname_r]) to configure.ac and then in unix.c(stream_ttyname) check with #ifdef HAVE_TTYNAME_R HAVE_DECL_TTYNAME_R
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #3 from dave.anglin at bell dot net --- On 10/8/2014 9:43 AM, jb at gcc dot gnu.org wrote: Hmm, maybe add something like AC_CHECK_DECLS_ONCE([ttyname_r]) to configure.ac and then in unix.c(stream_ttyname) check with #ifdef HAVE_TTYNAME_R HAVE_DECL_TTYNAME_R Don't we want to use ttyname_r in multithreaded applications? It seems HP-UX is the only platform to hide the declaration of ttyname_r using _REENTRANT :-( If configure finds ttyname_r, then presumably we don't need pthread linking for it. On some platforms (MacOS 10.4 and Solaris 11), ttyname_r may return a 'char *', not 'int'. Dave
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #4 from dave.anglin at bell dot net --- There are more functions with this problem. The attached patch enables libgfortran to build on hpux11.11. Dave -- John David Anglindave.ang...@bell.net
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #5 from Janne Blomqvist jb at gcc dot gnu.org --- Ah, I suspected that other functions might be affected as well. Thanks for finding them. That being said, googling this issue I stumbled upon https://gcc.gnu.org/ml/gcc-patches/2011-03/msg00545.html where you fixed a similar issue for hp-ux 10, seemingly by making the driver always set _REENTRANT. Wouldn't a similar thing be the right thing to do for hp-ux 11 as well? If there are no ill effects of always enabling _REENTRANT that would help other software than just libgfortran, as well as eliminating the risk that unconditionally enabling _REENTRANT in libgfortran might break on some other target?
