Hello,
On Sat, Dec 24, 2005 at 02:38:11PM +0100, Kurt Roeckx wrote:
> Package: cpufrequtils
> Version: 0.4-1
> Severity: important
>
> Hi,
>
> Your package is failing to build on amd64 with the following
> error:
> x86_64-linux-gnu-gcc -shared .libs/cpufreq.o .libs/sysfs.o .libs/proc.o
> -lsysfs -Wl,-soname -Wl,libcpufreq.so.0 -o .libs/libcpufreq.so.0.0.0
> /usr/bin/ld:
> /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64/libsysfs.a(libsysfs_la-sy+sfs_utils.o):
> relocation R_X86_64_32 against `a local symbol' can not be used when making a
> shared object; recompile with -fPIC
> /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64/libsysfs.a: could not
> read symbols: Bad value
>
> It's linking against the static libsysfs.a instead of against the
> shared libsysfs.so.
can't it be an issue in /lib vs /lib64 instead? Maybe libtool is trying
to statically link because it can't find the shared object in /lib64
(using /lib${libsuff} in the search path).
> This is caused by this change in libtool.m4 (which is in
> all the aclocal.m4's):
> + # Find out which ABI we are using (multilib Linux x86_64 hack).
> + libsuff=
> + case "$host_cpu" in
> + x86_64*)
> + echo '[#]line __oline__ "configure"' > conftest.$ac_ext
> + if AC_TRY_EVAL(ac_compile); then
> + case `/usr/bin/file conftest.$ac_objext` in
> + *64-bit*)
> + libsuff=64
> + ;;
> + esac
> + fi
> + rm -rf conftest*
> + ;;
> + *)
> + ;;
> + esac
> + sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff}"
> + sys_lib_search_path_spec="/lib${libsuff} /usr/lib${libsuff}
> /usr/local/lib${libsuff}"
>
> This seems to be coming from a gentoo version of libtool.
it does, that's what Dominik (upstream) is using (afair).
> After removing that from libcpufreq/aclocal.m4 and regenerating
> the auto* files, it builds without problems.
aren't there less instrusive measures? depending on libtool sucks.
If my guess above is correct then you don't have /lib64, does linking
/lib64 -> /lib helps (I'm not proposing it as a solution, I'd just like
to confirm my idea, in that case I could use the LDFLAGS variable in
debian/rules).
I'm no multiarch guru, so please forgive me (and please correct me) if I
told something wrong.
--
mattia
:wq!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
