gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

Post by Peter MacDona » Sat, 04 Jul 1992 14:26:10



Seems when I try compiling find or textutils etc, some file *
on stdlib.h.       I have tried many combinations of unpacking
0.96bp2inc.tar.Z, gcc includes and lx96b includes.  Anyone else,
or did I fail to read all the readme's in GCC correctly?
There is getting to be so much mail in this group, it is getting
hard to follow all bug reports.
-------------------------------------------------

gcc -O -g -I. -I../lib -I./lib -DSTDC_HEADERS -DHAVE_UNISTD_H -DNICE_PRIORITY   -c id.c -o id.o
In file included from /usr/lib/gcc-lib/i386-linux/2.2.2/include/limits.h:4, from id.c:29:
/usr/include/limits.h:4: warning: `RAND_MAX' redefined
/usr/include/stdlib.h:22: warning: this is the location of the previous definition
In file included from system.h:79, from id.c:26:
/usr/include/stdlib.h:115: parse error before `*'
/usr/include/stdlib.h:118: parse error before `wchar_t'
/usr/include/stdlib.h:121: parse error before `*'
/usr/include/stdlib.h:123: parse error before `*'
make[1]: *** [id.o] Error 1

 
 
 

gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

Post by H.J. » Sat, 04 Jul 1992 15:41:46



>Seems when I try compiling find or textutils etc, some file *
>on stdlib.h.       I have tried many combinations of unpacking
>0.96bp2inc.tar.Z, gcc includes and lx96b includes.  Anyone else,
>or did I fail to read all the readme's in GCC correctly?
>There is getting to be so much mail in this group, it is getting
>hard to follow all bug reports.
>-------------------------------------------------

>gcc -O -g -I. -I../lib -I./lib -DSTDC_HEADERS -DHAVE_UNISTD_H -DNICE_PRIORITY   -c id.c -o id.o
>In file included from /usr/lib/gcc-lib/i386-linux/2.2.2/include/limits.h:4, from id.c:29:
>/usr/include/limits.h:4: warning: `RAND_MAX' redefined

In my limts.h,

---
#ifndef RAND_MAX
/* The largest number rand will return (same as INT_MAX).  */
#define RAND_MAX 2147483647
#endif
----

Quote:>/usr/include/stdlib.h:22: warning: this is the location of the previous definition

In my stdlib.h,

-----
#ifndef RAND_MAX
/* The largest number rand will return (same as INT_MAX).  */
#define RAND_MAX        2147483647
#endif
___

Quote:>In file included from system.h:79, from id.c:26:
>/usr/include/stdlib.h:115: parse error before `*'
>/usr/include/stdlib.h:118: parse error before `wchar_t'
>/usr/include/stdlib.h:121: parse error before `*'
>/usr/include/stdlib.h:123: parse error before `*'
>make[1]: *** [id.o] Error 1

Could you please send me your limits.h, stdlib.h and
/usr/lib/gcc-lib/i386-linux/2.2.2/include/stddef.h?

H.J.

 
 
 

gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

Post by Kevin Bro » Sun, 05 Jul 1992 22:19:13




>>Seems when I try compiling find or textutils etc, some file *
>>on stdlib.h.       I have tried many combinations of unpacking
>>0.96bp2inc.tar.Z, gcc includes and lx96b includes.  Anyone else,
>>or did I fail to read all the readme's in GCC correctly?
>>There is getting to be so much mail in this group, it is getting
>>hard to follow all bug reports.

[...]

Quote:>>In file included from system.h:79, from id.c:26:
>>/usr/include/stdlib.h:115: parse error before `*'
>>/usr/include/stdlib.h:118: parse error before `wchar_t'
>>/usr/include/stdlib.h:121: parse error before `*'
>>/usr/include/stdlib.h:123: parse error before `*'
>>make[1]: *** [id.o] Error 1

>Could you please send me your limits.h, stdlib.h and
>/usr/lib/gcc-lib/i386-linux/2.2.2/include/stddef.h?

Heh.  I *knew* this was going to bite someone after I ran into it during
the build of 0.96b under gcc-2.12c.  I don't understand why it hasn't bitten
everyone using 2.12c or later...

