they are moving away from autotools but doesn't mean that is unsupported. When it wouldn't be available anymore, i'll switch to cmake.
about the _FILE_OFFSET_BITS=64, i really don't know what are you talking about. even using autools the flag is set up correctly for i686.
[code]
checking for _FILE_OFFSET_BITS value needed for large files... 64
[/code]
[code]
Config results:
-=-=-=-=-=-=-=-=-

Package:
name: libtorrent-rasterbar
version: 0.15.0
svn revision: 3323

Build environment:
build system: i686-pc-linux-gnu
host system: i686-pc-linux-gnu
target system: i686-pc-linux-gnu

Compiler and linker flags:
CPPFlags: -I/usr/include
CFlags: -lpthread -march=i686 -mtune=generic -O2 -pipe
CXXFlags: -march=i686 -mtune=generic -O2 -pipe
LDFlags: -L/usr/lib -Wl,--hash-style=gnu -Wl,--as-needed
Libs: -lz -lrt
Defs: -DPACKAGE_NAME=\"libtorrent-rasterbar\" -DPACKAGE_TARNAME=\"libtorrent-rasterbar\" -DPACKAGE_VERSION=\"0.15.0\" -DPACKAGE_STRING=\"libtorrent-rasterbar\ 0.15.0\" -DPACKAGE_BUGREPORT=\"arvid@cs.umu.se\" -DPACKAGE_URL=\"http://www.libtorrent.org\" -DPACKAGE=\"libtorrent-rasterbar\" -DVERSION=\"0.15.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD=1 -DHAVE_BOOST=1 -DTORRENT_USE_POSIX_MEMALIGN=1 -DHAVE_BOOST_SYSTEM=1 -DHAVE_BOOST_FILESYSTEM=1 -DHAVE_BOOST_THREAD=1 -D_FILE_OFFSET_BITS=64 -DHAVE_GETHOSTBYNAME=1 -DHAVE_GETHOSTBYNAME_R=1 -DGETHOSTBYNAME_R_RETURNS_INT=1 -DHAVE_LIBRT=1 -DNDEBUG=1 -DTORRENT_USE_OPENSSL=1 -DHAVE_PYTHON=\"2.6\" -DHAVE_BOOST_PYTHON=1 -DHAVE_LIBZ=1 -DHAVE_LINUX_FIEMAP_H=1 -DWITH_SHIPPED_GEOIP_H=1 -DBOOST_ASIO_HASH_MAP_BUCKETS=1021 -DBOOST_EXCEPTION_DISABLE=1 -DTORRENT_BUILDING_SHARED=1

[/code]

note the Defs flags. not to mention that the flag is present in compilation. do make V=1 to see it

Check libtorrent-rasrterbar.pc after configure with ./configure and cmake, described definition is not defined in Cflags section. So thet fail some others build (like leeckraft-git from AUR, with libtorrent-rasterbar configured with cmake - compilation process successfuly). I think that this behaviour is incorrect: lib should indicate all flags that used for compile.

i'm not very happy with the cmake building process. There is no way to enable python building and the resulting shared lib has a different so name. I guess this method is not finished and not supported.

if you really want this feature, you should consider fix it or report it upstream