Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"

Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"

[Francis Hwang]

I'm trying to compile GCC 3.2, and configure seems to work, but then when I
make, I get this error:

checking whether the C compiler (...) works... no
configure: error: installation or configuration problem: C compiler cannot
create executables.

So I started looking around in the config.log files, and the first errors I
found were these, in i686-pc-linux-gnu/libstdc++-v3/config.log:

/usr/bin/ld: conftest: Not enough room for program headers (allocated 6,
need 7)
/usr/bin/ld: final link failed: Bad value

I'm getting a lot of these "not enough room for program headers" errors. In
the list archives, I've seen a couple of people saying that running ld -N
works well, but I'm not sure how to set that up when I'm compiling GCC. Is
there some flag that I should use that'll do that for me?

Thanks in advance,

Francis

Re: Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"

[Ben Elliston]

>>>>> "Francis" == Francis Hwang <francis@rhizome.org> writes:

  Francis> I'm trying to compile GCC 3.2, and configure seems to work, but then when I
  Francis> make, I get this error:

  Francis> checking whether the C compiler (...) works... no
  Francis> configure: error: installation or configuration problem: C compiler cannot
  Francis> create executables.

  Francis> /usr/bin/ld: conftest: Not enough room for program headers (allocated 6,
  Francis> need 7)
  Francis> /usr/bin/ld: final link failed: Bad value

What kind of system do you have?  What does `sh config.guess' say?
Is /usr/bin/ld a native linker, or the GNU linker?

Ben

Re: Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"

[Francis Hwang]

Ben Elliston wrote:

> What kind of system do you have?  What does `sh config.guess' say?

i686-pc-linux-gnu

> Is /usr/bin/ld a native linker, or the GNU linker?

> /usr/bin/ld -v
GNU ld version 2.9.1 (with BFD 2.9.1.0.24)

So, the GNU linker, I suppose. BTW, is the version number for ld the same as
the version number for binutils? Cause if so, and binutils is at 2.13, maybe
that means I ought to update that?

Francis

Re: Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"

[Ben Elliston]

>>>>> "Francis" == Francis Hwang <francis@rhizome.org> writes:

  >> What kind of system do you have?  What does `sh config.guess' say?

  Francis> i686-pc-linux-gnu

Of course, as your message subject suggests. Ooops.

  >> /usr/bin/ld -v
  Francis> GNU ld version 2.9.1 (with BFD 2.9.1.0.24)

  Francis> So, the GNU linker, I suppose. BTW, is the version number
  Francis> for ld the same as the version number for binutils? Cause
  Francis> if so, and binutils is at 2.13, maybe that means I ought to
  Francis> update that?

I think that would be a good starting point.  It sounds like it could
be a bug in the linker script used by ld.

Ben

Re: Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"

[Francis Hwang]

So updating binutils helped: I'm getting further, but now I'm stuck
somewhere else. It's on this line:

/home/francis/gcc-3.2/gcc/gcj -B/home/francis/gcc-3.2/i686-pc-linux-gnu/libj
ava/ -B/home/francis/gcc-3.2/gcc/ --encoding=UTF-8 -fclasspath= -fbootclassp
ath=/home/francis/gcc-3.2/i686-pc-linux-gnu/libjava -ffloat-store -g -O2 -MD
 -MT java/lang/Class.lo -MF java/lang/Class.d -c
java/lang/Class.java -fPIC -o java/lang/.libs/Class.o
/tmp/ccWKhZuc.s: Assembler messages:
/tmp/ccWKhZuc.s:2: Warning: Missing string
/tmp/ccWKhZuc.s:2: Error: Rest of line ignored. First ignored character is
`1'.
/tmp/ccWKhZuc.s:17: Error: Unknown pseudo-op:  `.loc'
/tmp/ccWKhZuc.s:28: Error: Unknown pseudo-op:  `.loc'
/tmp/ccWKhZuc.s:34: Error: Unknown pseudo-op:  `.loc'
/tmp/ccWKhZuc.s:43: Warning: Missing string
/tmp/ccWKhZuc.s:43: Error: Rest of line ignored. First ignored character is
`2'.
/tmp/ccWKhZuc.s:44: Warning: Missing string
/tmp/ccWKhZuc.s:44: Error: Rest of line ignored. First ignored character is
`3'.
....

I'll spare you the 6 or so screens of output: It's a lot of "Unknown
pseudo-op" and "Bad .section directive: want a,w,x in string" ... Since this
is Java-specific stuff, and I only really care about C & C++ at this point,
I tried using

./configure --enable-languages=c,c++

but that seemed to open a whole different can of worms ... Any ideas where I
should look next?

Thanks,

Francis

----- Original Message -----
From: "Ben Elliston" <bje@redhat.com>
To: <gcc-help@gcc.gnu.org>
Sent: Wednesday, October 30, 2002 8:02 PM
Subject: Re: Problem compiling GCC 3.2 on i686-pc-linux: "not enough room
for program headers"


> >>>>> "Francis" == Francis Hwang <francis@rhizome.org> writes:
>
>   >> What kind of system do you have?  What does `sh config.guess' say?
>
>   Francis> i686-pc-linux-gnu
>
> Of course, as your message subject suggests. Ooops.
>
>   >> /usr/bin/ld -v
>   Francis> GNU ld version 2.9.1 (with BFD 2.9.1.0.24)
>
>   Francis> So, the GNU linker, I suppose. BTW, is the version number
>   Francis> for ld the same as the version number for binutils? Cause
>   Francis> if so, and binutils is at 2.13, maybe that means I ought to
>   Francis> update that?
>
> I think that would be a good starting point.  It sounds like it could
> be a bug in the linker script used by ld.
>
> Ben
>
>

