>Manually executing make in gcc44-4.3.999-20081212/darwin_objdir
> after a failed build of gcc trunk on i686-apple-darwin9 produces...
This appears to be an include ordering issue. Revision 142738 works
around this to fix the bootstrap issue (although the problem still
exists and is r
* Paolo Bonzini wrote on Fri, Dec 12, 2008 at 10:14:15PM CET:
> >
> > Yes, this is true. But even though the test that sets
> > shlibpath_overrides_runpath is run for every compiler, only one result
> > is then used for all link commands, and that happens to be the result of
> > the C++ test.
>
On Fri, 12 Dec 2008, Vincent Lefevre wrote:
> The release of MPFR 2.4.0 ("andouillette sauce moutarde") is imminent.
> Please help to make this release as good as possible by downloading and
> testing this release candidate:
>
> Changes from version 2.3.2 to version 2.4.0:
> [...]
> - Bug fixes.
Hi - to all of the incredible programmers who make GCC work on so many
computer chip architectures... I have one question:
Will GCC 4.3.X or 4.4.X be ported and operational on the AlphaServer 4XXX
Systems running Debian Linux or any other Linux anytime soon?
Thanks for your time to answer my
Manually executing make in gcc44-4.3.999-20081212/darwin_objdir after a
failed build of gcc trunk on i686-apple-darwin9 produces...
make[5]: Nothing to be done for `all'.
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
"CC_FOR_TARGET=/sw/src/fink.build/gcc44-4.3.999-200
Well, I am baffled. Revision 142714 fails as well so that
revision 142715 can't be at fault for the bootstrap failure
of -m64 libgfortran on i686-apple-darwin9. The strange part
is that I don't see anything in the remaining revision 142714
which could possibly be interacting with the build of
lib
I have narrowed the failure down a bit. Revision 142713 bootstraps
okay on i686-apple-darwin9 but revision 142715 fails at the same
place in the linkage of the -m64 version of libgfortran. I will
back up to revision 142714 next to confirm that the problem was
introduced with...
---
Szia
Pár napja kérdezted hogy nem e tudok egy jó letöltős oldalt. Ãs én
most találtam egyet.
Tele van jobbnál jobb filmekkel, és olcsó! 1 db sms elküldése után 500
kb/sec-el töltöttem napokig a legújabb premier filmeket és meséket!
Küldj most SMS-t,és 5 nap helyet,25-öt a
Building top-of-tree g++ fails in libstdc++ compiling ctype.cc:
In file included from .../gcc/libstdc++-v3/src/ctype.cc:59:
.../build/lin/bld_gcc/build/powerpc-eabi/libstdc++-v3/include/powerpc-eabi/bits/ctype_noninline.h: In static member
function ‘static const char* std::ctype::classic_table()
Between r142699 and r142726, we seemed to have broken the bootstrap
on i686-apple-darwin9. I now see a failure when linking the -m64 version
of libgfortran...
libtool: compile:
/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/gfortran
-B/sw/src/fink.build/gcc44-4.3.999-20081212
Snapshot gcc-4.4-20081212 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081212/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
If it bothers you (does it cause a PR?),
>>> It causes a program to fail to run during build.
>>>
>>> ./gcj-dbtool -n classmap.db || touch classmap.db
>>> /usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool:
>>> error while loading shared libraries: libgcj.so.10: c
Paolo Bonzini writes:
> Andreas Schwab wrote:
>> Paolo Bonzini writes:
>>
>>> If it bothers you (does it cause a PR?),
>>
>> It causes a program to fail to run during build.
>>
>> ./gcj-dbtool -n classmap.db || touch classmap.db
>> /usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjav
On Fri, Dec 12, 2008 at 12:01:07PM -0800, Mike Stump wrote:
> On Dec 10, 2008, at 3:24 PM, IainS wrote:
>> if one did -lgcc_s.10.x -lgcc_s.1 would that break it?
>> ... should it not pick up only the unresolved symbols from s.1
>
> I think this is the best long term solution. Things that can be
On Dec 10, 2008, at 3:24 PM, IainS wrote:
if one did -lgcc_s.10.x -lgcc_s.1 would that break it?
... should it not pick up only the unresolved symbols from s.1
I think this is the best long term solution. Things that can be found
from the system are, those that aren't, come from the newly
Andreas Schwab wrote:
> Paolo Bonzini writes:
>
>> If it bothers you (does it cause a PR?),
>
> It causes a program to fail to run during build.
>
> ./gcj-dbtool -n classmap.db || touch classmap.db
> /usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool:
> error while
Andrew Haley writes:
> What is done to solve the same problem in libstdc++?
It has basically the same problem, but it is even more special anyway
(and doesn't need to link a c++ program).
Andreas.
--
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nü
Andreas Schwab wrote:
> Ralf Wildenhues writes:
>
>> So I don't see how to avoid a test here, and hard-coding "yes" for
>> gentoo and "no" for most other distros sounds pretty ugly.
>
> And not very accurate either.
What is done to solve the same problem in libstdc++?
Andrew.
Ralf Wildenhues writes:
> So I don't see how to avoid a test here, and hard-coding "yes" for
> gentoo and "no" for most other distros sounds pretty ugly.
And not very accurate either.
Andreas.
--
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnbe
* Andreas Schwab wrote on Fri, Dec 12, 2008 at 06:43:45PM CET:
> Paolo Bonzini writes:
>
> > I think it's easiest to define a cache variable somewhere so that the
> > test is forced to pass.
>
> There is no cache variable associated with this test.
That's an independent bug which needs to be fi
- Forwarded message from Philippe Theveny -
From: Philippe Theveny
User-Agent: Thunderbird 2.0.0.18 (X11/20081119)
To: MPFR mailing list
Subject: [MPFR] MPFR-2.4.0 Release Candidate
The release of MPFR 2.4.0 ("andouillette sauce moutarde") is imminent.
Please help to make this release
Paolo Bonzini writes:
> If it bothers you (does it cause a PR?),
It causes a program to fail to run during build.
./gcj-dbtool -n classmap.db || touch classmap.db
/usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool:
error while loading shared libraries: libgcj.so.10
Andreas Schwab wrote:
> Why is the libjava directory configured with raw_cxx?
>
> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>
> The problem with this is that it keeps the libtool test for dynamic
> linker characteristics from working properly, due to the undefined
> re
Andrew Haley writes:
> Does the test even need to be C++?
Probably not, that's just a side effect of being generic and run for
every configured compiler. It's purpose is to test the linker, although
the outcome may be influenced by flags passed implicitly by the
frontend.
Andreas.
--
Andreas
Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Sure, but a generic link test shouldn't require a directory to be
>> configured in any special way.
>
> I don't see where that requirement is special. After all, RAW_CXX is
> definitely not a full C++ compiler (for a good reason, of course).
Ca
Andrew Haley writes:
> Sure, but a generic link test shouldn't require a directory to be
> configured in any special way.
I don't see where that requirement is special. After all, RAW_CXX is
definitely not a full C++ compiler (for a good reason, of course).
Andreas.
--
Andreas Schwab, SuSE L
Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Andreas Schwab wrote:
>>> Andrew Haley writes:
>>>
Andreas Schwab wrote:
> Why is the libjava directory configured with raw_cxx?
>
> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>
> The problem wi
On Fri, Dec 12, 2008 at 03:05:32PM +0100, Martin Jambor wrote:
> In this particular case, the ofset of var_array + its max_size (the
> size of its element, as the function computes it, this is something I
> also do not really understand)
No, it's not the element size, it's the size of the who
Andrew Haley writes:
> Andreas Schwab wrote:
>> Andrew Haley writes:
>>
>>> Andreas Schwab wrote:
Why is the libjava directory configured with raw_cxx?
Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
The problem with this is that it keeps the libto
Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Andreas Schwab wrote:
>>> Why is the libjava directory configured with raw_cxx?
>>>
>>> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>>>
>>> The problem with this is that it keeps the libtool test for dynamic
>>> linker ch
Andrew Haley writes:
> Andreas Schwab wrote:
>> Why is the libjava directory configured with raw_cxx?
>>
>> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>>
>> The problem with this is that it keeps the libtool test for dynamic
>> linker characteristics from working proper
Andreas Schwab wrote:
> Why is the libjava directory configured with raw_cxx?
>
> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>
> The problem with this is that it keeps the libtool test for dynamic
> linker characteristics from working properly, due to the undefined
> refe
Why is the libjava directory configured with raw_cxx?
Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
The problem with this is that it keeps the libtool test for dynamic
linker characteristics from working properly, due to the undefined
reference to __gxx_personality_v0 whic
Iain,
In a perfect world, the real solution to this would be for
Apple to create a new libgcc_s.10.6.dylib which contained the
missing symbols for the newer FSF gcc releases. However since
Apple won't touch GPLv3, this is impossible since it would
require their adopting the libgcc from gcc 4.3 o
Hi,
On Fri, Dec 12, 2008 at 12:26:38PM +0100, Richard Guenther wrote:
> On Fri, Dec 12, 2008 at 11:59 AM, Jan Hubicka wrote:
> >> On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote:
> >> > Hi,
> >> >
> >> > today I have encountered an unpleasant problem with the function
> >> > get_ref_
On Fri, Dec 12, 2008 at 11:59 AM, Jan Hubicka wrote:
>> On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote:
>> > Hi,
>> >
>> > today I have encountered an unpleasant problem with the function
>> > get_ref_base_and_extent() when it claimed a known and constant offset
>> > for the express
> On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote:
> > Hi,
> >
> > today I have encountered an unpleasant problem with the function
> > get_ref_base_and_extent() when it claimed a known and constant offset
> > for the expression insn_4(D)->u.fld[arg.82_3].rt_rtvec. (arg being a
> >
On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote:
> Hi,
>
> today I have encountered an unpleasant problem with the function
> get_ref_base_and_extent() when it claimed a known and constant offset
> for the expression insn_4(D)->u.fld[arg.82_3].rt_rtvec. (arg being a
> default_def pa
38 matches
Mail list logo
