You are not logged in.
rtorrent is a pretty nice Ncurses BitTorrent client based on libTorrent.
3 weeks ago, I built lib+rtorrent-0.6.3 from default aur PKGBUILD under arch64 and it is working fine.
New version 0.6.4 PKGBUILD differs from previous as it gives specific CXXFLAGS options.
Is there any need/interest to switch from "old" (below) to "new" CXXFLAGS style?
build() {
cd $startdir/src/$pkgname-$pkgver
patch -p1 < ../rtorrent.patch
CXXFLAGS="${CXXFLAGS} -fno-strength-reduce -fno-thread-jumps -fno-inline -fforce-addr"
./configure --prefix=/usr --disable-debug
make || return 1
make DESTDIR=$startdir/pkg install
}
Or switch to new one which I think would be:
if [ "$CARCH" == "x86_64" ]; then
CXXFLAGS="-march=x86_64 -Os -pipe -fno-strength-reduce -fno-thread-jumps -fno-inline -fforce-addr"
./configure --prefix=/usr --disable-debug
else
CXXFLAGS="-march=i686 -Os -pipe -fno-strength-reduce -fno-thread-jumps -fno-inline -fforce-addr"
./configure --prefix=/usr --disable-debug
fi
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline
I don't think that's necessary since the new line already includes ${CXXFLAGS} right at the beginning - if your flags are wrong, check makepkg.conf
Offline
I'll ask the maintainer why this shift since version 0.6.4, and will keep old style for now.
It's easier and adapts itself to one's makepkg.conf
cerebral > "old" PKGBUILD included 'CXXFLAGS="${CXXFLAGS} ', new one (version 0.6.4) includes 'CXXFLAGS="-march=i686 -Os -pipe'.
More general :
Quite some AUR's PKGBUILD do not include 'arch=(i686 x86_64)' even if they do compile under Arch64.
Is there any reason we should not point it to their maintainers ?
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline
Forgot to say that namcap detects dependencies for lib32-gcc & lib32-zlib.
rtorrent runned fine before I got those libs installed, so should I include them in PKGBUILDs ?
$ namcap rtorrent-0.6.4-2.pkg.tar.gz
rtorrent E: Dependency detected and not included (lib32-gcc) from files ['usr/bin/rtorrent']
rtorrent E: Dependency detected and not included (lib32-zlib) from files ['usr/bin/rtorrent']
$ namcap libtorrent-0.10.4-2.pkg.tar.gz
libtorrent E: Dependency detected and not included (lib32-gcc) from files ['usr/lib/libtorrent.so', 'usr/lib/libtorrent.so.9', 'usr/lib/libtorrent.so.9.0.0']
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline
cerebral > "old" PKGBUILD included 'CXXFLAGS="${CXXFLAGS} ', new one (version 0.6.4) includes 'CXXFLAGS="-march=i686 -Os -pipe'.
Ohhh, I see now. My apologies, I misunderstood you. Yes, I'd prefer the ${CXXFLAGS} way myself.
As for the arch= question, not a lot of package submitters/maintainers in the AUR have an x86_64 system, so they don't know whether or not it compiles on Arch64 - they can't put arch=(x86_64) unless they can verify it in some way. Also, the arch= tag is fairly new, so I'd imagine some people don't even know it exists - in general they should be using it though.
Offline
From the libtorrent homepage:
Due to a possible compiler bug, do not compile this release on gcc-4.1.1 with the default -O2 flag. This will cause out-of-memory errors, use -O3 or -Os instead.
The other CXXFLAGS (-fno-strength-reduce -fno-thread-jumps -fno-inline -fforce-addr) were included to work around a bug/feature in gcc-4.0.2. I think it is safe to remove them now.
Offline
It's my understanding you don't need them anymore, but they also aren't hurting anything. I'll take them out for the next release.
Anyone know who _keeps_ marking the aur package as out of date? I'm seriously getting fed up with it.
Offline
As for the arch= question, not a lot of package submitters/maintainers in the AUR have an x86_64 system, so they don't know whether or not it compiles on Arch64 - they can't put arch=(x86_64) unless they can verify it in some way. Also, the arch= tag is fairly new, so I'd imagine some people don't even know it exists - in general they should be using it though.
Oh that makes sense
Haven't had any issue while running rtorrent's built with Arch64's makepkg.conf defaults flags (ok, with 'march=athlon64') as I still use ${CXXFLAGS} even on the latest 0.6.4 release. Maybe I'm lucky.
In fact rtorrent on arch64 is slower to be responsive after it started than on arch i686 (where I use the community package i guess).
Then after a minute it's fully functionnal, and's doing an amazing job here I dunno how to recognize "out-of-memory errors" unless they print something on the console.
codemac : strange. I wouldn't worry if I was you. Some others linuxtracker registered users also use lib/rtorrent. But never one has had version up-to-date to Arch's
:? pliz excuse my poor English; it's getting pretty late here
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline
libtorrent won't compile with preconised CXXFLAGS. I'm 99% newbie when it comes to flags but isn't that because CXXFLAGS doesn't match $CFLAGS (in makepkg.conf)? :oops:
CXXFLAGS="-march=x86_64 -Os -pipe"
./configure --prefix=/usr --disable-debug
checking for madvise... yes
checking signedness of mincore parameter... configure: error: failed, do *not* attempt to use --disable-mincore unless you are running Win32.
make: *** No targets specified and no makefile found. Stop.
On libtorrent mail archive I've found this Have seen this
reported spuriously on borked platforms. Check
config.log to see why the test didn't compile.
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline
The reasoning for the "-march=i686 -Os -pipe" stuff was because I initially was doing -O0 and wasn't sure if it would be overriding the -Os in makepkg.conf. Later I found out that it would override it, but that was after I had released the build. I put it back to -Os when I found out that -O2 was no longer breaking.
I just never changed it back. This will also be reverted to the better syntax once there is a new release. libtorrent and rtorrent will also be going to [extra] once I find a stable net connection at my parents home for t-giving.
Offline
"CXXFLAGS="-march=x86_64 -Os -pipe"
-march=x86-64 ;-)
Offline
maybe some CARCH versus CFLAGS confusion, right ?
uh uh...
---------------> []
EDIT : nope; same error.
Guess I'll have to wait for next codemac's release to have a better responding rtorrent. Anyway, it runs
Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery ) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9
Offline