Compile problem on gcc-4.2-20060204
Hi, I came across the following problem while I was trying to compile gcc-4.2-20060204 on RedHat Linux. checking for shared library run path origin... (cached) done checking for iconv... (cached) yes checking for iconv declaration... (cached) extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking for X... disabled configure: error: GTK+ peers requested but no X library available configure: error: /bin/sh '/root/GCC/gcc-4.2-20060204/libjava/classpath/configure' failed for classpath make[1]: *** [configure-target-libjava] Error 1 make[1]: Leaving directory `/root/GCC/gcc-build' make: *** [bootstrap] Error 2 The shell script I use to call ./configure is: GCC_SRC_DIR=/root/GCC/gcc-4.2-20060204 export BOOT_CFLAGS='-g0 -O2 -pipe' export CFLAGS='-g0 -O2 -pipe' export CXXFLAGS='-g0 -O2 -pipe' export DEBUG_FLAGS='-g0' export LDFLAGS='-s' export LIBRARY_PATH=/usr/lib:/usr/X11R6/lib $GCC_SRC_DIR/configure --enable-languages=c,c++,java --enable-threads\ --disable-nls --disable-debug \ --with-gcc --with-gnu-as --with-gnu-ld \ --disable-shared \ --enable-libgcj --enable-java-awt=gtk,xlib --without-x --enable-java-gc=boehm \ --disable-libgcj-debug The shell script I use to make is: MAKE=make $MAKE \ BOOT_CFLAGS='-O2 -pipe -g0' \ CFLAGS='-O2 -pipe -g0' CXXFLAGS='-O2 -pipe -g0' \ LIBCFLAGS='-O2 -pipe -g0' \ LIBCXXFLAGS='-O2 -pipe -g0 -fno-implicit-templates' \ DEBUG_FLAGS='-g0' LIBGCC2_DEBUG_CFLAGS='-g0' \ JCFLAGS='-pipe -g0' GCJFLAGS='-O2 -pipe -g0' \ LIBGCJ_CFLAGS='-O2 -pipe -g0' \ LIBGCJ_CXXFLAGS='-O2 -pipe -g0 -fno-implicit-templates' \ LDFLAGS='-s' bootstrap I am not sure I have set the parameters right. Any suggestions are highly welcomed. Regards Rui
Re: Compile problem on gcc-4.2-20060204
On Feb 5, 2006, at 10:30 AM, Rui Wang wrote: --enable-java-awt=gtk,xlib --without-x You said without X but included the gtk and the xlib peers. What do you think that should mean? -- Pinski
RE: Compile problem on gcc-4.2-20060204
>> --enable-java-awt=gtk,xlib --without-x > >You said without X but included the gtk and the xlib peers. >What do you think that should mean? > Thank you for the quick reply, would you mind to explain a bit more on how these two related with each other? My understanding from reading the online doc is: --with-x means use the x window system --enable-java-awt= specifies the awt library Cheers Rui
RE: Compile problem on gcc-4.2-20060204
Rui Wang writes: > >> --enable-java-awt=gtk,xlib --without-x > > > >You said without X but included the gtk and the xlib peers. > >What do you think that should mean? > > > Thank you for the quick reply, would you mind to explain a bit more > on how these two related with each other? > > My understanding from reading the online doc is: > --with-x means use the x window system > --enable-java-awt= specifies the awt library The AWT library uses the X window system. Andrew.
gcc internals question, e.g. -fdump-translation-unit
I need a way to extract from gcc, each time gcc runs, the following information: A) When a call to any function F is encountered, I require the full path of the file wherein F is defined. B) When the conversion of any pointer of type STRICT->funcptr (structure member of type pointer to function(of any return type)) to a function call is encountered, I require the full pathname of the file wherein STRUCT is defined. I have looked at things like the -fdump-translation-unit flag, and have managed to perform task 'A" by laborious parsing and analysis of the output but I am looking for a simpler way. I can't do "B", at all. Can I do this by use of some other, or new, or undocumented flag for gcc. If so, then in particular, how will I interpret the output from that flag? Or do I need to patch gcc itself? Where would be the right place to start - what file or function?
Re: Reconsidering gcjx
> "Thorsten" == Thorsten Glaser <[EMAIL PROTECTED]> writes: Thorsten> Why not keep enough support in jc1 to bootstrap ecj? >> > We don't know how much of the language that would be. >> And we can't tell _a priori_. As I understand it, the intention is to >> use upstream sources, and they will change. Thorsten> Just keep the current state then - maybe in a separate frontend Thorsten> only used for bootstrapping, sharing some code with the final, Thorsten> class-only, frontend. And expand it if needed for ecj. This really is not practical. First, on occasion a change to the Eclipse compiler will cause it to stop building with the current gcj. That is, the existing java front end is already too buggy for this plan to work. Second, if we look down the road we can see that there's no subset of the language that we can implement that will let this plan work. E.g., what is to stop the eclipse compiler authors from using generics? Tom
Re: Request for clarification on the 128bit long double requirments
I hope I can clarify the situation. Planning and communication surely
could have been much better, and as the person who coordinated the efforts
that were made, I can be blamed for what we did and when we did it. glibc
has lacked the manpower to be as organized as we would like to be, and
given what we do have, frankly I have no apologies about how we've
scheduled our work.
glibc has not imposed any requirements on GCC. The maintainers for the
affected platforms have known for a long time that the long double type
ought to change and that the sticking point was the glibc compatibility.
Anyone involved in glibc development has known this was on the table for
2.4, and that it would be happening by sometime around now. We did the
glibc work to support -mlong-double-128 for powerpc64, sparc, and alpha.
The support requires building glibc with a GCC that supports -mlong-double-128.
At least as far back as 4.0 (and I think 3.4 as well, modulo compiler bugs)
this works for those platforms. glibc does not mandate any change to GCC.
(glibc is built to support both the old and new long double type ABIs at
both link and compile time, depending on the use of -mlong-double-128 or
its default setting by GCC.)
The glibc work is now ready and it is easy to switch on for each platform
that has used the double==long double ABI in the past. I contacted the GCC
maintainers for s390 and powerpc(32) to suggest we start supporting a good
long double type on those platforms as well. In the case of s390, we
learned that the -mlong-double-128 support was not yet in the compiler at
all. In the case of powerpc32, we learned that its -mlong-double-128
supported only IEEE quad format, while powerpc64 supported IBM extended
format, and the consensus on behalf of powerpc users was that a single long
double format across the 32/64 powerpc architecture is what GNU/Linux users
should have. The upshot is that both s390 and powerpc(32) would require
new GCC changes in order to compile for the new glibc long double ABI. I
told those maintainers that glibc 2.4 would not support a new long double
ABI for each platform unless GCC 4.1 as released could compile that glibc.
The glibc sources make it easy enough to switch a platform down the line
(for the glibc 2.5 ABI, whenever that next release period comes along).
But all agreed that it would be in users' interests not to delay another
year in having a worthwhile long double type for their platforms, and also
in users' interests to have the change happen at the same time for as many
platforms as possible so that efforts to document and explain the change to
users could be consolidated.
Each platform's maintainers took the decision to try to make the necessary
changes in GCC 4.1 so that -mlong-double-128 can be used to compile glibc
2.4, and took the responsibility for that decision with the GCC community.
>From what I gather, the GCC maintainers as whole agreed that these changes
were worth having in 4.1 despite the poor planning. glibc has not forced
anything on GCC maintainers. If s390 -mlong-double-128 support is not in
GCC 4.1, the new long double ABI will not be in glibc 2.4 for s390.
If powerpc -m32 -mlong-double-128 -mabi=ibmlongdouble support is not in
GCC 4.1, the new long double ABI will not be in glibc 2.4 for powerpc(32).
Since the GCC maintainers for these platforms told me that GCC 4.1 would
have it, we have already started building glibc using the new support.
glibc has nothing to do with libstdc++ and does not mandate any changes to
it. Since glibc can support -mlong-double-128, we can expect users will
want libstdc++ to support it as well, with compatibility for old binaries
and for new compiles using either -mlong-double-64 or -mlong-double-128, as
glibc has. As I understand it, the libstdc++ maintainers decided it was
worthwhile to try to support this in GCC 4.1 for the benefit of users on
platforms where -mlong-double-128 is available.
On no platform does glibc force GCC to change its default to -mlong-double-128.
The glibc build itself passes -mlong-double-128, so it can be compiled with
older GCCs on most platforms. A glibc 2.4 installation will work for
a compiler that defaults to -mlong-double-128 or one that defaults to
-mlong-double-64. It is up to the GCC maintainers to decide what the
default is for each platform. As I understand it, the maintainers for
{s390*,powerpc*,sparc*,alpha}-*-linux* configurations decided that making
the default -mlong-double-128 in GCC 4.1 would be beneficial to users.
That decision certainliy does require that the libstdc++ compatibility work
be finished in the 4.1 release. But glibc does not make this requirement.
Thanks,
Roland
Re: Request for clarification on the 128bit long double requirments
Roland McGrath wrote: > I told those maintainers that glibc 2.4 would not support a new long double > ABI for each platform unless GCC 4.1 as released could compile that glibc. > The glibc sources make it easy enough to switch a platform down the line > (for the glibc 2.5 ABI, whenever that next release period comes along). Thanks for the explanation. To clarify this statement: * If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support that, would it be possible to activate the support on the GLIBC 2.4 branch? * If GCC 4.1.x does not support the new ABI, but some later GCC does, will it be possible to either (a) activate the support on the GLIBC 2.4 branch, or (b) add it to the then-current development mainline for GLIBC? (I assume the answer to "b" is "yes", from the above, but I want to clarify because I'd hear that this was a now-or-never change in GLIBC.) Given that the GLIBC with the support is fully backwards-compatible with older GLIBCs, it seems that it would be possible to enable the support later on the GLIBC 2.4 branch, when compilers that can support the feature become available. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [PATCH, RFC] Enable IBM long double for PPC32 Linux
Joe Buck wrote: > I agree that the matter should have been raised far earlier, and that > glibc decisions of this kind should be coordinated with gcc, and in this > case the issue should have been discussed far earlier. Yes, I completely agree. In fact, I think everyone agrees; Roland has suggested as much in his messages as well. As I've indicated before, I'm not pleased with this situation either. It was as much a surprise to me as anyone. There is no question that this change is not in keeping with our branch policy. However, the PowerPC GNU/Linux community seems to want this feature very badly, and has suggested that failure to incorporate these patches in GCC 4.1 would be very bad. My feeling is that it is the PowerPC community which will be harmed if they get the patches wrong, so it's somewhat reasonable to let those folks balance risk and reward. I would not be inclined to hold up the release for these changes, but we're not ready to release yet, so this is not yet an issue. Also, at the time these changes were suggested for 4.1, there were none (minimal?) objections; at this point, the developers have been working on the changes for quite some time. If there were significant objections, they should have been made immediately, and, if necessary, the SC involved at that point. Jakub has already indicated that the libstdc++ changes will not go on the 4.1 branch. I, too, believe those changes are too risky. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
What is text.hot section in elf files ?
Hello everyone, While scrolling down the objdump of the code for /usr/bin/gcc, There is a section called text.hot section, which is normally not present on the elf files. What is that? is it something specific to /usr/bin/gcc only.How can be create such sections in our normal executables ? -- Regards, Sandeep A man with one watch knows what time it is; a man with two watches is never quite sure.
Re: What is text.hot section in elf files ?
Hi, On 2/6/06, Sandeep Kumar <[EMAIL PROTECTED]> wrote: > Hello everyone, > While scrolling down the objdump of the code for /usr/bin/gcc, There > is a section called text.hot section, which is normally not present on > the elf files. What is that? is it something specific to /usr/bin/gcc > only.How can be create such sections in our normal executables ? Seems to be something that gcc generates. Read below: http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/Optimize-Options.html> -freorder-functions Reorder basic blocks in the compiled function in order to reduce number of taken branches and improve code locality. This is implemented by using special subsections text.hot for most frequently executed functions and text.unlikely for unlikely executed functions. Reordering is done by the linker so object file format must support named sections and linker must place them in a reasonable way. Also profile feedback must be available in to make this option effective. See -fprofile-arcs for details. Enabled at levels -O2, -O3, -Os Cheers, -- Ravi Ramaseshan http://www.geocities.com/ramaseshan_ravi/ " Reality is only something we believe in strongly. "
