Re: GCC error

Re: GCC error

[Ian Lance Taylor]

"anissi" <anissi@kowsar.com> writes:

> During configuration of GCC-3.3.3 this error occurs:
> 
>  
> 
> Checking size of short.configure : error :can not determine a size for short
> 
>  
> 
> So what is my problem ?

I don't know, and you left out a number of details such as the system
you are using and precisely how you ran configure.  In any case, look
in the file config.log, probably at the very end.  You should look at
config.log in the subdirectory which was being configured at the time
of the above error.  That may suggest what the underlying problem is.

Ian

Re: Gcc Error

[Jonathan Wakely]

On 23 August 2015 at 01:06, Thomas Dineen wrote:
> Jonathan:
>
>    Thanks for the response. Your advise on breaking up the build
> fixed the problem.
>
>     Question: With gcc is there an upper limit on the object code
> size of the final linked application?

That has nothing to do with GCC, it's up to the linker and OS.

I know the Solaris linker used to have a limit of 1GB for 32-bit
executables but I think that's been increased. In any case, a 1GB
executable is much larger than most people will ever create.

> How about the *.O files?

I'm not aware of any limit.

>     Currently I am at about 50.5MB.
>
>     Currently I use static linking for portability, avoiding missing dll
> issues.
>
>      For larger applications will it be necessary to break up the executable
> using
> dynamic link libraries, thus loading a block when and if it is actually
> called?

I doubt that will make any difference.

Re: Gcc Error

[Thomas Dineen]

Jonathan:

    Thanks for the response. Your advise on breaking up the build
fixed the problem.

     Question: With gcc is there an upper limit on the object code
size of the final linked application? How about the *.O files?

     Currently I am at about 50.5MB.

     Currently I use static linking for portability, avoiding missing 
dll issues.

      For larger applications will it be necessary to break up the 
executable using
dynamic link libraries, thus loading a block when and if it is actually 
called?

Thomas Dineen


On 8/22/2015 1:46 AM, Jonathan Wakely wrote:
> On 22 August 2015 at 07:19, Thomas Dineen wrote:
>> Gentle People:
>>
>>      When Building a rather large project gcc produces the following error:
>> "Out of memory for code representation:" See the details below.
>>
>> What is the best or simplest way to fix this?
>>
>> 1) Will using 64 bit via the -m64 flag fix this?
> That tells the compiler to produce 64-bit output, it doesn't change
> how much memory it has available, and is likely to use more memory to
> represent the larger pointer types.
>
>> or
>> 2) I am currently building the project with single gcc call. (The slow way)
>> Due to some legacy issues with GTK/Cairo and extern variables one big build
>> seems to work. Would it be better to compile each .C File to a .O file and
>> then
>> link (Faster way).
> Do you mean you've put all the code in a single file? If yes, then of
> course splitting it up into smaller files will use less memory.
>
>> 3) I am using an older gcc 3.4.6 on Solaris 10.
> Good grief.
>
>> Sun5# !ma
>> make TA_Benchs
>> Running Target: TA_Bench Sun
>> gcc -D_REENTRANT -ggdb -w  -g -c IB_TWS_API.c Read_IB_Callbacks.c
>> gcc Main.c  -ggdb -w IB_TWS_API.o Read_IB_Callbacks.o `pkg-config --cflags
>> --libs gtk+-2.0 ` -lcurl -lm -lsocket -lnsl -ggdb -w -o TA_Bench.sun
>> Assembler: Main.c
>>          "/var/tmp//ccVeiKcL.s", line 15324105 : Out of memory for code
>> representation
>> make: *** [TA_Benchs] Error 1
> This error isn't even coming from GCC, it's coming from the assembler,
> which is part of Solaris and not part of GCC. It's trying to assemble
> a file that is at least 15 million lines long. That's probably your
> problem. Try splitting Main.c into smaller files.
>
>

Re: Gcc Error

[Jonathan Wakely]

On 22 August 2015 at 07:19, Thomas Dineen wrote:
> Gentle People:
>
>     When Building a rather large project gcc produces the following error:
> "Out of memory for code representation:" See the details below.
>
> What is the best or simplest way to fix this?
>
> 1) Will using 64 bit via the -m64 flag fix this?

That tells the compiler to produce 64-bit output, it doesn't change
how much memory it has available, and is likely to use more memory to
represent the larger pointer types.

> or
> 2) I am currently building the project with single gcc call. (The slow way)
> Due to some legacy issues with GTK/Cairo and extern variables one big build
> seems to work. Would it be better to compile each .C File to a .O file and
> then
> link (Faster way).

Do you mean you've put all the code in a single file? If yes, then of
course splitting it up into smaller files will use less memory.

> 3) I am using an older gcc 3.4.6 on Solaris 10.

Good grief.

