Summary: | dev-libs/libgcrypt tries to link against native libgpg-error when crosscompiling | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrei Slavoiu <ansla80> |
Component: | [OLD] Library | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | alonbl, bertrand, djkurtz, dschridde+gentoobugs, jlec, patrakov, rpilar, vapier, zerochaos |
Priority: | High | Keywords: | LATER |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.g10code.com/gnupg/issue1261 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 267503 | ||
Attachments: |
build log
libgcrypt-1.4.4.ebuild.patch Updated patch to use SYSROOT instead of ROOT libgpg-error-1.10-0001-Generate-and-install-a-pkg-config-file.patch libgcrypt-1.5.0-0001-Generate-and-install-a-pkg-config-file.patch libgcrypt-1.5.0-0002-Use-pkg-config-to-find-gpg-error.patch |
Description
Andrei Slavoiu
2009-04-25 21:27:23 UTC
Created attachment 189428 [details]
build log
Full build log
Created attachment 189430 [details, diff] libgcrypt-1.4.4.ebuild.patch Patch that fixes this. NOTE: in order for the patch to work the following post-install hook must be used (as I understood from googling about this this is a known problem with libtool) # cat /usr/armv4tl-softfloat-linux-gnueabi/etc/portage/bashrc # This script is inspired from the one posted by Mike Frysinge here http://www.nabble.com/Cross-compile-and-libtool-td13912879.html post_src_install() { for i in $D/usr/lib*/*.la; do if [ -f $i ]; then einfo "post_src_install hook: Fixing .la file $i" sed -i -e "/^libdir=/s:=:='$SYSROOT':" $i else einfo "post_src_install hook: No .la files were installed, nothing to fix" fi done } Comment on attachment 189430 [details, diff]
libgcrypt-1.4.4.ebuild.patch
ROOT variable cannot be used in src_* functions.
Created attachment 189461 [details, diff]
Updated patch to use SYSROOT instead of ROOT
*** Bug 334431 has been marked as a duplicate of this bug. *** configure is using gpg-error-config --libs and gpg-error-config --cflags to get information. I believe that the problem is stemming from the fact that the parent systems gpg-error-config is the one used if it's present. Mike, what is the best way to handle this? Is the solution posted the generally accepted way? Or perhaps something like + if tc-is-cross-compiler; then + export LIBGCRYPT_CONFIG="${SYSROOT}/usr/bin/libgcrypt-config" + fi from bug 267503 Comment on attachment 189461 [details, diff]
Updated patch to use SYSROOT instead of ROOT
SYSROOT should not show up in any ebuild
the actual bug here is that libgcrypt wrongly uses AC_PATH_PATH in its code. it should be using AC_PATH_TOOL. i reported this upstream a while ago. (In reply to comment #8) > the actual bug here is that libgcrypt wrongly uses AC_PATH_PATH in its code. > it should be using AC_PATH_TOOL. i reported this upstream a while ago. > From within the working source directory: find . | xargs grep AC_PATH_PATH returns nothing. find . | xargs grep AC_PATH_TOOL however has results: ./autom4te.cache/requests: 'AC_PATH_TOOL_PREFIX' => 1, ./autom4te.cache/requests: 'AC_PATH_TOOL_PREFIX' => 1, ./autom4te.cache/traces.2:m4trace:m4/libtool.m4:2810: -1- AU_DEFUN([AC_PATH_TOOL_PREFIX], [m4_if($#, 0, [_LT_PATH_TOOL_PREFIX], [_LT_PATH_TOOL_PREFIX($@)])]) ./autom4te.cache/traces.2:m4trace:m4/libtool.m4:2810: -1- AC_DEFUN([AC_PATH_TOOL_PREFIX], [AC_DIAGNOSE([obsolete], [The macro `AC_PATH_TOOL_PREFIX' is obsolete. ./autom4te.cache/traces.1:m4trace:m4/libtool.m4:1889: -1- AC_DEFUN([AC_PATH_TOOL_PREFIX], [AC_REQUIRE([AC_PROG_EGREP])dnl ./autom4te.cache/traces.1:m4trace:m4/libtool.m4:1952: -1- AC_DEFUN([AC_PATH_MAGIC], [AC_PATH_TOOL_PREFIX(${ac_tool_prefix}file, /usr/bin$PATH_SEPARATOR$PATH) ./autom4te.cache/traces.1: AC_PATH_TOOL_PREFIX(file, /usr/bin$PATH_SEPARATOR$PATH) ./autom4te.cache/traces.1:m4trace:configure.ac:136: -1- AC_PATH_TOOL_PREFIX([${ac_tool_prefix}file], [/usr/bin$PATH_SEPARATOR$PATH]) ./autom4te.cache/traces.1:m4trace:configure.ac:136: -1- AC_PATH_TOOL_PREFIX([file], [/usr/bin$PATH_SEPARATOR$PATH]) ./m4/libtool.m4:AU_ALIAS([AC_PATH_TOOL_PREFIX], [_LT_PATH_TOOL_PREFIX]) ./m4/libtool.m4:dnl AC_DEFUN([AC_PATH_TOOL_PREFIX], []) So it looks like upstream may have fixed it (incorrectly)? i meant AC_PATH_PROG autom4te.cache isnt relevant as that is all cache state. none of it comes from upstream. I read what vapier said here: https://bugs.g10code.com/gnupg/issue1261 However, I don't think it is quite as simple as using AC_PATH_TOOL instead of AC_PATH_PROG. This searches for ${host}-gpg-error-config in $PATH. But, at least on my system, gpg-error-config's name isn't prefixed, but we want to search for it in ${SYSROOT}/usr/bin. Hence, the patches by Andrei work... is there a better way of doing this without using ${SYSROOT} or ${ROOT} in the ebuild itself? and that's the point of cross-fix-root that is already part of crossdev The issue seems to persist in dev-libs/libgcrypt-1.5.0-r2. I fixed it using a set of patches that can be found in the ambro-cross overlay at [1] and [2]. (Also attached here and submitted upstream.) [1] http://code.google.com/p/ambro-cross-overlay/source/browse/#svn%2Ftrunk%2Fdev-libs%2Flibgpg-error%2Ffiles [2] http://code.google.com/p/ambro-cross-overlay/source/browse/#svn%2Ftrunk%2Fdev-libs%2Flibgcrypt%2Ffiles Created attachment 324126 [details, diff]
libgpg-error-1.10-0001-Generate-and-install-a-pkg-config-file.patch
Created attachment 324128 [details, diff]
libgcrypt-1.5.0-0001-Generate-and-install-a-pkg-config-file.patch
Created attachment 324130 [details, diff]
libgcrypt-1.5.0-0002-Use-pkg-config-to-find-gpg-error.patch
unfortunately, upstream is stupid and isn't interested in supporting .pc files. and our downstream isn't interested in adding them either. (In reply to comment #17) > unfortunately, upstream is stupid and isn't interested in supporting .pc > files. and our downstream isn't interested in adding them either. Let us hope they changed their opinion. I submitted the patches anyway: http://lists.gnupg.org/pipermail/gnupg-devel/2012-September/026908.html http://lists.gnupg.org/pipermail/gcrypt-devel/2012-September/001985.html (In reply to comment #17) > unfortunately, upstream is stupid and isn't interested in supporting .pc > files. and our downstream isn't interested in adding them either. So I assume that I have the permission to add it? (In reply to comment #19) Diego said no last i heard to cleaning up gpg related packages |