The answer is not to be found in /usr/lib/gcc-lib/i386-linux/2.2.2/include/*.
These are "generic" header files that gcc uses, apparently to determine what
it needs to know and so forth.  The definition of wchar_t DOES NOT belong
there (just as the definition of size_t doesn't belong there).

The problem is that /usr/include/stdlib.h has prototypes that involve wchar_t,
and wchar_t is not defined *anywhere* in the current gcc-2.2.2/0.96b
distribution.  Not in any of the include files in the gcc-2.2.2 distribution,
not in any of the include files in 0.96bp2inc.tar.Z, and not in any of the
include files in linux-0.96b.tar.Z (which contains the OS source).  Not
anywhere.

I can't believe that this one was overlooked, particularly since this has
been a problem as of the release of 2.12c!

wchar_t is supposed to be defined in /usr/include/stddef.h (where things like
size_t are defined).  The only stddef.h that is distributed in the current
release is in linux-0.96b.tar.Z, and it does not have a definition of wchar_t
(and never has, to my knowledge).  I'm at a loss to figure out how you guys
running anything later than 2.11c could build the kernel without running
into this problem, as tools/build.c includes stdlib.h, which has prototypes
that, in releases as of 2.12c (or so it seems.  I had this same problem when
trying to build the kernel with 2.12c), refer to wchar_t.

The following needs to be added to stddef.h (wherever it's located on your
system, probably in /usr/include):

#ifndef _WCHAR_T
#define _WCHAR_T
typedef long wchar_t;
#endif

I'm assuming here that the above typedef is correct for our system.  This is
the definition used by the 386/486 implementation of System Vr4.


Quote:>H.J.

--

 
 
 

gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

Post by Jim Winstead J » Mon, 06 Jul 1992 05:23:41



>The answer is not to be found in /usr/lib/gcc-lib/i386-linux/2.2.2/include/*.
>These are "generic" header files that gcc uses, apparently to determine what
>it needs to know and so forth.  The definition of wchar_t DOES NOT belong
>there (just as the definition of size_t doesn't belong there).

You must not have been listening to what H.J. Lu has been saying on
this subject.

/usr/lib/gcc-lib/i386-linux/2.2.2/include is where the
version-dependent include files are kept.  According to H.J. Lu has
said about how he was told to do things by the FSF, stddef.h and
stdarg.h are two such include files.  This directory is searched for
include files, just as /usr/include is, although I'm not sure which is
searched first.

If you don't believe cpp looks in /usr/lib/..., do a 'strings cpp |
grep include' and believe otherwise.

Quote:>The problem is that /usr/include/stdlib.h has prototypes that involve wchar_t,
>and wchar_t is not defined *anywhere* in the current gcc-2.2.2/0.96b
>distribution.  Not in any of the include files in the gcc-2.2.2 distribution,
>not in any of the include files in 0.96bp2inc.tar.Z, and not in any of the
>include files in linux-0.96b.tar.Z (which contains the OS source).  Not
>anywhere.

wchar_t is defined in stddef.h, as it should be.  That file is located
in /usr/lib/..., and is picked up by cpp, provided you are using the
correct version of cpp.  (Perhaps you or others with the problem have
an old copy lingering?)

Quote:>I can't believe that this one was overlooked, particularly since this has
>been a problem as of the release of 2.12c!

I've had no problems with it.  Never a peep from any compilations I've
done, which have been many over the last few days.

According to the reference I have, wchar_t is a 'wide' character, or
multi-byte character, so I suspect you'll see a lot of it once Unicode
is adopted, for example.
--
                                    +    Jim Winstead Jr. (CSci '95)
                                    |            Harvey Mudd College

                                    + This is all my words.  Honest!

 
 
 

gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

Post by James Henricks » Mon, 06 Jul 1992 04:46:53


[ A whole BUNCH of stuff deleted.  :-) ]


>>>Seems when I try compiling find or textutils etc, some file *
>>>on stdlib.h.       I have tried many combinations of unpacking
>>>0.96bp2inc.tar.Z, gcc includes and lx96b includes.  Anyone else,
>>>or did I fail to read all the readme's in GCC correctly?
>>>There is getting to be so much mail in this group, it is getting
>>>hard to follow all bug reports.

I made it through the installation rather painlessly, though I didn't follow
the directions explicity.  I have run into a different problem.  

I am replacing all of my old programs with gcc2.2.2-compiled versions.  
Everything appears to be working OK except "du" and "ls".  I have tried
compiling the GNU fileutils source that I got from prep.ai.mit.edu and the
fileutils source from the Linux directory from tsx-11.mit.edu, and get the
the same result.

Both programs display file sizes OK in bytes, but neither one displays the
file sizes in blocks correctly.  It always comes out as 0.  I don't mind
that much with "ls" because I never use that option, but I'm not
accustomed to mentally converting bytes to blocks when I use "du".  :-)  I
know, it's easy to blame it on the compiler, but these utilities should work
on other unices.  Tracking through the source code, there is a macro to
convert the number of 512K blocks to the equivalent number of 1024K blocks,
but the macro is instead producing a result of 0.  Has anyone else run into
this problem?  If it is indeed a problem with the macro, it should happen
on all systems but it worked OK on an Ultrix system using gcc1.40.  I've
got a bunch of other stuff to compile at present but will continue my
investigation later if nobody comes up with a solution first.

I'd also like to point out a definition that might be missing from one of the
header files.  "cp" expects DEV_BSIZE to be defined somewhere.  I had to
define it as 1024 in cp.c to get it to compile.

I hope my oddball gcc-2.2.2 installation didn't cause this.  I haven't
had any other problems yet and the kernel works OK.

--
Jim H.
*

* "Yet another Jim in the Linux world."  :-)

 
 
 

gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

Post by Douglas E. Qua » Mon, 06 Jul 1992 08:50:29



Quote:

>I am replacing all of my old programs with gcc2.2.2-compiled versions.  
>Everything appears to be working OK except "du" and "ls".  I have tried

>Both programs display file sizes OK in bytes, but neither one displays the
>file sizes in blocks correctly.  It always comes out as 0.  I don't mind

This is due to the change in the stat structure in the latest Linux
release.  Older releases used the SYSV style stat structure but with 16 bit
inode numbers, but the new Linux stat goes to 32 bit inode numbers and the
infinitely superior BSD stat structure.  I think SYSVR4 finally saw the
light and fixed their stupid struct stat (it only took them about 5 years).

The problem is that BSD struct stat has an st_blocks field.  The new
Linux stat has it too, and GNU configure sees st_blocks and has no way to
know that st_blocks is currently ignored by Linux (always = 0).   You can
fix this by setting the flag -DST_BLOCKS_MISSING.  A better fix would have
been for Linus to temporarily name the st_blocks field something like
__st_blocks so that automatic configure utilities would work properly.
Then it could be given it's correct name when the kernel sets the
st_blocks field.  Of course, you could make this change yourself.

I think there's a good chance that the block counts that GNU du and the
like report might be a (very) little off because of the unusual inode
format of the Minix system.  16-bit inode numbers and no atime or ctime
and only 32 byte inodes instead of 64 bytes might be unique in the modern
Unix world.  I think that most Unices can store 10 direct blocks in an inode,
Minix only has 7.  I haven't spent any time looking into this -- once the
kernel sets st_blocks it will be a non-issue.
Minix inodes have only
--
Doug Quale

 
 
 

gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

Post by Kevin Bro » Mon, 06 Jul 1992 20:11:39




>>The answer is not to be found in /usr/lib/gcc-lib/i386-linux/2.2.2/include/*.
>>These are "generic" header files that gcc uses, apparently to determine what
>>it needs to know and so forth.  The definition of wchar_t DOES NOT belong
>>there (just as the definition of size_t doesn't belong there).

>You must not have been listening to what H.J. Lu has been saying on
>this subject.

>/usr/lib/gcc-lib/i386-linux/2.2.2/include is where the
>version-dependent include files are kept.  According to H.J. Lu has
>said about how he was told to do things by the FSF, stddef.h and
>stdarg.h are two such include files.  This directory is searched for
>include files, just as /usr/include is, although I'm not sure which is
>searched first.

>If you don't believe cpp looks in /usr/lib/..., do a 'strings cpp |
>grep include' and believe otherwise.

I hang my head in shame...:-)

You're quite correct, of course.

The reason I had problems with it is that the cpp that comes with gcc-2.12c
doesn't look in the right place for the include files.  Instead of looking in
/usr/lib/gcc-lib/i386-linux/2.12c/include, it was looking in
/usr/lib/gcc-lib/i386-linux/2.12/include, which on my system doesn't exist.

Sigh...

M*of the story: if you're having these problems, check your directory
layout real carefully...

Also: if you're distributing a version of gcc, make sure the binaries look
in the right places for things...

Quote:>>The problem is that /usr/include/stdlib.h has prototypes that involve wchar_t,
>>and wchar_t is not defined *anywhere* in the current gcc-2.2.2/0.96b
>>distribution.  Not in any of the include files in the gcc-2.2.2 distribution,
>>not in any of the include files in 0.96bp2inc.tar.Z, and not in any of the
>>include files in linux-0.96b.tar.Z (which contains the OS source).  Not
>>anywhere.

>wchar_t is defined in stddef.h, as it should be.  That file is located
>in /usr/lib/..., and is picked up by cpp, provided you are using the
>correct version of cpp.  (Perhaps you or others with the problem have
>an old copy lingering?)

This turns out to be correct.  I had to stare real hard at
/usr/lib/.../stddef.h to find out where it was defining wchar_t, but it is
defining it.

Quote:>>I can't believe that this one was overlooked, particularly since this has
>>been a problem as of the release of 2.12c!

>I've had no problems with it.  Never a peep from any compilations I've
>done, which have been many over the last few days.

I can now see why...

--

 
 
 

gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

Post by Chris Flatters,208,7209,homepho » Tue, 07 Jul 1992 06:40:11



>I'm assuming here that the above typedef is correct for our system.  This is
>the definition used by the 386/486 implementation of System Vr4.



wchar_t is an integral type that can represent all distinct values for any extended
character set in the supported locales.  Currently

typedef unsigned char wchar_t

should be sufficient for Linux (until we support Kanji or Arabic).

        Chris Flatters

 
 
 

gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

Post by joh.. » Tue, 07 Jul 1992 11:19:51



Quote:> [ A whole BUNCH of stuff deleted.  :-) ]

> I made it through the installation rather painlessly, though I didn't follow
> the directions explicity.  I have run into a different problem.  

> I am replacing all of my old programs with gcc2.2.2-compiled versions.  
> Everything appears to be working OK except "du" and "ls".  I have tried
> compiling the GNU fileutils source that I got from prep.ai.mit.edu and the
> fileutils source from the Linux directory from tsx-11.mit.edu, and get the
> the same result.

  I tried this too (with gcc 2.2.2, installed correctly I think) and got
the same problem as below with `ls` and `du`. The old binaries work OK under
.96b patch 2.

Quote:

> Both programs display file sizes OK in bytes, but neither one displays the
> file sizes in blocks correctly.  It always comes out as 0.  I don't mind
> that much with "ls" because I never use that option, but I'm not
> accustomed to mentally converting bytes to blocks when I use "du".  :-)  I
> know, it's easy to blame it on the compiler, but these utilities should work
> on other unices.  Tracking through the source code, there is a macro to
> convert the number of 512K blocks to the equivalent number of 1024K blocks,
> but the macro is instead producing a result of 0.  Has anyone else run into
> this problem?  If it is indeed a problem with the macro, it should happen
> on all systems but it worked OK on an Ultrix system using gcc1.40.  I've
> got a bunch of other stuff to compile at present but will continue my
> investigation later if nobody comes up with a solution first.

> I'd also like to point out a definition that might be missing from one of the
> header files.  "cp" expects DEV_BSIZE to be defined somewhere.  I had to
> define it as 1024 in cp.c to get it to compile.

  Is 1024 bytes correct?. I had assumed a block was 512.

> I hope my oddball gcc-2.2.2 installation didn't cause this.  I haven't
> had any other problems yet and the kernel works OK.

> --
> Jim H.
> *

> * "Yet another Jim in the Linux world."  :-)

--


Monash University Computer Centre       Phone:  +61 3  5654763
Wellington Road,                        FAX:    +61 3  5654746
Clayton 3168,
Australia.

 
 
 

gcc 2.2.2: stdlib.h/stddef.h wchar_t problem?

Post by Drew Eckhar » Wed, 08 Jul 1992 13:56:29




>> header files.  "cp" expects DEV_BSIZE to be defined somewhere.  I had to
>> define it as 1024 in cp.c to get it to compile.

>  Is 1024 bytes correct?. I had assumed a block was 512.

yes, 1024 bytes is correct.  Internally, most device drivers
read / write 2 512 byte physical blocks to make one 1024 "linux"
block, but everything above the device drivers sees 1024 byte
blocks.
 
 
 

1. help: wchar_t type conflict stddef.h & Xlib.h

I been porting Bristol hyperhelp 5.x and our product PV-WAVE to linux
2.0.0 (slackware 96) and I keep running into the same problem: gcc complains
 about conflicting types of two declarations for 'wchar_t' . One is in
 ../X11/Xlib.h (we are using XFree86 from slackware 96)
and the other is in
./gcc-lib/i486-linux/2.7.2/include/stddef.h (ditto gcc)

This is obviously not an application specific problem, so I'm hoping someone
else has seen this before and dealt with it.
Has anyone else seen this? Is there a particular definition I need to be using?
A fix?

--
Thanks,
Brad

2. redirecting core files

3. c/c++: ERROR: Undefined symbol: .std::basic_string<wchar_t, std::char_traits<wchar_t>

4. Chat program needed!

5. Help in programming a Client/Server application on a SCO UNIX System

6. GCC 2.7.2 - wchar_t functions = problems

7. Emulating HTTP File Uploads

8. gcc can't find stddef.h

9. cc, gcc, -I, and stddef.h

10. gcc 2.4.5 i486 bins on Sunsite and stdlib.h

11. Problem compiling xxgdb and wchar_t conflict

12. problem of fputws when sizeof(wchar_t)==2