Branden,
> The long story, for those interested:
> http://lists.debian.org/debian-x/2002/debian-x-200208/msg00091.html
> (and read the whole thread)
> The short story:
> I need people with root on machines of your given architecture to
> compile and run the attached C program. It consists of cod
>
> The arm bug isn't fixed in CVS - It's a toolchain problem that I'll work
> around with a local hack to disable combreloc. HPPA hasn't submitted
> yet. Last I heard ia64's patch wasn't in CVS yet, and I have no idea
> what's up with Sparc. So it doesn't seem like post of the arch bugs are
>
On Sat, Oct 25, 2008 at 1:21 PM, Julien Danjou <[EMAIL PROTECTED]> wrote:
> Is there anything from an outsider that could help?
I've seen this on-and-off again on the hppa-linux port. The issue has,
in my experience, been a compiler problem. My standard operating
procedure is to methodically add v
On Mon, Oct 27, 2008 at 10:05 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> I've seen this on-and-off again on the hppa-linux port. The issue has,
>> in my experience, been a compiler problem. My standard operating
>> procedure is to methodically add volatile to the atomic.h operations
>> until it
On Mon, Oct 27, 2008 at 11:27 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> I understand all that, but the question still stands: is the compiler
> really moving a memory write past a memory barrier? ISTR we did have
> a discussion on gcc-list about that, but it was a while ago and should
> now be
On Tue, Mar 1, 2011 at 8:34 PM, Matthias Klose 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 shouldn't be many
On Tue, Jun 18, 2013 at 8:02 PM, John David Anglin wrote:
> Hi Aurelien,
>
>
> On 18-Jun-13, at 6:05 PM, Aurelien Jarno wrote:
>
>> This is true that they have recently contacted me through another email
>> address, but I haven't found time to work on that. Just stay tuned.
>
>
> That's great news
On Mon, Jul 14, 2014 at 4:36 PM, Aurelien Jarno wrote:
> glibc 2.19 has changed the libc ABI on s390, more specifically the
> setjmp/longjmp functions [1] [2]. Symbol versioning is used to handle
> some cases, but it doesn't work when a jmp_buf variable is embedded
> into a structure, as it change
On Tue, Jul 15, 2014 at 1:18 AM, Aurelien Jarno wrote:
> On Mon, Jul 14, 2014 at 11:14:42PM -0400, Carlos O'Donell wrote:
>> On Mon, Jul 14, 2014 at 4:36 PM, Aurelien Jarno wrote:
>> > glibc 2.19 has changed the libc ABI on s390, more specifically the
>> >
9 matches
Mail list logo