CPP (preprocessor) quandry

[Eljay Love-Jensen]

Here's a simplified example of my quandry:
#define MkFoo(y) typedef y Foo

Users were happy with this solution, doing things like...
	MkFoo(unsigned char);
...or...
	MkFoo(signed long int);
...as they needed.

But then one day, a programmer needed this.  But the following is No Good...
	MkFoo(enum {a,b,c});
...since the preprocessor thinks the comma belongs to it.

So the usual way of embedding commas as a macro parm is by another set of 
parens:
	MkFoo((enum {a,b,c}));

However, that expands to...
	typedef (enum {a,b,c}) Foo;
...which is still No Good.

What is the preprocessor trick to strip out the extra parens?

Or is there an inverse of stringification (passing the parm in as a quoted 
string and then stripping the quotes would be acceptable, if possible)?

Don't suggest templates.  Not appropriate for this code base.

Thanks,
--Eljay
(I hate macros.)

RE: CPP (preprocessor) quandry

[Buddy Lott]

I can't think of a way to get around this, but maybe if you explain what
purpose this solves (in other wordes, why use the macro) I could think
of a way to accomplish the same thing.

One what that comes to mind:

Typedef enum { a,b,c} EnumWhatever;
MkFoo(Whatever)

> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org]
On
> Behalf Of Eljay Love-Jensen
> Sent: Friday, November 22, 2002 12:17 PM
> To: gcc-help@gcc.gnu.org
> Subject: CPP (preprocessor) quandry
> 
> Here's a simplified example of my quandry:
> #define MkFoo(y) typedef y Foo
> 
> Users were happy with this solution, doing things like...
> 	MkFoo(unsigned char);
> ...or...
> 	MkFoo(signed long int);
> ...as they needed.
> 
> But then one day, a programmer needed this.  But the following is No
> Good...
> 	MkFoo(enum {a,b,c});
> ...since the preprocessor thinks the comma belongs to it.
> 
> So the usual way of embedding commas as a macro parm is by another set
of
> parens:
> 	MkFoo((enum {a,b,c}));
> 
> However, that expands to...
> 	typedef (enum {a,b,c}) Foo;
> ...which is still No Good.
> 
> What is the preprocessor trick to strip out the extra parens?
> 
> Or is there an inverse of stringification (passing the parm in as a
quoted
> string and then stripping the quotes would be acceptable, if
possible)?
> 
> Don't suggest templates.  Not appropriate for this code base.
> 
> Thanks,
> --Eljay
> (I hate macros.)

RE: CPP (preprocessor) quandry

[Eljay Love-Jensen]

Hi Buddy,

The macro wraps the data type in a struct, so as to reduce namespace pollution.

In particular, it avoids...
typedef enum {a,b,c} EnumWhatever;
...such that a, b, c and EnumWhatever now reside in the global (or current) 
namespace.

I have found a GCC-centric solution.  But (unfortunately) the code needs to 
run on other compilers.

#define $MkEnum(name$, enum$...) \
struct name$ {\
   typedef enum { enum$ } Type;\
   Type m;\
   explicit name$ (Type in) : m(in) { }\
   operator Type () const { return m; };\
   }

NOTE: local convention dictates that $ is used to prefix macros (function 
macros or simple substitution), and $ suffix for the macro's 
parameters.  The $ is digestable by all the preprocessors / compilers we 
care about.  Less chance of spurious macro vs. local identifier collision.

