mgansser@rand.de
2002-Jul-08 11:58 UTC
compilation breaks with gnome support on hp-ux 11.00 (PR#1757)
Full_Name: Martin Gansser Version: 1.5.1 OS: hp-ux 11.00 Submission from: (NULL) (195.145.22.147) cc -Wp,-H16000 -I. -I../../../src/include -I../../../src/include -I/opt/gnome/include/gnome-1.0 -DNE ED_GNOMESUPPORT_H -I/opt/gnome/lib/gnome-libs/include -I/opt/gnome/include/glib-1.2 -I/opt/gnome/lib /glib/include -I/opt/gnome/include/orbit-1.0 -I/opt/gnome/include/gtk-1.2 -I/opt/gnome/include/gnome -xml -I/opt/gnome/include -I/opt/gnome/include/gnome-1.0 -DNEED_GNOMESUPPORT_H -I/opt/gnome/lib/gnom e-libs/include -I/opt/gnome/include/glib-1.2 -I/opt/gnome/lib/glib/include -I/opt/gnome/include/orbi t-1.0 -I/opt/gnome/include/gtk-1.2 -I/usr/local/include -I/opt/gnome/include -DHAVE_CONFIG_H +Z - Wp,-H16000 -c system-showfiles.c -o system-showfiles.lo cpp: "/opt/gnome/include/gnome-1.0/libgnome/gnome-i18n.h", line 10: warning 2013: Unknown preprocess ing directive. cc: "system-showfiles.c", line 271: error 1502: Array size must be a constant expression. gmake[4]: *** [system-showfiles.lo] Error 1 gnome-1.4 for hpux 11.00 PS: R-1.5.1 compiles fine w/o gnome support -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Peter Dalgaard BSA
2002-Jul-08 14:18 UTC
compilation breaks with gnome support on hp-ux 11.00 (PR#1757)
mgansser@rand.de writes:> cc: "system-showfiles.c", line 271: error 1502: Array size must be a constant > expression. > gmake[4]: *** [system-showfiles.lo] Error 1 > > gnome-1.4 for hpux 11.00 > PS: R-1.5.1 compiles fine w/o gnome supportHmm: const gint bufsize = 2048; gchar buf[bufsize]; is the culprit, so a quick fix should be obvious (just use #define instead). But is this usage of "const" variables an un-ANSI C extension in GCC, or is it the HP C compiler that is to blame?? -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Gansser, Martin
2002-Jul-08 15:04 UTC
compilation breaks with gnome support on hp-ux 11.00 (PR#1757)
> mgansser@rand.de writes: > > > cc: "system-showfiles.c", line 271: error 1502: Array size > must be a constant > > expression. > > gmake[4]: *** [system-showfiles.lo] Error 1 > > > > gnome-1.4 for hpux 11.00 > > PS: R-1.5.1 compiles fine w/o gnome support > > Hmm: > > const gint bufsize = 2048; > gchar buf[bufsize]; > > is the culprit, so a quick fix should be obvious (just use #define > instead). But is this usage of "const" variables an un-ANSI C > extension in GCC, or is it the HP C compiler that is to blame?? > > -- > O__ ---- Peter Dalgaard Blegdamsvej 3 > c/ /'_ --- Dept. of Biostatistics 2200 Cph. N > (*) \(*) -- University of Copenhagen Denmark Ph: > (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: > (+45) 35327907occurs only, if CC=cc (HP C compiler) is set, not with CC=gcc -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
RenE J.V. Bertin
2002-Jul-09 19:29 UTC
compilation breaks with gnome support on hp-ux 11.00 (PR#1757)
> Hmm: > > const gint bufsize = 2048; > gchar buf[bufsize]; > > is the culprit, so a quick fix should be obvious (just use #define > instead). But is this usage of "const" variables an un-ANSI C > extension in GCC, or is it the HP C compiler that is to blame??Peter (and others): AFAIK, gcc is the only C compiler that allows this sort of fortran-like syntax. Mighty handy, but not portable at all. However, behind the screens, it translates this (more or less) into a call to alloca(). This is a function that is part of most modern systems, and of which portable versions can be found (outside the glibc source tree). BTW: debugging code that allocates arrays like this is not trivial, as on all systems I've seen, you cannot directly access element n as array[n] (from within gdb, that is). There is a comprehensive whitepaper about gcc's not-portable-outside-gcc quirks available on Metrowerk's site, called Porting GNU C Programs to Metrowerks' CodeWarrior C Compiler. RenE -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Seemingly Similar Threads
- [PATCH libldm v3 0/2] Make libldm to parse and return volume GUID.
- [PATCH libldm 00/12] New API: an ability to retrieve created device-mapper devices back after they have been created.
- [PATCH libldm v4 0/3] Make libldm to parse and return volume GUID.
- [PATCH 0/1] libldm: Make libldm to parse and return volume GUID.
- [PATCH libldm v2 0/1] Make libldm to parse and return volume GUID.