Mail Archives: cygwin/2005/05/12/06:37:32
----Original Message----
>From: Marcel
>Sent: 12 May 2005 11:00
> I am NOT an experienced C or cygwin user, but the
> problems I keep running into, appear to me that gcc
> with cygwin behaves very differently from whatever I
> had on the previous systems.
Actually, it's not a difference in gcc, but in the libc implementation.
Linux systems use glibc; cygwin is newlib-based. There are some differences
between those two in the areas that are allowed to be
implementation-defined, and I'm afraid you've just run into one of those:
> gcc -g -Wall -c flm.c
> flm.c:37: error: initializer element is not constant
> make: *** [flm.o] Error 1
>
> The offending line.37 was:
> FILE *ch_par=stdout,*ch_verify=NULL;
That's because under newlib, 'stdout' is not the name of a variable. It's
a macro:
/usr/include/stdio.h:
#define stdin (_REENT->_stdin)
#define stdout (_REENT->_stdout)
#define stderr (_REENT->_stderr)
that hides fetching the stdout pointer from thread-local storage, which in
turn involves calling a function:
/usr/include/sys/reent.h
# define _REENT (__getreent())
So effectively you've written
FILE *ch_par = some_function ();
which, while it's a permitted way to initialise a local variable when a
function enters, cannot be used in C to initialise a static (file-scope)
variable. In fact, if you compile your code with --save-temps and look at
the pre-processed .i file, you'll see that it's been turned into:
FILE *ch_par = ((__getreent())->_stdout);
On some systems, stdout is just a pointer variable, but under cygwin, it
isn't. Possible solutions include either initialising it at runtime, or
switching your compilation to C++, which does permit constructor functions.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -