About vtable generation on ia64
Hi all,
I'am tring to understand how g++ generate vtable for c++ on ia64. Here
is what I got in the CONSTRUCTOR_ELTS in a constructor node: (with g++ 3.3.2
fe)
=== source code ===
Class A
{
Public:
Virtual void f(){}
Virtual void g(){}
};
=== result ===
VAL: 0
SYMOFF: _ZTI1A(0x1901)+0(0x0)
SYMOFF: _ZN1A1fEv(0x1701)+0(0x0)
SYMOFF: _ZN1A1fEv(0x1701)+0(0x0) -- (1)
SYMOFF: _ZN1A1gEv(0x1801)+0(0x0)
SYMOFF: _ZN1A1gEv(0x1801)+0(0x0) --(2)
You can see that (1) and (2) are incorrect according to the abi. They
should be of gp value. I wonder it is a bug in my g++ version, or it just
allocates slots here, and the later phases in g++ will fix this.
Thanks,
Zhenyu
RE: detecting non-PIC in shared lib on Darwin?
On 27 April 2006 20:02, Mike Stump wrote: > On Apr 26, 2006, at 6:26 PM, Jack Howarth wrote: >> readelf -d foo.so | grep TEXTREL >> >> Does anyone know if some mechanism like this is possible for Darwin >> shared libraries? > > A man page is a terrible thing to waste: Yes, but it's an even more terrible thing to wrap: > -segprot name max init (32-bit only) >Specifies the maximum and initial virtual memory > protection of >the named segment, name, to be max and > init ,respectively. The Ouch! :) cheers, DaveK -- Can't think of a witty .sigline today
RE: Gosh, GCC 3.4.6 does so exist...
On 27 April 2006 20:33, Bernard Leak wrote: > Dear List, > do you all remember this? > > Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html > if your memory needs to be jogged. > > One month and a few hours on... has anything changed? Well, at least the front page of gcc.gnu.org is now self-contradictory: " Previous release series: GCC 3.4.5 (released 2005-11-30) Branch status: GCC 3.4.6 is the last release from the 3.4 series; the branch has been closed after the release. " > Is Gabriel Dos Reis still looking into this, or has he been hit > by a bus? Only time will tell. cheers, DaveK -- Can't think of a witty .sigline today
H8300-elf Toolchain based on gcc-4.1 is not working on gdb-6.4.50.20060425.
Hi
We have built "h8300-elf" toolchain based on gcc-4.1 (released). This
toolchain is based on following sources,
Binutils-2.16.92
Gcc-4.1-20060407
Newlib-1.14.0
Also we have built, GDB for "h8300-elf" using gdb-6.4.50.20060425
We have found following problems for all varients of h8 target,
1. "printf" is not working with this toolchain for simulator.
2. Local variables can not be watched using GDB.
Following is the test case used for testing,
int a = 100;
int main ()
{
printf ("\n H8300-ELF toolchain test. Var = %d\n",a);
return 0;
}
Commands are as follow;
#h8300-elf-gcc -ms -g foo.c
#h8300-elf-run a.out
--> This outputs nothing.
We have also tried following combination,
Binutils-2.16.92
Gcc-4.1.0 (released)
Newlib-1.14.0
However, results are same.
Any help on this will be highly appreciated.
Thanks and regards,
Pradeep Sanchana
KPIT Cummins InfoSystems Ltd.
Pune, India
~~~
Free download of GNU based tool-chains for Renesas' SH, H8 and M16C
Series.
The following site also offers free technical support to its users.
Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on February 1, 2006.
~~~
Re: gcc.gnu.org mirror (was: Update of mirrors web page)
On Sat, 8 Apr 2006, Gerald Pfeifer wrote: >> ftp://ftp.club-internet.fr/pub/gcc/ - severly out of date (3.3 is latest) > ftpmaster, I just confirmed this. Would you mind having a look and > letting us know how to proceed? > > If this was this a technical glitch, and you plan to restart > mirroring gcc.gnu.org again, please advise. > > Otherwise we will remove ftp.club-internet.fr from the list at > http://gcc.gnu.org/mirrors.html. I now removed ftp.club-internet.fr from the GCC mirror list by means of the patch below. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.172 diff -u -3 -p -r1.172 mirrors.html --- mirrors.html22 Apr 2006 18:42:36 - 1.172 +++ mirrors.html28 Apr 2006 11:27:43 - @@ -32,7 +32,6 @@ Key fingerprint = 90AA 4704 69D3 965A 87 France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6 dot fr France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks to ftpmaint at irisa dot fr France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, thanks to ftpmaint at uvsq dot fr -France: ftp://ftp.club-internet.fr/pub/gcc/";>ftp.club-internet.fr, thanks to ftpmaster at t-online dot fr Germany, Berlin: ftp://ftp.fu-berlin.de/unix/languages/gcc/";>ftp.fu-berlin.de, thanks to Felix von Leitner (leitner at math dot fu-berlin dot de) Germany: ftp://ftp.gwdg.de/pub/misc/gcc/";>ftp.gwdg.de, thanks to emoenke at gwdg dot de Germany: ftp://ftp.mpi-sb.mpg.de/pub/gnu/mirror/gcc.gnu.org/pub/gcc/";>ftp.mpi-sb.mpg.de, thanks to ftpadmin at mpi-sb.mpg dot de
dwarf2 compiling problem
Hi all. When compiling simple example (even c file with no code in it) with dlx-elf-gcc -c -gdwarf-2 foo.c I get the following error message: internal compiler error: in assemble_integer, at varasm.c:2148 I've defined debugging support in the following way: #define DBX_DEBUGGING_INFO 1 #define DBX_REGISTER_NUMBER(REGNO) (REGNO) #define DWARF2_DEBUGGING_INFO 1 #define PREFERRED_DEBUGGING_TYPE DBX_DEBUG Compiling without debug info or with stab debug format (-g) is working ok gcc:version 4.02 target: DLX CPU (port in progress) Does anyone have an idea what can cause this? Is this a bug in gcc or in target cpu files? Thanks, Nemanja
Re: Gosh, GCC 3.4.6 does so exist...
Dear List, Dave Korn wrote Well, at least the front page of gcc.gnu.org is now self-contradictory: " Previous release series: GCC 3.4.5 (released 2005-11-30) Branch status: GCC 3.4.6 is the last release from the 3.4 series; the branch has been closed after the release. " Not unless "now" means something unexpected. I pointed out this discrepancy in my original message: Correspondingly, the link to this page on http://gcc.gnu.org/ should have its anchor updated from 'GCC 3.4.5' to 'GCC 3.4.6'. For a while I thought that the mention of 3.4.6 on the next line was a mere typo. Yours bemusedly, Bernard Leak
Re: PIC for mcore
On Apr 27, 2006, at 7:05 PM, Qiuker wrote: Is there much difference from different PIC implement? They all do exactly the same thing, allow code to be run at different addresses, so they are all identical, or, yeah, they can be totally different from just doing normal codegen and saving the relocs and fixing the code up at runtime, possibly caching the result of the relocation to disk to saving even that cost, or allocating pic related registers, or not allocating such registers, or having those registers always setup in the prologue to having the prologue not set up the registers, to having GOTs and PLTs to having stubs and lazy pointers. Is it machine related ? Not usually. More OS related I'd say. Darwin is one flavor, ELF another, SunOS another, AT&T another, HPUX another, AIX another and so on... All the same, yet all different.
RE: Gosh, GCC 3.4.6 does so exist...
On 28 April 2006 17:45, Bernard Leak wrote: > Dear List, > > Dave Korn wrote >> Well, at least the front page of gcc.gnu.org is now self-contradictory: >> >> " Previous release series: GCC 3.4.5 (released 2005-11-30) >> Branch status: GCC 3.4.6 is the last release from the 3.4 series; the >> branch has been closed after the release. " >> > Not unless "now" means something unexpected. > I pointed out this discrepancy in my original message: > > Correspondingly, the link to this page on http://gcc.gnu.org/ > should have its anchor updated from 'GCC 3.4.5' to 'GCC 3.4.6'. > For a while I thought that the mention of 3.4.6 on the next > line was a mere typo. > > > > Yours bemusedly, > Bernard Leak Oops, fair enough. I must admit that for the sake of a throwaway joke I didn't do my background research throughly. Caveat laughor! cheers, DaveK -- Can't think of a witty .sigline today
Re: detecting non-PIC in shared lib on Darwin?
On Apr 28, 2006, at 3:18 AM, Dave Korn wrote: Yes, but it's an even more terrible thing to wrap: Welcome to format=flowed. :-( Apparently some companies think that everyone uses an intelligent mail reader. I believe that if you read it with just the right software, you'd see it as intended?.
Richard G. appointed libgcc-math maintainer
It is my pleasure to announce that the steering committee has appointed Richard Guenther libgcc-math maintainer. Please adjust the MAINTAINERS file accordingly, Richard, and Happy Hacking! Gerald
What is the expected behavior of attribute nonnull for C++
Hello,
Consider the following test case:
struct A { bool g(int*, int*) __attribute__((nonnull (2))); };
bool A::g(int* a, int* b) {
if (a)
return 0;
return this;
}
G++ produces the following code for this snippet:
;; Function bool A::g(int*, int*) (_ZN1A1gEPiS0_)
bool A::g(int*, int*) (this, a, b)
{
:
return 0;
}
Notice how we have applied the __attribute__((nonnull (2))) to
the "a" argument, instead of "b", because G++ has added "this"
as an extra, artificial argument. To the middle end, argument 2
of "g" is "a", not "b".
The documentation of the nonnull attribute says:
`nonnull (ARG-INDEX, ...)'
The `nonnull' attribute specifies that some function parameters
should be non-null pointers. For instance, the declaration:
extern void *
my_memcpy (void *dest, const void *src, size_t len)
__attribute__((nonnull (1, 2)));
causes the compiler to check that, in calls to `my_memcpy',
arguments DEST and SRC are non-null.
So do we expect our users to know that they should add 1 to every
ARG-INDEX they pass? That would make this a documentation bug. Or
is this a "real" bug in G++, and should the compiler correct the
ARG-INDEX numbers so that the middle-end doesn't get confused?
Gr.
Steven
Re: What is the expected behavior of attribute nonnull for C++
Steven Bosscher wrote: > The documentation of the nonnull attribute says: > > `nonnull (ARG-INDEX, ...)' > The `nonnull' attribute specifies that some function parameters > should be non-null pointers. For instance, the declaration: > > extern void * > my_memcpy (void *dest, const void *src, size_t len) > __attribute__((nonnull (1, 2))); > > causes the compiler to check that, in calls to `my_memcpy', > arguments DEST and SRC are non-null. > > > So do we expect our users to know that they should add 1 to every > ARG-INDEX they pass? That would make this a documentation bug. Or > is this a "real" bug in G++, and should the compiler correct the > ARG-INDEX numbers so that the middle-end doesn't get confused? I think this is a documentation bug. (Well, really, I think it's a design bug; the attribute should be applied to the parameters, rather than to the entire function type, so that users didn't have to count. In other words, it should be: void f(__attribute((nonnull)) int *); But, that's just me being wishful.) The reason I think this is a documentation bug is that (a) it's always been this way, ergo we'd be breaking backwards compatibility to change it, and (b) some of these kinds of attributes could usefully apply to the "this" pointer. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: What is the expected behavior of attribute nonnull for C++
On 4/28/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: Steven Bosscher wrote: > The documentation of the nonnull attribute says: > > `nonnull (ARG-INDEX, ...)' > The `nonnull' attribute specifies that some function parameters > should be non-null pointers. For instance, the declaration: > > extern void * > my_memcpy (void *dest, const void *src, size_t len) > __attribute__((nonnull (1, 2))); > > causes the compiler to check that, in calls to `my_memcpy', > arguments DEST and SRC are non-null. > > > So do we expect our users to know that they should add 1 to every > ARG-INDEX they pass? That would make this a documentation bug. Or > is this a "real" bug in G++, and should the compiler correct the > ARG-INDEX numbers so that the middle-end doesn't get confused? I think this is a documentation bug. OK. Andrew Pinski already pointed out http://gcc.gnu.org/PR1607 as another example. (Well, really, I think it's a design bug; the attribute should be applied to the parameters, rather than to the entire function type, so that users didn't have to count. In other words, it should be: void f(__attribute((nonnull)) int *); But, that's just me being wishful.) :-) The reason I think this is a documentation bug is that (a) it's always been this way, ergo we'd be breaking backwards compatibility to change it, OK, Richard G. also mentioned this. I'll prepare a documentation patch. and (b) some of these kinds of attributes could usefully apply to the "this" pointer. That is why I was looking at this. We have http://gcc.gnu.org/PR27336, and part of the fix could be to make the 'this' pointer always non-NULL. So far I haven't found anyone who can think of a situation where 'this' can be NULL... Thanks, Gr. Steven
Re: What is the expected behavior of attribute nonnull for C++
Steven Bosscher wrote: > That is why I was looking at this. We have http://gcc.gnu.org/PR27336, > and part of the fix could be to make the 'this' pointer always > non-NULL. So far I haven't found anyone who can think of a situation > where 'this' can be NULL... It can't be NULL. (There are ways to break your program so that it is in fact NULL, but your program already has undefined behavior at that point.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: libstdc++ in a combined tree
DJ Delorie wrote: > Another one like libssp. > > In libstdc++-v3's configure.ac, we see this: > > # This depends on GLIBCXX CHECK_LINKER_FEATURES, but without it assumes no. > GLIBCXX_ENABLE_SYMVERS([yes]) > > The comment lies. If we haven't yet checked the linker features, it > will check them, and configure will fail in a combined build because > newlib/libgloss hasn't yet been installed. > > Since we already check for cross compiling, I've been using this > conditional instead: > > if test x"$gcc_no_link" = xyes; then true; else > # This will run GLIBCXX CHECK_LINKER_FEATURES, so we can't use it if we > can't > # build executables. > GLIBCXX_ENABLE_SYMVERS([yes]) > fi > > but of course this will drop support for cross compiled linux targets > having symbol versioning. Suggestions? The key problem is that we have two ways of determining what features to enable and use: * Autoconf tests * Hard-coded information about the target * --enable-* flags to configure To me, it ought to be a fundamental invariant that the same features are enabled for cross and native compilation. To accomplish that, we need to avoid autoconf tests for features that require running target programs; we must hard-code those. We could hard-code everything, but that becomes difficult, because your target foo-*-bar system isn't quite the same as mine. Hence, my opinion is that we ought never to use autoconf tests to figure these things out, even for native compilation, relying instead on hard-coded target information of --enable-* flags. I think it makes sense to use autoconf for everything that doesn't require a runtime test, to the extent possible. To that end -- and I know this is going to be unpopular -- I think we should require that you have a C library available at libstdc++ build time, either by having one already installed, or by passing appropriate -I/-L options to libstdc++. IIUC, Cygwin has some complicated dependencies that make this difficult. (That's why I assume this suggestion isn't going to be popular.) Assuming people won't accept that restriction, then we ought to either (a) hard-code this choice, or (b) depend on a --enable-* flag. I think it should be considered bad policy to make things work differently for native/cross environments. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Maintainers and new contributions
The SC would like to ensure that before we accept any major contribution, like a new runtime library or back end we have a maintainer lined up for that component. The purpose of this policy is to avoid taking code for which, for whatever reason, we cannot find an available maintainer, or which the maintainers available are in some way unsatisfactory. To be clear, although this discussion was somewhat inspired by the libsse-math stuff, it is in no way a comment about Richard G.; the SC is uniformly pleased to have him maintaining this new component. However, in future, before we accept similar contributions we should clarify that the submitter (or someone else) is willing to be a maintainer, and ask the SC to sign off. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: libstdc++ in a combined tree
> The key problem is that we have two ways And then he lists *three* ;-) > * Hard-coded information about the target I seem to recall a long time ago, talk of a global target capabilities database. It proved too unwieldy to implement. However, a toplevel configury snippet (aka config.gcc) might (1) prove useful, and (2) speed up configure. > To me, it ought to be a fundamental invariant that the same features > are enabled for cross and native compilation. That would be a good goal. > To accomplish that, we need to avoid autoconf tests for features that > require running target programs; The problem I'm running into is that I can't even *link* a target program at that point. The C library (including crt0 and linker scripts) have not yet been installed. > Hence, my opinion is that we ought never to use autoconf tests to > figure these things out, even for native compilation, relying > instead on hard-coded target information of --enable-* flags. Such as --enable-libfoo-a ? > To that end -- and I know this is going to be unpopular -- I think we > should require that you have a C library available at libstdc++ build > time, either by having one already installed, or by passing appropriate > -I/-L options to libstdc++. We normally pass the newlib -I/-L, but in my case, I also need to point into libgloss for a few things. That gets nasty as there's no consistency there.
gcc-4.1-20060428 is now available
Snapshot gcc-4.1-20060428 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060428/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 113359 You'll find: gcc-4.1-20060428.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060428.tar.bz2 C front end and core compiler gcc-ada-4.1-20060428.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060428.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060428.tar.bz2 C++ front end and runtime gcc-java-4.1-20060428.tar.bz2 Java front end and runtime gcc-objc-4.1-20060428.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060428.tar.bz2The GCC testsuite Diffs from 4.1-20060421 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: libstdc++ in a combined tree
DJ Delorie wrote: >> The key problem is that we have two ways > > And then he lists *three* ;-) :-) >> To accomplish that, we need to avoid autoconf tests for features that >> require running target programs; > > The problem I'm running into is that I can't even *link* a target > program at that point. The C library (including crt0 and linker > scripts) have not yet been installed. Right, I understand. Assuming that they exist at this point, you could theoretically pass enough options to make it work -- although, as you say, it's hard to know what those options ought to be. If everything is set up right, it's -I options (for libc headers), -L options (for libc and libgloss), and a -T option (for appropriate linker script). >> Hence, my opinion is that we ought never to use autoconf tests to >> figure these things out, even for native compilation, relying >> instead on hard-coded target information of --enable-* flags. > > Such as --enable-libfoo-a ? In this case, for example, --enable-libstdc++-symvers, or some such. >> To that end -- and I know this is going to be unpopular -- I think we >> should require that you have a C library available at libstdc++ build >> time, either by having one already installed, or by passing appropriate >> -I/-L options to libstdc++. > > We normally pass the newlib -I/-L, but in my case, I also need to > point into libgloss for a few things. That gets nasty as there's no > consistency there. Personally, I'd just not do a one-tree build. :-) But, I know that's popular with lots of folks, for various reasons, including not having to build the compiler twice. The thing I'd discourage you from doing is running autoconf only in some configurations (e.g., only if native, or only if $build = $host). In particular, adding a configure option which is unconditionally honored, if present, but falling back to autoconf if it's not present, doesn't bother me; that still doesn't introduce any differences based on whether we're in a cross, native, or Canadian configuration. It might be that it's more expedient to add such a configure option than to fix things so that you can link, but, really, first and foremost, I'd encourage you to fix things so that you can link. (One big-hammer solution there is to revive the "staged install" proposal, where you would do something like "make install DESTDIR=$objdir/install" after building each component, so that Newlib, libgloss, etc., would already be in this staging area, before building libstdc++. I think that would simplify a lot of our Makefiles -- but, of course, necessitate a fair bit of change.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: libstdc++ in a combined tree
> Right, I understand. Assuming that they exist at this point, you > could theoretically pass enough options to make it work -- although, > as you say, it's hard to know what those options ought to be. If > everything is set up right, it's -I options (for libc headers), -L > options (for libc and libgloss), and a -T option (for appropriate > linker script). I did that for m32c, the problem is that we're explicitly denying linking with a GCC_NO_EXECUTABLES, then we link anyway. It will *always* break, regardless of -I/-L options, because autoconf itself is complaining. > Personally, I'd just not do a one-tree build. :-) But, I know that's > popular with lots of folks, for various reasons, including not > having to build the compiler twice. Right, our internal trees are *all* one-tree builds. It's vastly simpler to just do "./configure; make; make install" than all the nastiness needed to bootstrap a cross compiler. It still won't fix the libstdc++ bug, nor does it catch the libgloss bits. > (One big-hammer solution there is to revive the "staged install" > proposal, where you would do something like "make install > DESTDIR=$objdir/install" after building each component, so that > Newlib, libgloss, etc., would already be in this staging area, > before building libstdc++. I think that would simplify a lot of our > Makefiles -- but, of course, necessitate a fair bit of change.) DJGPP builds this way. The actual Makefile targets *are* in the local install tree, so they get built-in-place. Then you just cp -rp the bits you need (or in djgpp's case, zip them together for distribution).
Re: libstdc++ in a combined tree
DJ Delorie wrote: >> Right, I understand. Assuming that they exist at this point, you >> could theoretically pass enough options to make it work -- although, >> as you say, it's hard to know what those options ought to be. If >> everything is set up right, it's -I options (for libc headers), -L >> options (for libc and libgloss), and a -T option (for appropriate >> linker script). > > I did that for m32c, the problem is that we're explicitly denying > linking with a GCC_NO_EXECUTABLES, then we link anyway. It will > *always* break, regardless of -I/-L options, because autoconf itself > is complaining. Well, that sounds like an autoconf bug. If it refuses to work when presented with a pile of compiler options, that just sounds bad. I know none of my suggestions have been particularly expedient. :-( If you're looking for a short-term hack, the best I can think of is --enable-libstdc++-symvers. I think (but I'm not a libstdc++ maintainer!) that an --enable-libstdc++-symvers option might be acceptable, and that wouldn't run afoul of my concern about using autoconf only in native configurations, etc. I think that problem (which we already have in some places) is truly *awful*; whatever short-term win may come out of it for one party is lost in the long-term loss for the whole project when a configuration behaves differently depending on native/cross/Canadian. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: libstdc++ in a combined tree
> Well, that sounds like an autoconf bug. If it refuses to work when > presented with a pile of compiler options, that just sounds bad. No, I think it's our bug - we do this: GCC_NO_EXECUTABLES GLIBCXX_ENABLE_SYMVERS([yes]) You can't logically expect that to work, no matter how many compiler options we give it - we've told autoconf to not produce any executables, then asked it to test something that requires them. > If you're looking for a short-term hack, the best I can think of is > --enable-libstdc++-symvers. I think (but I'm not a libstdc++ > maintainer!) that an --enable-libstdc++-symvers option might be > acceptable, and that wouldn't run afoul of my concern about using > autoconf only in native configurations, etc. I suppose a small case statement could make reasonable guesses about defaults, too. *-linux* yes, *-elf no, etc.
Re: libstdc++ in a combined tree
DJ Delorie wrote: >> Well, that sounds like an autoconf bug. If it refuses to work when >> presented with a pile of compiler options, that just sounds bad. > > No, I think it's our bug - we do this: > > GCC_NO_EXECUTABLES > GLIBCXX_ENABLE_SYMVERS([yes]) > > You can't logically expect that to work, no matter how many compiler > options we give it - we've told autoconf to not produce any > executables, then asked it to test something that requires them. I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that when we've failed to link things? In general, when libstdc++ isn't working for me in a cross configuration, it's usually because some early libstdc++ autoconf test has failed to link something, and therefore activated GNU_NO_EXECUTABLES, and then everything breaks. Usually, I've botched something in my environment so that the compiler can't link. In your case, you've not botched anything, but you know that your compiler can't link, so this goes back to the basic point that the environment that the libstdc++ configure script is seeing doesn't allow linking. As I've said earlier, inconvenient though I can see it might be in some situations, my preference is that we make it an invariant that (roughly speaking) $CC $CFLAGS *must* be able to link programs when we're configuring libstdc++. >> If you're looking for a short-term hack, the best I can think of is >> --enable-libstdc++-symvers. I think (but I'm not a libstdc++ >> maintainer!) that an --enable-libstdc++-symvers option might be >> acceptable, and that wouldn't run afoul of my concern about using >> autoconf only in native configurations, etc. > > I suppose a small case statement could make reasonable guesses about > defaults, too. *-linux* yes, *-elf no, etc. Yes -- so long as whatever procedure we use is unaffected by cross/native/Canadian. (The case statement is what I meant by "hard-coded" answers.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: libstdc++ in a combined tree
> I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that > when we've failed to link things? No, it's explicit: if test "$build" != "$host"; then # We are being configured with some form of cross compiler. GLIBCXX_IS_NATIVE=false case "$host","$target" in *-*-darwin*,*-*-darwin*) . . . ;; *) GCC_NO_EXECUTABLES ;; esac else GLIBCXX_IS_NATIVE=true fi (remember that $host here is the toplevel $target)
Re: libstdc++ in a combined tree
DJ Delorie wrote: >> I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that >> when we've failed to link things? > > No, it's explicit: I apologize; I didn't realize that. In that case, you're right; the current approach is just busted. It should become an --enable option, or a hard-coded case statement, or an autoconf test that doesn't require linking stuff. In my ideal world, we wouldn't set GCC_NO_EXECUTABLES because we'd be able to link by this point, but I guess it must be there to support exactly the kind of environment you're in. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: libstdc++ in a combined tree
On Fri, 28 Apr 2006, DJ Delorie wrote: > > I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that > > when we've failed to link things? > > No, it's explicit: > > if test "$build" != "$host"; then > # We are being configured with some form of cross compiler. > GLIBCXX_IS_NATIVE=false > case "$host","$target" in > *-*-darwin*,*-*-darwin*) > . . . > ;; > > *) > GCC_NO_EXECUTABLES I hadn't realised there was such configuration separate from crossconfig.m4. This setting of GCC_NO_EXECUTABLES is out of date in that we do now expect to be able to do link tests for glibc and uClibc targets and there's been no sign of complaints about problems arising from this. (I don't think you can ever build a correct shared libstdc++ on a glibc system without the shared glibc already being there to link the shared libstdc++ against. And the functions present in uClibc depend on how it was configured, making link checks essential.) -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Summer of Code: proposal to participate with Partial Transitions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, Its my first message to the list. I am happy for this year found the FSF, and more especially, the gcc project, in the Google Summer of Code[1]. Let me introduce myself, I'm 23 years old Brazilian student of Management, but I also did a couple of courses in the Computer Science. I am a Free Software evangelist, programmer, system administrator, and involved with the Brazilian Free Software Community since 2000. Checking the projects at your soc page[2], I found some ideas, and the Partial Transitions[3] called my attention. I am very interested in submitting a project for the SoC in this category. I read the general ideas and have a project in my mind to execute the task listed in the wiki. Paolo Bonzini is the last people that have change the wiki about this. If anyone have any further suggests, comments, please send to me. So, i need a mentor for talk about this ideas, the gcc TO DO list in this area, and make a proposal to google summer of code, that satisfies me and GCC project. And, if my project will be good the sufficient, use these two months to improve my skills helping the GCC project. Tanks you in advance. I look forward to your reply. 1- http://code.google.com/soc/ 2- http://gcc.gnu.org/wiki/SummerOfCode 3- http://gcc.gnu.org/wiki/Partial%20Transitions -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRFKb1YALkWTeldHvAQLOKw//V9iI16dhgaFShen8rY/oBjTr25EvilRr p3enZj6a7Og4VBzWRf+iTDXOISqZ9yiQV9hchw65j0n1uADFOVFMnOjYmnEWNmv4 zW12qyRRBQ5QamZGh+zRr3Rcjesv+OeaJ9s6MczOoWEIOXqnjD52glmaaxc0UzOM 2+W84hDxrQ2R30Q/3+ATsIsNq6ohHAzkRoG3NY+JQCNTqSa8lh35/W79w18MC8Zu 07OiQzStU+/Vvd2esRDOBOeVqDrGXNYRY9lNq2LO90jXcyDzslAIhjfykv14K9N8 fQnVLLVVo9KZjKz5h+qxVM5wjUwFNUaRe2aUAWWw7+h4ddDhrTp2RCys4Vg91h5m 6qhmZKfY6uZNS9UtPqG0/OlE3lmguiMOEIrf0NAig5ObrspYG9dbulm8Bkii9rIr ZjGw1xHoTREV0K/1xnMqApLBZKCDNp3E22h0Ue9kNJMP4EU3DkV1oB7kmFAtYWJK eCarsZQfRR3zgq12GDfCxq78ORAfSs+yHYYDxHDAHZr32nyizw8hiNMzWOwplEF+ kqt02BdBqTxvt4eQB2tKHz3pUFjXb6KpsQXaZQ7UmeAUWZR40I66thLHRYBpLrEX 1ew41WqLKvEaQfeWGa8MjhdpabDmn/sTDJnpbZaI+J5DwucdLXurcxqbkAjhKc5X LmOBLnCVpZ8= =pn1d -END PGP SIGNATURE-
Re: libstdc++ in a combined tree
On Fri, Apr 28, 2006 at 08:36:50PM -0400, DJ Delorie wrote: > > > Well, that sounds like an autoconf bug. If it refuses to work when > > presented with a pile of compiler options, that just sounds bad. > > No, I think it's our bug - we do this: > > GCC_NO_EXECUTABLES > GLIBCXX_ENABLE_SYMVERS([yes]) > > You can't logically expect that to work, no matter how many compiler > options we give it - we've told autoconf to not produce any > executables, then asked it to test something that requires them. Incorrect. Take a look at the implementation of GCC_NO_EXECUTABLES, please: AS_IF([AC_TRY_EVAL(ac_link)], [gcc_no_link=no], [gcc_no_link=yes]) It sets gcc_no_link based on a link test. If the link test succeeds, then future link tests are allowed. If the link test fails, then future link tests are a fatal error (instead of just reporting the feature being tested for as missing). So if you really have enough to link, then it ought to work fine. What are you building here? A combined tree including newlib? If so, I bet you aren't specifying --with-newlib; that turns off a bunch of link tests. Newlib is special because we arrange to build libstdc++-v3 before building newlib. That we require the configure option is somewhat lame. -- Daniel Jacobowitz CodeSourcery
Re: libstdc++ in a combined tree
> What are you building here? A combined tree including newlib? If > so, I bet you aren't specifying --with-newlib; that turns off a > bunch The toplevel configure automatically adds that in a combined tree (or at least it should), if newlib is being built. The two targets I'm currently working with are m32c-elf and sh-elf. For m32c-elf I added the -I/-L options, thinking it was unique. When sh-elf did similar things I realized otherwise. I'm currently working through a canadian and discovering other problems. We really need to test these things more often :-P
Re: libstdc++ in a combined tree
I apologize; I didn't realize that. In that case, you're right; the current approach is just busted. It should become an --enable option, or a hard-coded case statement, or an autoconf test that doesn't require linking stuff. Really? Like --enable-symvers[=style]? http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html Of course, the issue of the "C" library remains. -benjamin
re: Summer of Code: proposal to participate with Partial Transitions
Eder wrote: Partial Transitions[http://gcc.gnu.org/wiki/Partial%20Transitions] called my attention. I am very interested in submitting a project for the SoC in this category. I read the general ideas and have a project in my mind to execute the task listed in the wiki. You might want to start by picking just one of the "Partial Transitions" tasks and trying to work on it, even before submitting a proposal; that will help you write a better proposal... - Dan
Re: libstdc++ in a combined tree
On Fri, Apr 28, 2006 at 11:21:18PM -0400, DJ Delorie wrote: > > > What are you building here? A combined tree including newlib? If > > so, I bet you aren't specifying --with-newlib; that turns off a > > bunch > > The toplevel configure automatically adds that in a combined tree (or > at least it should), if newlib is being built. Can you verify that this really happened? I know I've had to specify it manually recently. > The two targets I'm currently working with are m32c-elf and sh-elf. > For m32c-elf I added the -I/-L options, thinking it was unique. When > sh-elf did similar things I realized otherwise. I'm currently working > through a canadian and discovering other problems. > > We really need to test these things more often :-P Frankly, people who are interested in using the combined tree build process need to test it - just like you're doing. There's just too many possible configurations. -- Daniel Jacobowitz CodeSourcery
