On Tue, 12 Feb 2013 08:32:23 -0600
Nathan Whitehorn nwhiteh...@freebsd.org wrote:
A related question to these commits: are EABI binaries incompatible
with systems built for OABI? And vice versa? If so, should we mint a
new MACHINE_ARCH for ARM EABI (or OABI, I guess)? The usual
implication of
On 02/13/13 03:25, Andrew Turner wrote:
On Tue, 12 Feb 2013 08:32:23 -0600
Nathan Whitehorn nwhiteh...@freebsd.org wrote:
A related question to these commits: are EABI binaries incompatible
with systems built for OABI? And vice versa? If so, should we mint a
new MACHINE_ARCH for ARM EABI
On Wed, Feb 13, 2013 at 10:25:46PM +1300, Andrew Turner wrote:
On Tue, 12 Feb 2013 08:32:23 -0600
Nathan Whitehorn nwhiteh...@freebsd.org wrote:
A related question to these commits: are EABI binaries incompatible
with systems built for OABI? And vice versa? If so, should we mint a
new
On Wed, 13 Feb 2013 16:00:06 +0200
Konstantin Belousov kostik...@gmail.com wrote:
On Wed, Feb 13, 2013 at 10:25:46PM +1300, Andrew Turner wrote:
On Tue, 12 Feb 2013 08:32:23 -0600
Nathan Whitehorn nwhiteh...@freebsd.org wrote:
A related question to these commits: are EABI binaries
A related question to these commits: are EABI binaries incompatible with
systems built for OABI? And vice versa? If so, should we mint a new
MACHINE_ARCH for ARM EABI (or OABI, I guess)? The usual implication of
sharing a uname -p string is that systems can run each other's binaries
-- that being
Author: andrew
Date: Tue Feb 12 06:04:51 2013
New Revision: 246706
URL: http://svnweb.freebsd.org/changeset/base/246706
Log:
When clang builds libc it may insert calls to __aeabi_* functions. Normally
this is not a problem as they are resolved by libgcc. The exception is for
the
