On Fri, Sep 14, 2007 at 10:50:08AM +0000, Emm Is wrote: > Currently the 0.6.x etch version of rtorrent works just fine but the 0.7.x sid version does not. Actually > the problem a known problem with libTorrent ( http://libtorrent.rakshasa.no/wiki/LibTorrentKnownIssues ) > for which a work-round is to set some CXXFLAGS during configure. I think that's a bit too much void of details - Does it segfault on startup, not start or not able to download anything? "what seems like a compiler bug" 1) seems like a rough guess. most likely changin -mtune simply shuffles variables around enough to make the bug not trigger. 2) if this really is a compiler bug, we'd really like to have a bugreport and get it fixed. In either case, changing the cflags will hide, not fix the problem. Thus it might come back to haunt as in other packages or later versions or rtorrent. > So, could users of other ARM systems report here 1) whether debian rtorrent 0.7.x works for them as is; and/or > 2) whether building libtorrent with CXXFLAGS="-O2 -mcpu=xscale -mtune=xscale" ./configure breaks > rtorrent for them. libtorrent10 (0.11.7-1) + rtorrent (0.7.4-2+b1) works on armel[1] port as is. The major portability differences between arm and armel ports: 1) arm and armel has different struct packing rules - This affects applications that make assumptations on how gcc lays structs in memory. 2) arm and armel have different floating points - I doubt rtorrent and libtorrent depend on specific float behaviour 3) currently armel port is being compiled with gcc-4.2 while most arm buildd's still use gcc-4.1 - Could cause some "variable shuffling" issues Finally for all arm systems (and most other risc systems), unaligned memory access is not acceptable, and will cause undefined results. Cheers, Riku [1] http://wiki.debian.org/ArmEabiPort -- "rm -rf" only sounds scary if you don't have backups
Attachment:
signature.asc
Description: Digital signature