> Sun5# !ma
> make TA_Benchs
> Running Target: TA_Bench Sun
> gcc -D_REENTRANT -ggdb -w  -g -c IB_TWS_API.c Read_IB_Callbacks.c
> gcc Main.c  -ggdb -w IB_TWS_API.o Read_IB_Callbacks.o `pkg-config --cflags
> --libs gtk+-2.0 ` -lcurl -lm -lsocket -lnsl -ggdb -w -o TA_Bench.sun
> Assembler: Main.c
>         "/var/tmp//ccVeiKcL.s", line 15324105 : Out of memory for code
> representation
> make: *** [TA_Benchs] Error 1

This error isn't even coming from GCC, it's coming from the assembler,
which is part of Solaris and not part of GCC. It's trying to assemble
a file that is at least 15 million lines long. That's probably your
problem. Try splitting Main.c into smaller files.

Gcc Error

[Thomas Dineen]

Gentle People:

     When Building a rather large project gcc produces the following error:
"Out of memory for code representation:" See the details below.

What is the best or simplest way to fix this?

1) Will using 64 bit via the -m64 flag fix this?
or
2) I am currently building the project with single gcc call. (The slow way)
Due to some legacy issues with GTK/Cairo and extern variables one big build
seems to work. Would it be better to compile each .C File to a .O file 
and then
link (Faster way).

3) I am using an older gcc 3.4.6 on Solaris 10. Would a simple update to 
a newer
version solve the out of memory problem shown above. (Separate from the -m64
issue shown below)?

Sun5# !ma
make TA_Benchs
Running Target: TA_Bench Sun
gcc -D_REENTRANT -ggdb -w  -g -c IB_TWS_API.c Read_IB_Callbacks.c
gcc Main.c  -ggdb -w IB_TWS_API.o Read_IB_Callbacks.o `pkg-config 
--cflags --libs gtk+-2.0 ` -lcurl -lm -lsocket -lnsl -ggdb -w -o 
TA_Bench.sun
Assembler: Main.c
         "/var/tmp//ccVeiKcL.s", line 15324105 : Out of memory for code 
representation
make: *** [TA_Benchs] Error 1

Sun5# !ma
make TA_Benchs
make: Warning: File `Makefile' has modification time 847 s in the future
Running Target: TA_Bench Sun
gcc -m64 -D_REENTRANT -ggdb -w  -g -c IB_TWS_API.c Read_IB_Callbacks.c
IB_TWS_API.c:1: sorry, unimplemented: 64-bit mode not compiled in
Read_IB_Callbacks.c:1: sorry, unimplemented: 64-bit mode not compiled in
make: *** [TA_Benchs] Error 1

Sun5# gcc --version
gcc (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Re: GCC Error

[Ian Lance Taylor]

fimer <yuanhao12@gmail.com> writes:

>> That said, the most likely problem is that the code is doing something
>> like this:
>> 
>> class C { void C::fn(); }
>> 
>> That is invalid C++ syntax, but older versions of gcc--before gcc 3.4,
>> I think--used to accept it.  The "C::" must be omitted.
>> 
>> Ian
>> 
>> 
>
>
> If it is, can this also be resolved by adding any option to compile command?

As far as I know there is no option for this.  This code was always
invalid according to C++, and as far as I know it was never intended
for g++ to accept it.  That is, it was a bug, and the bug is now
fixed.

Ian

Re: GCC Error

[Jan Engelhardt]

On Friday 2008-12-26 07:29, fimer wrote:
>> 
>> There is little we can do to help you with so little information.
>> 
>> That said, the most likely problem is that the code is doing something
>> like this:
>> 
>> class C { void C::fn(); }
>> 
>> That is invalid C++ syntax, but older versions of gcc--before gcc 3.4,
>> I think--used to accept it.  The "C::" must be omitted.
>
>If it is, can this also be resolved by adding any option to compile command?

Can't you just fix the code?

Re: GCC Error

[fimer]

Ian Lance Taylor-3 wrote:
> 
> Denisius <fanatica0@hotmail.com> writes:
> 
>> Whenever I try to compile I get the following error:
>>
>> "In file included from act_comm.cpp:26:
>> lockers.h:81: error: extra qualification âlockers_object::â on member
>> âget_next_free_locker_numberâ"
>>
>> I am using GCC 4.3.
> 
> There is little we can do to help you with so little information.
> 
> That said, the most likely problem is that the code is doing something
> like this:
> 
> class C { void C::fn(); }
> 
> That is invalid C++ syntax, but older versions of gcc--before gcc 3.4,
> I think--used to accept it.  The "C::" must be omitted.
> 
> Ian
> 
> 


If it is, can this also be resolved by adding any option to compile command?
-- 
View this message in context: http://www.nabble.com/GCC-Error-tp20528286p21172193.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: GCC Error

[Ian Lance Taylor]

Denisius <fanatica0@hotmail.com> writes:

> Whenever I try to compile I get the following error:
>
> "In file included from act_comm.cpp:26:
> lockers.h:81: error: extra qualification âlockers_object::â on member
> âget_next_free_locker_numberâ"
>
> I am using GCC 4.3.

There is little we can do to help you with so little information.

That said, the most likely problem is that the code is doing something
like this:

class C { void C::fn(); }

That is invalid C++ syntax, but older versions of gcc--before gcc 3.4,
I think--used to accept it.  The "C::" must be omitted.

Ian

GCC Error

[Denisius]

Whenever I try to compile I get the following error:

"In file included from act_comm.cpp:26:
lockers.h:81: error: extra qualification âlockers_object::â on member
âget_next_free_locker_numberâ"

I am using GCC 4.3.
-- 
View this message in context: http://www.nabble.com/GCC-Error-tp20528286p20528286.html
Sent from the gcc - Help mailing list archive at Nabble.com.

GCC error

[anissi]

During configuration of GCC-3.3.3 this error occurs:

 

Checking size of short.configure : error :can not determine a size for short

 

So what is my problem ?

 

Thanks in advance;

 

Manssour Anissi

GCC error

[anissi]

During configuration of GCC-3.3.3 this error occurs:

 

Checking size of short.configure : error :can not determine a size for short

 

So what is my problem ?

 

Thanks in advance;

 

Manssour Anissi

Re: gcc error

[Nix]

On Mon, 29 Jul 2002, Rupert Wood muttered drunkenly:
> I think libc6 has been obsoleted by glibc 2.x but I understand updating

No, they are one and the same:

lrwxrwxrwx    1 root     root           13 Jun 27 08:24 /lib/libc.so.6 -> libc-2.2.5.so

(The previous libc, libc.so.5, was derived from glibc-1.0... hence the
current rather confusing situation.)

> a Linux C library is a fairly complex and nasty operation (and that
> libc6 and glibc aren't binary compatible?). However, the C library and

They are ;} the problem is something else.

-- 
`There's something satisfying about killing JWZ over and over again.'
                                        -- 1i, personal communication

