libtool path problem

Bug #751142 reported by Sebastian
60
This bug affects 8 people
Affects Status Importance Assigned to Milestone
libgcrypt11 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: libgcrypt11

The libgcrypt library is installed in /lib, whilst the devel libraries is installed in /usr/lib. In /usr/lib/i386-linux-gnu/libgcrypt.la it says libdir=/lib, which makes libraries look for libgcrypt.la in /lib, and thus fail.

tags: added: multiarch
Sigmun (sigmun84)
Changed in libgcrypt11 (Ubuntu):
status: New → Confirmed
tags: added: natty
Revision history for this message
Steve Langasek (vorlon) wrote :

Thank you for reporting this issue and helping to improve Ubuntu.

Can you please give an example of something that fails as a result of this? The latest version of gnutls26 in natty built successfully against this libgcrypt.

Changed in libgcrypt11 (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Carsten Haitzler (raster-rasterman) wrote :

well first... just take a look at the .la file. it's obviously wrong. the actual location of it doesn't match what the .la internally states. that wrongness DOES create bugs.

evas fails to build because the .la file GENERATED for eet (which evas links to), is linked to libgcrypt, and libtool automatically includes dependencies in the .la files it generates based on the content of dependent .la files, so it happens one level down from the thing that links to gcrypt.

i.e.
evas ---LINK---> eet ---LINK---> gcrypt

evas fails as the .la file for eet (libeet.la) in its dependencies lists the gcrypt... which points to the wrong place. relevant logs and snippets of files here:

-------------------
...
make[5]: Entering directory `/home/raster/C/svn/ssh+svn/e/trunk/evas/src/lib/include'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/home/raster/C/svn/ssh+svn/e/trunk/evas/src/lib/include'
make[5]: Entering directory `/home/raster/C/svn/ssh+svn/e/trunk/evas/src/lib'
  CC main.lo
  CCLD libevas.la
/bin/sed: can't read /lib/i386-linux-gnu/libgcrypt.la: No such file or directory
libtool: link: `/lib/i386-linux-gnu/libgcrypt.la' is not a valid libtool archive
make[5]: *** [libevas.la] Error 1
...
 6:22PM ~/C > ls /lib/i386-linux-gnu/libgcrypt.la
ls: cannot access /lib/i386-linux-gnu/libgcrypt.la: No such file or directory
 6:22PM ~/C > ls /usr/lib/i386-linux-gnu/libgcrypt.la
4.0K /usr/lib/i386-linux-gnu/libgcrypt.la
 6:22PM ~/C > grep libdir /usr/lib/i386-linux-gnu/libgcrypt.la
libdir='/lib/i386-linux-gnu'
 6:22PM ~/C > grep /lib/i386-linux-gnu/libgcrypt.la /usr/local/lib/libeet.la
dependency_libs=' -L/usr/lib/i386-linux-gnu /usr/lib/i386-linux-gnu/libgnutls.la -L/lib/i386-linux-gnu /lib/i386-linux-gnu/libgcrypt.la -L/usr/local/lib /usr/local/lib/libeina.la -lrt -ldl -lz /usr/lib/i386-linux-gnu/libjpeg.la -lm'
-----------

notice the libeet.la in the dependency_libs has taken the /lib/i386-linux-gnu/libgcrypt.la which is based on the libgcrypt.la file name plus its erroneous libdir entry. that is standard (correct) behavior for libtool, but the supplied data in the libgcrypt.la file is wrong, thus the problem. fix libdir to be /usr/lib/i386-linux-gnu and it's all hunky dory.

Revision history for this message
Sigmun (sigmun84) wrote :

For example, the compilation of sbmanager isn't possible out of the box. By editing /usr/lib/i386-linux-gnu/libgcrypt.la and modifying 'libdir=/lib' into 'libdir=/usr/lib/i386-linux-gnu', the compilation was possible.

make all-recursive
make[1]: entrant dans le répertoire « /usr/local/src/sbmanager »
Making all in data
make[2]: entrant dans le répertoire « /usr/local/src/sbmanager/data »
make[2]: Rien à faire pour « all ».
make[2]: quittant le répertoire « /usr/local/src/sbmanager/data »
Making all in src
make[2]: entrant dans le répertoire « /usr/local/src/sbmanager/src »
  CC libsbmanager_la-device.lo
  CC libsbmanager_la-gui.lo
  CC libsbmanager_la-sbmgr.lo
  CCLD libsbmanager.la
  CC sbmanager-main.o
  CCLD sbmanager
libtool: link: cannot find the library `/lib/i386-linux-gnu/libgcrypt.la' or unhandled argument `/lib/i386-linux-gnu/libgcrypt.la'
make[2]: *** [sbmanager] Erreur 1
make[2]: quittant le répertoire « /usr/local/src/sbmanager/src »
make[1]: *** [all-recursive] Erreur 1
make[1]: quittant le répertoire « /usr/local/src/sbmanager »
make: *** [all] Erreur 2

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libgcrypt11 - 1.5.0-1

---------------
libgcrypt11 (1.5.0-1) experimental; urgency=low

  * Merge multi-arch changes (1.4.6-6 and 1.4.6-7), drop libtool la file.
  * Drop CFLAGS += -Wall again, it has become unnecessary.
  * New upstream version.
  * Bump shlibs

libgcrypt11 (1.5.0~beta1-1) experimental; urgency=low

  * Development release.
  * Drop 13_ftbfs_gold.diff. (applied upstream)
  * Bump shlibs.
  * Run ./configure with --enable-static option, it is disabled by default
    now.
  * Set CFLAGS += -Wall, the latest combination of cdbs + dpkg-dev does not
    seem to set it by default.

libgcrypt11 (1.4.6-7) unstable; urgency=low

  * Do not use multiarch path in udeb. (Thanks, Colin Watson)

libgcrypt11 (1.4.6-6) unstable; urgency=low

  * Stop shipping libtool la file. This should take care of LP: #751142
  * Convert to multi-arch.
    + configure with --libdir=/lib/$(DEB_HOST_MULTIARCH), update
      *.install accordingly.
    + Bump cdbs Build-Depends to 0.4.93 (required for expanding
      $(DEB_HOST_MULTIARCH)).
    + Bump debhelper b-d to 8.1.3 (for ${misc:Pre-Depends}).
    + runtime library is Multi-Arch: same and has Pre-Depends:
      ${misc:Pre-Depends}.
    + This is based on 1.4.6-5ubuntu1, however some differences remain. -dbg
      package is not Multi-Arch: same (Due to usr/lib/debug/usr/bin/*). We
      ship the so-symlink in /lib/$(DEB_HOST_MULTIARCH) instead of
      /usr/lib/$(DEB_HOST_MULTIARCH).
 -- Rico Tzschichholz <email address hidden> Mon, 11 Jul 2011 11:22:32 +0000

Changed in libgcrypt11 (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
Deepak C Shetty (dpkshetty) wrote :

Hi,
  I am still seeing this problem. I have ubuntu 11.04 desktop ... and i faced the same issue...
I tried using apt-get to get latest libgcrypt ( thinking the above fix is not there), but apt-get says i have latest libgcrypt installed.

Pls see the problem below.
I tried to manually change the libdir to /usr/lib/... as a workaround mentioned above, and then tried executing right from the ./autoconfiscate.sh step ( libvirt-cim does not have ./autogen) but i still see the below issue.. appreciate a response...

dpkshetty@deepak-ThinkPad-T60p:~/work/libvirt-cim/libvirt-cim$ make
make all-recursive
make[1]: Entering directory `/home/dpkshetty/work/libvirt-cim/libvirt-cim'
Making all in libxkutil
make[2]: Entering directory `/home/dpkshetty/work/libvirt-cim/libvirt-cim/libxkutil'
Making all in tests
make[3]: Entering directory `/home/dpkshetty/work/libvirt-cim/libvirt-cim/libxkutil/tests'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/dpkshetty/work/libvirt-cim/libvirt-cim/libxkutil/tests'
make[3]: Entering directory `/home/dpkshetty/work/libvirt-cim/libvirt-cim/libxkutil'
  CC cs_util_instance.lo
  CC misc_util.lo
  CC device_parsing.lo
  CC xmlgen.lo
  CC infostore.lo
  CC pool_parsing.lo
  CC acl_parsing.lo
  CCLD libxkutil.la
/bin/sed: can't read /lib/i386-linux-gnu/libgcrypt.la: No such file or directory
libtool: link: `/lib/i386-linux-gnu/libgcrypt.la' is not a valid libtool archive
make[3]: *** [libxkutil.la] Error 1
make[3]: Leaving directory `/home/dpkshetty/work/libvirt-cim/libvirt-cim/libxkutil'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/dpkshetty/work/libvirt-cim/libvirt-cim/libxkutil'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dpkshetty/work/libvirt-cim/libvirt-cim'
make: *** [all] Error 2

Revision history for this message
Steve Langasek (vorlon) wrote :

This issue has been fixed for the 11.10 release, not for 11.04.

Revision history for this message
Deepak C Shetty (dpkshetty) wrote :

Hi Steve,
  Thanks for your help. So is there any way to fix it ( via some workarounds / patches) in 11.04 ?
I am ok with some manual steps if possible to get around this issue in 11.04 , pls let me know.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 751142] Re: libtool path problem

On Sat, Oct 29, 2011 at 04:30:31AM -0000, Deepak Shetty wrote:
> Hi Steve,
> Thanks for your help. So is there any way to fix it ( via some workarounds / patches) in 11.04 ?
> I am ok with some manual steps if possible to get around this issue in 11.04 , pls let me know.

You can either edit /usr/lib/i386-linux-gnu/libgcrypt.la by hand to replace
libdir=/lib with libdir=/usr/lib/i386-linux-gnu, or create a
/lib/libgcrypt.la symlink pointing to the real file.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Deepak C Shetty (dpkshetty) wrote :

>You can either edit /usr/lib/i386-linux-gnu/libgcrypt.la by hand to replace
>libdir=/lib with libdir=/usr/lib/i386-linux-gnu, or create a
>/lib/libgcrypt.la symlink pointing to the real file.

I had tried changing libdir=/usr/lib/... manually.
but when i do make the SUBDIR .la gets dynamically generated and it still points to /lib/....
I even tried starting from the ./autogen step for my module compilation, it did not help.
Wanted to document that here.

Will try the symlink approach. Thanks Steve.

Revision history for this message
Deepak C Shetty (dpkshetty) wrote :

Using the softlink approach work.. thanks again !

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.