On Tue, Mar 1, 2011 at 8:34 PM, Matthias Klose d...@debian.org wrote:
I'll make gcc-4.5 the default for (at least some) architectures within the
next
two weeks before more transitions start. GCC-4.5 is already used as the
default
compiler for almost any other distribution, so there
On Fri, Aug 6, 2010 at 11:03 AM, Matthias Klose d...@debian.org wrote:
On 06.08.2010 00:58, brian m. carlson wrote:
On Thu, Aug 05, 2010 at 10:59:18PM +0200, Matthias Klose wrote:
On 08.07.2010 01:42, brian m. carlson wrote:
Package: gcc-4.4
Version: 4.4.4-6
Severity: wishlist
Because
On Thu, Feb 25, 2010 at 7:22 PM, Petr Salinger petr.salin...@seznam.cz wrote:
On Thu, Feb 25, 2010 at 9:23 AM, Petr Salinger petr.salin...@seznam.cz
wrote:
The file, which have to be copied, have size 1701,
but two pages (2*4096) are mmaped. It is allowed on both
Linux and FreeBSD.
When the
On Mon, Nov 23, 2009 at 8:48 AM, Aurelien Jarno aurel...@aurel32.net wrote:
Next steps:
(1) Wait for testsuite results to finish completely. Verify nothing
has regressed.
No regressions.
(2) Remove changes to gcc package debian/rules2 and re-run validation.
Some regressions caused by
On Mon, Nov 23, 2009 at 5:22 AM, Aurelien Jarno aurel...@aurel32.net wrote:
Carlos O'Donell a écrit :
On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin
d...@hiauly1.hia.nrc.ca wrote:
While I set out the glibc types exactly as before (binary compatible),
the alignment restrictions were
On Sun, Nov 22, 2009 at 10:30 AM, John David Anglin
d...@hiauly1.hia.nrc.ca wrote:
The problem appears to have gone away with head. I don't see it with
hpux.
Note that latest version of gcc 4.4 in Debian is built with
--disable-libstdcxx-pch, but the segfault is this present :(
On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell
car...@systemhalted.org wrote:
This happens because the original locale object was created at address
0xbff01c20. However, when apt-get calls std::basic_ioschar,
std::char_traitschar ::init it passes in the address 0xbff01c18.
So we went from
On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin
d...@hiauly1.hia.nrc.ca wrote:
While I set out the glibc types exactly as before (binary compatible),
the alignment restrictions were changed subtly.
Excellent debugging!
I have adjusted the glibc lock structure alignments to try and match
On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno aurel...@aurel32.net wrote:
I confirm, it's what I see in the testsuite log:
| 77
| __signbitl
| version status: incompatible
| GLIBCXX_3.4
| type: function
| status: added
If __signbitl is the only failure in the abi_check, then that's
On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno aurel...@aurel32.net wrote:
Domenico Andreoli a écrit :
On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote:
On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose d...@debian.org wrote:
On 05.11.2009 14:30, Domenico Andreoli wrote:
On Sun, Nov 15, 2009 at 11:03 PM, Felipe Sateler fsate...@gmail.com wrote:
I think the analysis it is wrong, because after the scons clean stage, the
cache is deleted. Relevant section from debian/cdbs/1/class/scons.mk:
scons-clean::
$(DEB_SCONS_INVOKE) $(DEB_SCONS_CLEAN_TARGET)
What is the status of this bug?
Is it up to the package maintainer to disable cloog/ppl for hppa and
try the build again?
Speaking professionally, CodeSourcery enables cloog/ppl for our
toolchain products, but we do a lot of additional testing to verify
everything is working properly.
At the
On Sat, Mar 22, 2008 at 6:10 PM, Aurelien Jarno [EMAIL PROTECTED] wrote:
I have tried to build the glibc with GCC 4.3 on hppa, and rpcgen
segfaults when it is used, so the build fails. I haven't start to
investigate the problem (I started by the architectures where the
problems were
(which?) compiler version, drop
gcj/java support, or fix things)?
Cheers,
Carlos O'Donell
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Sat, Mar 22, 2008 at 5:10 PM, Matthias Klose [EMAIL PROTECTED] wrote:
Carlos O'Donell writes:
- gij/gcj shows bus errors on hppa (either 4.2 or 4.3).
Has gij/gcj ever worked on hppa-linux?
at least the gij/gcj before adding support for generics (1.5) did
work. Now
On Sat, Mar 22, 2008 at 6:10 PM, Aurelien Jarno [EMAIL PROTECTED] wrote:
Carlos O'Donell a écrit :
On Sat, Mar 22, 2008 at 4:33 PM, Matthias Klose [EMAIL PROTECTED] wrote:
For all ports besides alpha and hppa we plan to make GCC-4.3 the
default compilers for lenny.
- both alpha
Aside from the evilness of doing binNMUs of this magnitude, I doubt a
transition that doesn't change the SONAME will work. As soon as the
new libstdc++ is installed, every c++ app on the box will instantly
break. This means if anything happens e.g. to apt during the update, the
system will
Eugene,
This code is completely correct as far as I can see. The second while is
interpreted as a new while loop, and the closing; is short for {} in
this case. I've expanded the code into a more intuitive form here:
int main()
{
int a = 0;
while (a == 0) {
a = 1;
}
It should probably be LD_LIBRARY_PATH=whatever:$${LD_LIBRARY_PATH}
Even better, something like
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}whatever.
It's generally not desirable to introduce null path components into
LD_LIBRARY_PATH if it was unset before, see #152099 for
On Wed, Aug 21, 2002 at 11:55:27AM +0300, Alexei Khlebnikov wrote:
I think this program should not terminate at all because i will
always be one greater than oldi.
I think gcc3.0 has a problem with no optimization then but since
there is later version that works gcc 3.1.1, upgrade.
With
With no optimization the program runs correctly by the rules of integers
representation in memory. See the explanation below.
I must have been asleep last night :} Thanks Alexei!
gcc-3.1 generates similar code, don't have 3.2 on an i386 box
to test. Though 3.2 on an hppa box
On Wed, Aug 21, 2002 at 11:55:27AM +0300, Alexei Khlebnikov wrote:
I think this program should not terminate at all because i will
always be one greater than oldi.
I think gcc3.0 has a problem with no optimization then but since
there is later version that works gcc 3.1.1, upgrade.
With
I think this program should not terminate at all because i will
always be one greater than oldi.
I think gcc3.0 has a problem with no optimization then but since
there is later version that works gcc 3.1.1, upgrade.
Thanks,
Andrew Pinski
Agreed. Infact it doesn't terminate on all the
this helps with understanding the problem.
Get someone to try the 'undef' beforehand case.
Cheers,
Carlos O'Donell Jr.
M,
changes in the system include files which affected the result?
I thought that too, so I put features.h.orig back ontop of features.h.
And it still kept compiling. So I thought, I must have modified
the original back too. No problem, I'm compiling glibc, I have the
source lying around.
25 matches
Mail list logo