RE: gcc error

[Rupert Wood]

Shahin wrote:

> when I am trying to compile simple  C file with headers errors
> are generated....
:
> /usr/include/libio.h:263: parse error before `size_t'

That's very odd - it looks like size_t hasn't been defined yet. This is
usually done in <sys/types.h> via <stddef.h> but these should be
included automatically by any other header files that need them. Try
adding:

    #include <stddef.h>

to the very top of your source.

However, this is a problem with your C library and not with GCC. (Or it
may be an interaction problem - the C library assumes something about
GCC or vice versa.)

I think libc6 has been obsoleted by glibc 2.x but I understand updating
a Linux C library is a fairly complex and nasty operation (and that
libc6 and glibc aren't binary compatible?). However, the C library and
compiler supplied together in a distribution *ought* to cooperate
properly.

Good luck,
Rup.

gcc error

[Linux]

Hi List ,
I have a problem with gcc , 
when I am trying to compile simple  C file with headers errors
are generated....

gateway:/home/users/shahin# gcc -o myC myC.c
In file included from /usr/include/stdio.h:65,
                 from myC.c:1:
/usr/include/libio.h:263: parse error before `size_t'
/usr/include/libio.h:272: parse error before `size_t'
/usr/include/libio.h:368: parse error before `_IO_sgetn'
/usr/include/libio.h:368: parse error before `size_t'
/usr/include/libio.h:368: warning: data definition has no type or storage 
class
In file included from myC.c:1:
/usr/include/stdio.h:179: parse error before `__attribute_malloc__'
/usr/include/stdio.h:179: warning: data definition has no type or storage
class
/usr/include/stdio.h:259: parse error before `size_t'
/usr/include/stdio.h:265: parse error before `size_t'
/usr/include/stdio.h:293: parse error before `size_t'
/usr/include/stdio.h:297: parse error before `size_t'
/usr/include/stdio.h:459: parse error before `fread'
/usr/include/stdio.h:459: parse error before `size_t'
/usr/include/stdio.h:460: warning: data definition has no type or storage
class
/usr/include/stdio.h:462: parse error before `fwrite'
/usr/include/stdio.h:462: parse error before `size_t'
/usr/include/stdio.h:463: warning: data definition has no type or storage
class
/usr/include/stdio.h:467: parse error before `fread_unlocked'
/usr/include/stdio.h:467: parse error before `size_t'
/usr/include/stdio.h:468: warning: data definition has no type or storage
class
/usr/include/stdio.h:469: parse error before `fwrite_unlocked'
/usr/include/stdio.h:469: parse error before `size_t'
/usr/include/stdio.h:470: warning: data definition has no type or storage
class


O/S debian 
kernel 2.2.15
gcc 2.95
And I have installed libc6-dev


Thanks
Shahin