* Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"
@ 2002-10-29 14:51 Francis Hwang
2002-10-29 17:11 ` Ben Elliston
0 siblings, 1 reply; 11+ messages in thread
From: Francis Hwang @ 2002-10-29 14:51 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"
2002-10-29 14:51 Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers" Francis Hwang
@ 2002-10-29 17:11 ` Ben Elliston
2002-10-30 9:55 ` Francis Hwang
0 siblings, 1 reply; 11+ messages in thread
From: Ben Elliston @ 2002-10-29 17:11 UTC (permalink / raw)
To: gcc-help
>>>>> "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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"
2002-10-29 17:11 ` Ben Elliston
@ 2002-10-30 9:55 ` Francis Hwang
2002-10-30 17:02 ` Ben Elliston
2002-11-22 9:17 ` CPP (preprocessor) quandry Eljay Love-Jensen
0 siblings, 2 replies; 11+ messages in thread
From: Francis Hwang @ 2002-10-30 9:55 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"
2002-10-30 9:55 ` Francis Hwang
@ 2002-10-30 17:02 ` Ben Elliston
2002-10-31 11:16 ` Francis Hwang
2002-11-22 9:17 ` CPP (preprocessor) quandry Eljay Love-Jensen
1 sibling, 1 reply; 11+ messages in thread
From: Ben Elliston @ 2002-10-30 17:02 UTC (permalink / raw)
To: gcc-help
>>>>> "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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"
2002-10-30 17:02 ` Ben Elliston
@ 2002-10-31 11:16 ` Francis Hwang
0 siblings, 0 replies; 11+ messages in thread
From: Francis Hwang @ 2002-10-31 11:16 UTC (permalink / raw)
To: gcc-help
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
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* CPP (preprocessor) quandry
2002-10-30 9:55 ` Francis Hwang
2002-10-30 17:02 ` Ben Elliston
@ 2002-11-22 9:17 ` Eljay Love-Jensen
2002-11-22 9:43 ` Buddy Lott
1 sibling, 1 reply; 11+ messages in thread
From: Eljay Love-Jensen @ 2002-11-22 9:17 UTC (permalink / raw)
To: gcc-help
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.)
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: CPP (preprocessor) quandry
2002-11-22 9:17 ` CPP (preprocessor) quandry Eljay Love-Jensen
@ 2002-11-22 9:43 ` Buddy Lott
2002-11-22 10:06 ` Eljay Love-Jensen
0 siblings, 1 reply; 11+ messages in thread
From: Buddy Lott @ 2002-11-22 9:43 UTC (permalink / raw)
To: gcc-help
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.)
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: CPP (preprocessor) quandry
2002-11-22 9:43 ` Buddy Lott
@ 2002-11-22 10:06 ` Eljay Love-Jensen
2002-11-22 10:11 ` Buddy Lott
0 siblings, 1 reply; 11+ messages in thread
From: Eljay Love-Jensen @ 2002-11-22 10:06 UTC (permalink / raw)
To: Buddy Lott, gcc-help
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)
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: CPP (preprocessor) quandry
2002-11-22 10:06 ` Eljay Love-Jensen
@ 2002-11-22 10:11 ` Buddy Lott
2002-11-22 10:32 ` Eljay Love-Jensen
0 siblings, 1 reply; 11+ messages in thread
From: Buddy Lott @ 2002-11-22 10:11 UTC (permalink / raw)
To: gcc-help
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)
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: CPP (preprocessor) quandry
2002-11-22 10:11 ` Buddy Lott
@ 2002-11-22 10:32 ` Eljay Love-Jensen
0 siblings, 0 replies; 11+ messages in thread
From: Eljay Love-Jensen @ 2002-11-22 10:32 UTC (permalink / raw)
To: Buddy Lott; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers"
@ 2002-11-01 10:00 Francis Hwang
0 siblings, 0 replies; 11+ messages in thread
From: Francis Hwang @ 2002-11-01 10:00 UTC (permalink / raw)
To: gcc-help
(I sent this yesterday, but it looked like it didn't go through, so I'm
sending again ...)
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
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2002-11-22 18:32 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-29 14:51 Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers" Francis Hwang
2002-10-29 17:11 ` Ben Elliston
2002-10-30 9:55 ` Francis Hwang
2002-10-30 17:02 ` Ben Elliston
2002-10-31 11:16 ` Francis Hwang
2002-11-22 9:17 ` CPP (preprocessor) quandry Eljay Love-Jensen
2002-11-22 9:43 ` Buddy Lott
2002-11-22 10:06 ` Eljay Love-Jensen
2002-11-22 10:11 ` Buddy Lott
2002-11-22 10:32 ` Eljay Love-Jensen
2002-11-01 10:00 Problem compiling GCC 3.2 on i686-pc-linux: "not enough room for program headers" Francis Hwang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).