[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #15 from prlw1 at cam dot ac dot uk 2009-09-07 16:47 --- I just got stuck with this again: wondered why a NetBSD-5.99.15/i386 box with gcc-HEAD wouldn't compile. Then remembered the #define _ANSI_H_ fix and all is well. What is impeding this patch from being applied? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #14 from prlw1 at cam dot ac dot uk 2009-03-25 18:57 --- I take it all is in hand, and I don't need to test anything? (I did a successful build with the same as the first patch, but defining _MACHINE_ANSI_H_ - this is equivalent - all went well) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #8 from prlw1 at cam dot ac dot uk 2009-03-23 21:07 ---
What about the first patch, which seems less drastic? (I think it would be
better to install gcc's stddef.h, so there is one thing less to remember when
upgrading gcc) It seems that if our machine/ansi.h defined _MACHINE_ANSI_H_
rather than _${MACHINE}_ANSI_H_, things would be happier. The first patch
defines _ANSI_H_ instead. Hmm I'll try both and see...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #6 from prlw1 at cam dot ac dot uk 2009-03-23 20:45 ---
(In reply to comment #5)
> The patch is obviously wrong (it changes the installed headers for all
> targets instead of setting USER_H to adjust the list for the target with
> this issue)
Care to explain more re USER_H? I tried to addIndex: stddef.h
===
--- stddef.h(revision 145011)
+++ stddef.h(working copy)
@@ -62,6 +62,20 @@
#include
#endif
+#if defined(__NetBSD__)
+typedef _BSD_PTRDIFF_T_ ptrdiff_t;
+
+#ifdef _BSD_SIZE_T_
+typedef _BSD_SIZE_T_size_t;
+#undef _BSD_SIZE_T_
+#endif
+
+#ifdef _BSD_WCHAR_T_
+typedef _BSD_WCHAR_T_ wchar_t;
+#undef _BSD_WCHAR_T_
+#endif
+#endif /* __NetBSD__ */
+
/* In 4.3bsd-net2, machine/ansi.h defines these symbols, which are
defined if the corresponding type is *not* defined.
FreeBSD-2.1 defines _MACHINE_ANSI_H_ instead of _ANSI_H_ */
which allowed me to compile gfortran. libsup++ failed including time.h, which
behaved as though _BSD_SIZE_T_ was defined, but empty.
Simply put, if I gcc -E gcc/gcc/ginclude/stddef.h, size_t is not defined:
# 1 "stddef.h"
# 1 ""
# 1 ""
# 1 "stddef.h"
# 58 "stddef.h"
# 1 "/usr/include/machine/ansi.h" 1 3 4
# 37 "/usr/include/machine/ansi.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 59 "/usr/include/sys/cdefs.h" 3 4
# 1 "/usr/include/machine/cdefs.h" 1 3 4
# 60 "/usr/include/sys/cdefs.h" 2 3 4
# 1 "/usr/include/sys/cdefs_elf.h" 1 3 4
# 62 "/usr/include/sys/cdefs.h" 2 3 4
# 38 "/usr/include/machine/ansi.h" 2 3 4
# 1 "/usr/include/machine/int_types.h" 1 3 4
# 45 "/usr/include/machine/int_types.h" 3 4
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef short int __int16_t;
typedef unsigned short int __uint16_t;
typedef int __int32_t;
typedef unsigned int __uint32_t;
typedef long long int __int64_t;
typedef unsigned long long int __uint64_t;
typedef int __intptr_t;
typedef unsigned int __uintptr_t;
# 40 "/usr/include/machine/ansi.h" 2 3 4
# 73 "/usr/include/machine/ansi.h" 3 4
typedef union {
__int64_t __mbstateL;
char __mbstate8[128];
} __mbstate_t;
# 59 "stddef.h" 2
and machine/ansi.h defines _${MACHINE}_ANSI_H_ on NetBSD. If I gcc -E
/usr/include/stddef.h, size_t is defined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug fortran/39532] fortran 95 parsing trouble
--- Comment #2 from prlw1 at cam dot ac dot uk 2009-03-23 20:23 --- I just tried ifort -warn stderrors -std95 modules.f which didn't complain. It seems gfortran is unhappy about the parentheses in that declaration. I included the parts before, so you can see that nREBOspecies is defined... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39532
[Bug fortran/39532] New: fortran 95 parsing trouble
Program extract: ... module brennerdata use datatypes use element,only : maxele integer(i4), save :: nbrennertype = 3 integer(i4),parameter :: nREBOspecies = 4 integer(i4), save :: nREBOspecies2 logical, save :: lbP_CHdone(0:3,0:3,3) logical, save :: lbPdone(0:3,0:3,nREBOspecies*(nREBOspecies+ 1)/2,nREBOspecies) ... logical, save :: lbPdone(0:3,0:3,nREBOspecies*(nREBO 1 Error: Missing ')' in statement at or before (1) with gfortran 4.4.0 source of 16 March 2009. I believe this is correct F95, and the intel compiler is happy with it. (This may be a duplicate of another bug, but what would good search terms be?) -- Summary: fortran 95 parsing trouble Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: prlw1 at cam dot ac dot uk GCC build triplet: i386-unknown-netbsdelf5.99.8 GCC host triplet: i386-unknown-netbsdelf5.99.8 GCC target triplet: i386-unknown-netbsdelf5.99.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39532
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #4 from prlw1 at cam dot ac dot uk 2009-03-23 19:31 --- Just hit this bug. Either solution looks good (am about to test, but spent ages reaching the same conclusion, so expect success for both) Anyone from gcc listening? -- prlw1 at cam dot ac dot uk changed: What|Removed |Added CC||prlw1 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug libfortran/26564] ../.././libgfortran/mk-kinds-h.sh: Unknown type
--- Comment #18 from prlw1 at cam dot ac dot uk 2006-05-20 16:24 --- I have just experienced exactly the same error on a NetBSD-current/i386 system. There the problem is not gmp et al.'s fault, and I can't see quite enough detail in the problem on alpha below to see that it isn't the same. My system uses ELF binaries, and I don't set half the world in LD_LIBRARY_PATH nor ld.so.conf. I have libmpfr.so.2.1 and libgmp.so.7.1 in /usr/local/lib. The error /usr/src/local/gcc/libgfortran/mk-kinds-h.sh: Unknown type happens because gfortran was compiled without -Wl,-R/usr/local/lib, so it cannot find libmpr. The top level configure accepts --with-mpfr=/usr/local --with-gmp=/usr/local, and doesn't spot any problems, as it AC_TRY_LINKs the libraries rather than AC_TRY_RUN them. gcc/configure --help mentions GMPLIBS How to link GMP but setting that environment variable (or HOST_GMPLIBS) before running the top level configure doesn't seem to help, as --with-gmp sets gmplibs, which in top level Makefile.in sets HOST_GMPLIBS, which in turn is what GMPLIBS is set to, which is what reaches gcc/Makefile.in (AFAICT) The way I worked around this is after running configure --with-gmp..., edit the top level Makefile, and set HOST_GMPLIBS to include -Wl,-R/usr/local/lib. There ought to be a more user friendly way of doing this, so I think this bug ought to be reopened... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26564
