You just want not to use " --enable-multiarch".
Thanks,
Andrew Pinski
From: linaro-toolchain-boun...@lists.linaro.org
on behalf of Diane Holt
Sent: Wednesday, March 05, 2014 2:33 PM
To: Zhenqiang Chen
Cc: Linaro Toolchain
Subject: Re: Building 4.8 without m
On the other hand, disabling multilib didn't accomplish what I wanted. What
I want is for things to be where they used to be, with regard to /lib,
/usr/lib, /usr/include, and include/C++ -- I don't want that extra
arm-linux-gnueabi subdir under those. Granted, I can re-organize things
once I've got
I don't build eglibc -- I use a prebuilt one. But that does look to have
been the issue. The one I used before was 2.12.1, so I tried a later one
(2.15) and things worked.
Thanks very much,
Diane
On Tue, Mar 4, 2014 at 10:09 PM, Zhenqiang Chen
wrote:
> How do you build your eglibc/glibc?
>
> Ca
That's what I originally tried -- passing in both --disable-multiarch and
--disable-multilib -- but when I include --disable-multiarch, then I'm back
to that same install error I was getting before. I just tried it again,
with the later eglibc (2.15), and it still errors out (i.e., libgcc isn't
inc
Peter Maydell writes:
> On 28 February 2014 14:27, Alexander Graf wrote:
>> Could we check the instruction at the sognaling pc and check
>> if it's a known syscall instruction? No need to replace glibc
>> wrappers then.
>
> No, because the behaviour we want for "started handling
> syscall in qe
> Am 28.02.2014 um 22:21 schrieb Peter Maydell :
>
>> On 28 February 2014 14:12, Alex Bennée wrote:
>> Is this "simply" a case of having a precise state in/around syscalls?
>
> No.
>
>> AIUI we already have such a mechanism for dealing with faults in
>> translated code so this is all aimed at
On 28 February 2014 14:27, Alexander Graf wrote:
> Could we check the instruction at the sognaling pc and check
> if it's a known syscall instruction? No need to replace glibc
> wrappers then.
No, because the behaviour we want for "started handling
syscall in qemu" through to "PC anything up to b
On 28 February 2014 17:08, Alex Bennée wrote:
>
> Peter Maydell writes:
>
>> On 28 February 2014 14:27, Alexander Graf wrote:
>>> Could we check the instruction at the sognaling pc and check
>>> if it's a known syscall instruction? No need to replace glibc
>>> wrappers then.
>>
>> No, because th
On 28 February 2014 14:12, Alex Bennée wrote:
> Is this "simply" a case of having a precise state in/around syscalls?
No.
> AIUI we already have such a mechanism for dealing with faults in
> translated code so this is all aimed at when an asynchronous signal
> arrives somewhere in QEMU's own cod
[Adding Alex Barcelo to the CC]
On Thu, Feb 27, 2014 at 6:20 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 26 Feb 2014, Dann Frazier wrote:
>
>> I've narrowed down the changes that seem to prevent both types of
>> segfaults to the following changes that introduce a wrapper around
>> sigprocmask:
>>
>
Michael Matz writes:
> Hi,
>
> On Tue, 25 Feb 2014, Peter Maydell wrote:
>
>> On 25 February 2014 13:33, Michael Matz wrote
>> > The biggest road-block is that signal vs syscall handling is
>> > fundamentally broken in linux-user and it's unfixable without
>> > assembler implementations of the
Please check your eglibc config. It seams you add the following items.
rtlddir=/lib
libdir=/usr/lib/arm-linux-gnueabi
slibdir=/lib/arm-linux-gnueai
Please remove the "arm-linux-gnueabi" if you do not like it.
Thanks!
-Zhenqiang
On 6 March 2014 08:01, Diane Holt wrote:
> That's what I original
Hi all,
We are using Linaro 13.03 toolchain(
gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux We are trying to
execute a simple test code to check whether ARM assembly code executes on
board or not. Execution is on Arndale Board. Every time We include assembly
function, We get segmentat
On 6 March 2014 14:41, Vishwa wrote:
Hi,
> We are using Linaro 13.03
> toolchain(gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux We are
> trying to execute a simple test code to check whether ARM assembly code
> executes on board or not. Execution is on Arndale Board. Every time We
> i
14 matches
Mail list logo
