NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: toolchain/39338: paxctl doesn't work in powerpc -> i386 cross-builds
The following reply was made to PR toolchain/39338; it has been noted by GNATS.
From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, toolchain-manager%netbsd.org@localhost,
gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc:
Subject: Re: toolchain/39338: paxctl doesn't work in powerpc -> i386
cross-builds
Date: Mon, 11 Aug 2008 02:00:44 -0400
On Aug 10, 4:45pm, tls%coyotepoint.com@localhost
(tls%coyotepoint.com@localhost) wrote:
-- Subject: toolchain/39338: paxctl doesn't work in powerpc -> i386 cross-bui
| >Number: 39338
| >Category: toolchain
| >Synopsis: paxctl doesn't work in powerpc -> i386 cross-builds
| >Confidential: no
| >Severity: serious
| >Priority: medium
| >Responsible: toolchain-manager
| >State: open
| >Class: sw-bug
| >Submitter-Id: net
| >Arrival-Date: Sun Aug 10 16:45:00 +0000 2008
| >Originator: Thor Lancelot Simon
| >Release: NetBSD 4.99.63
| >Organization:
| >Environment:
| Darwin maxey.hvg.tjls.com 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10
| 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
| Architecture: powerpc
| Machine: powerpc
| >Description:
| I modified my local build to set MKPIE for a few executables, and
| to mark them for ASLR with PAXCTL_FLAGS=+A. This works fine in a
| native build or a cross-build from OS X 10.5 on i386. But in a
| cross-build from OS X 10.4 on powerpc, paxctl appears to
| misinterpret the ELF headers. Is this a byte-order problem?
|
| For example:
|
| /home/tls/nbtools/bin/nbpaxctl +A telnet
| nbpaxctl: Bad ELF size 13312 from `telnet' (maybe it's not an ELF?):
Unknown error: 0
|
| For any executable, the error (and misread size) are always the same.
|
| >How-To-Repeat:
| In a NetBSD/i386 build hosted on Mac OS X (powerpc) 10.4, add
| MKPIE=yes and PAXCTL_FLAGS=+A to the Makefile for any executable.
Yes, it is an endian problem. It should auto-detect.
christos
Home |
Main Index |
Thread Index |
Old Index