Hi Luke,
a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation" is not a
predefined library unit
it looks like you get this error when the compiler can't find a file that it
thinks forms part of the Ada library (this is determined by the name, eg: a
package Ada.XYZ is expected to be part o
On 14 October 2010 02:07, Paul Koning wrote:
>
> Explicitly setting LD_LIBRARY_PATH seems to cure the problem. It would be
> good to have that called out in the procedures (or, preferably, made not to
> be necessary).
As Ian pointed out, it's documented under --with-mpc et al, although I
only a
On Thu, 2010-10-14 at 09:31 +0200, Duncan Sands wrote:
> Hi Luke,
>
> > a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation" is not a
> > predefined library unit
>
> it looks like you get this error when the compiler can't find a file that it
> thinks forms part of the Ada library (this is
Joakim Tjernlund/Transmode wrote on 2010/10/12 11:00:36:
>
> Alan Modra wrote on 2010/10/11 14:58:45:
> >
> > On Sun, Oct 10, 2010 at 11:20:06AM +0200, Joakim Tjernlund wrote:
> > > Now I have had a closer look at this and it looks much like -fpic
> > > on ppc32, you still use the GOT/TOC to loa
Hi All,
What's the option for dumping the results of loop dependence checking?
such as dependence relations, direction vectors, etc.
Thanks,
Hongtao
Hello list,
When I compile this source with -flto:
> extern int retval;
> int func (void)
> {
> return retval;
> }
... the LTO symbol table contains both symbols:
> /gnu/binutils/git.repo/obj/ld/test/func.o: file format pe-i386
>
> Contents of section .gnu.lto_.symtab.227b80e3:
>
On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn wrote:
>
> Hello list,
>
> When I compile this source with -flto:
>
>> extern int retval;
>> int func (void)
>> {
>> return retval;
>> }
>
> ... the LTO symbol table contains both symbols:
>
>> /gnu/binutils/git.repo/obj/ld/test/func.o: file for
Hello Luke,
Luke A. Guest wrote:
> Can anyone give me a pointer here? I'm totally new to this :/
> a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation" is not a
> predefined library unit
> a-exexpr.adb:39:06: "Ada.Exceptions (body)" depends on
> "Ada.Exceptions.Exception_Propagation (body)"
On 14/10/2010 15:44, Richard Guenther wrote:
> On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn wrote:
>> Nor indeed is there any sign of puts, which is what the generated ltrans0.s
>> file ends up optimising it to (as indeed does the native code in the original
>> .o file). I'm assuming that this is
On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn wrote:
> On 14/10/2010 15:44, Richard Guenther wrote:
>> On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn
>> wrote:
>
>>> Nor indeed is there any sign of puts, which is what the generated ltrans0.s
>>> file ends up optimising it to (as indeed does the native
> Hi Art,
>> No luck with this mornings builds on both x86 and sparc.
>>
>> My last successful i386-pc-solaris2.10 build was several weeks ago; all
> the build attempts fail at this assertion in the function/file below:
>> { ... snip ... }
> I'm building mainline on Solaris 8 to 11 with both Sun
>> On Tue, Oct 12, 2010 at 2:46 PM, Art Haas wrote:
>> Hi.
>>
>> The bootstrap problems I've been having on the x86 Solaris machine,
>> plus the reply from maintainer Rainer Orth that his builds have
>> been succeeding were the impetus to investigate how 'git bisect'
>> works. After a bit of fumb
On 14/10/2010 16:24, Richard Guenther wrote:
> On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn wrote:
>> On 14/10/2010 15:44, Richard Guenther wrote:
>>> I have no idea about the linker-plugin side, but we could of course
>>> avoid generating any calls that were not there before (by for example
>>> st
On Oct 13, 2010, at 9:07 PM, Ian Lance Taylor wrote:
> Paul Koning writes:
>
>> My build system doesn't have LD_LIBRARY_PATH defined so whatever is
>> the Linux default would apply. Perhaps I should change that. But it
>> seems strange that configure finds the prerequisites and then ends up
>
Ralf Wildenhues writes:
> * Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 03:07:46AM CEST:
>> Paul Koning writes:
>> > My build system doesn't have LD_LIBRARY_PATH defined so whatever is
>> > the Linux default would apply. Perhaps I should change that. But it
>> > seems strange that configure
Dave Korn writes:
> The consequence of this is that either there are going to be undefined
> symbols in the final executable, or the linker has to perform another round of
> library scanning. It occurred to me that the semantics of this might even not
> have been decided yet, since ELF platfor
* Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 06:56:27PM CEST:
> Ralf Wildenhues writes:
> > Provide a configure switch --with-hardcoded-gccdeps that adds run path
> > entries for pre-installed support libraries?
>
> I'm fine with that, but it just introduces another configure option for
> peop
Ralf Wildenhues writes:
> * Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 06:56:27PM CEST:
>> Ralf Wildenhues writes:
>> > Provide a configure switch --with-hardcoded-gccdeps that adds run path
>> > entries for pre-installed support libraries?
>>
>> I'm fine with that, but it just introduces an
* Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 08:43:51PM CEST:
> Ralf Wildenhues writes:
> > OK. I won't argue my point further, but I am interested to learn why
> > shared libraries in nonstandard locations are seemingly frowned upon
> > here. Is that due to fragility of the libtool approach
Ralf Wildenhues writes:
>> 2) If we did use libtool to build gcc, then, yes, I would be concerned
>>about the relinking issue.
>
> Why? Because of 'make install' run as root? Any other reasons?
Any install process which is more complex than cp is a matter for
concern. It should only be un
On Thu, Oct 14, 2010 at 12:47:34PM -0700, Ian Lance Taylor wrote:
> > It is not so unlikely that multiple instances of cc1, cc1plus, and f951
> > are running simultaneously. Granted, I haven't done any measurements.
>
> Most projects are written in only one language. Sure, there may be
> cases w
On Thu, 14 Oct 2010, Ian Lance Taylor wrote:
> Ralf Wildenhues writes:
>
> >> 2) If we did use libtool to build gcc, then, yes, I would be concerned
> >>about the relinking issue.
> >
> > Why? Because of 'make install' run as root? Any other reasons?
>
> Any install process which is more
On 10/14/2010 3:31 AM, Duncan Sands wrote:
Hi Luke,
a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation" is not a
predefined library unit
it looks like you get this error when the compiler can't find a file that it
thinks forms part of the Ada library (this is determined by the name, eg
Snapshot gcc-4.5-20101014 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101014/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: Wednesday, October 13, 2010 4:43 PM
> To: sebastianspublicaddr...@googlemail.com
> Cc: gcc@gcc.gnu.org; Joe Buck
> Subject: Re: show size of stack needed by functions
>
> We have had something along these
On 9/29/2010 3:53 PM, Richard Henderson wrote:
> The test program in target-supports.exp is broken, since
> it doesn't preclude the use of cleanups instead. Indeed,
> the init/cleanup3.C seems to be essentially identical to
> the target-supports test.
Why isn't the test program in target-support
26 matches
Mail list logo
