* Sid Boyce
Stefan Fent wrote:
I tested 64bit - everthing available as source should work with 64bit
I didn't say "works out of the box" ;-)
Not so! See other posts. There are 2 I've come across so far that insist in looking in /usr/lib rather than /usr/lib64 for some libs that are only present in /usr/lib64, no matter what you do. Someone posted they were having this problem and I picked 2 random apps just to see if I saw the same problem --- It looks like a libtool problem. kmymoney and amarok.
kmymoney has m4 macros being too old (not libtool!) acinclude.m4 has the libdirs hardcoded. If you have a look at the kmymoney.srpm on the source DVD and do exactly what is done in the prep/build sections, it compiles fine. Didn't look at amarok now, but probably a similar problem.
They build a libtool which says 64 everywhere it should (no mention of just "lib"), but when run, it complains it can't find some of the libs in /usr/lib.
Another app "gxine" builds as a rpm, installs OK, then segfaults when run, ldd on gxine looks good, the strace ends ----- Segmentation fault ------------------------------------------------
The code is not 64bit clean, if you compile with '-Wall', you can see lots of int --> pointer conversions and vice versa. (That is illegal on any arch, but by hasard it works on i386)
Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer ===== LINUX ONLY USED HERE =====
regards, Stefan -- Stefan Fent SuSE Linux AG, Maxfeldstr. 5, D-90409 Nuernberg GPG fingerprint = B226 E3DA 37B0 2170 7403 D19C 18AF E579 9161 4BBC