Something similar to this trick was proposed / introduced by Stroustrup in 
his C++ Programming Language (3rd and Special editions).  Not the macro 
part, but the wrapping of a POD in a struct to have somewhat stronger type 
safety.  Getting that stronger type safety is the ultimate purpose of the 
macros; the macros serve to reduce repetitive typing -- and thus reduce 
mistakes and simplify maintenance.

A better solution would be to use a language that has this facility 
native.  Stroupstrup told me (paraphrased), "No one is stopping you from 
writing your own language."  (I think he was a little tired of hearing a 
bazillion requests and suggestions for how to "improve" C++.)

Sincerely,
--Eljay
(I hate macros)


At 12:43 PM 11/22/2002 -0500, Buddy Lott wrote:
>I can't think of a way to get around this, but maybe if you explain what
>purpose this solves (in other wordes, why use the macro) I could think
>of a way to accomplish the same thing.
>
>One what that comes to mind:
>
>Typedef enum { a,b,c} EnumWhatever;
>MkFoo(Whatever)

RE: CPP (preprocessor) quandry

[Buddy Lott]

Does it have to work in C or just C++?

It sounds like you are trying to simulate namespaces in c or c++.


Have you you tried something like this

#define NAMESPACE struct y {
#define ENDNAMESPACE }

Then in the code you would do:

NAMESPACE(buddy)

Typedef ...

ENDNAMESPACE

This would also allow you to "customize" name spaces to the whatever the
compiler supports.

> -----Original Message-----
> From: Eljay Love-Jensen [mailto:eljay@adobe.com]
> Sent: Friday, November 22, 2002 1:06 PM
> To: Buddy Lott; gcc-help@gcc.gnu.org
> Subject: RE: CPP (preprocessor) quandry
> 
> Hi Buddy,
> 
> The macro wraps the data type in a struct, so as to reduce namespace
> pollution.
> 
> In particular, it avoids...
> typedef enum {a,b,c} EnumWhatever;
> ...such that a, b, c and EnumWhatever now reside in the global (or
> current)
> namespace.
> 
> I have found a GCC-centric solution.  But (unfortunately) the code
needs
> to
> run on other compilers.
> 
> #define $MkEnum(name$, enum$...) \
> struct name$ {\
>    typedef enum { enum$ } Type;\
>    Type m;\
>    explicit name$ (Type in) : m(in) { }\
>    operator Type () const { return m; };\
>    }
> 
> NOTE: local convention dictates that $ is used to prefix macros
(function
> macros or simple substitution), and $ suffix for the macro's
> parameters.  The $ is digestable by all the preprocessors / compilers
we
> care about.  Less chance of spurious macro vs. local identifier
collision.
> 
> Something similar to this trick was proposed / introduced by
Stroustrup in
> his C++ Programming Language (3rd and Special editions).  Not the
macro
> part, but the wrapping of a POD in a struct to have somewhat stronger
type
> safety.  Getting that stronger type safety is the ultimate purpose of
the
> macros; the macros serve to reduce repetitive typing -- and thus
reduce
> mistakes and simplify maintenance.
> 
> A better solution would be to use a language that has this facility
> native.  Stroupstrup told me (paraphrased), "No one is stopping you
from
> writing your own language."  (I think he was a little tired of hearing
a
> bazillion requests and suggestions for how to "improve" C++.)
> 
> Sincerely,
> --Eljay
> (I hate macros)
> 
> 
> At 12:43 PM 11/22/2002 -0500, Buddy Lott wrote:
> >I can't think of a way to get around this, but maybe if you explain
what
> >purpose this solves (in other wordes, why use the macro) I could
think
> >of a way to accomplish the same thing.
> >
> >One what that comes to mind:
> >
> >Typedef enum { a,b,c} EnumWhatever;
> >MkFoo(Whatever)

RE: CPP (preprocessor) quandry

[Eljay Love-Jensen]

Hi Buddy,

Thanks for the idea!

This "two-part macro" trick will work:
#define $MkEnum(name$) \
struct name$ {\
   typedef enum {

#define $EndEnum(name$) \
   } Type;\
   Type m;\
   name$(Type in) : m(in) { }\
   operator Type () const { return m; }\
}

In use:

$MkEnum(Marx)
	Groucho, Chico, Harpo, Gummo, Zeppo, Karl = 86
$EndEnum(Marx);

Voila!  Slightly awkward, but acceptable.  It could all be put on one line, 
but I'm not sure if that'd be better or worse.

Note:  C++ only, no C.

Thanks,
--Eljay