Re: Libtool and packaging
Hi, If someone has some info on this, do respond... If you do show what kind of source you are referring to, it might help. regards, junichi -- Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/ 183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libtool and packaging
Hello,
I unfortunately deleted all my control files in an attempt to make a
fresh start, but created a very simple debian/rules so as to test if
the --enable-fast-install solved my problem, here it is :
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of
dh-make.
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
CFLAGS = -Wall -g
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif
configure: configure-stamp
configure-stamp:
dh_testdir
# Add here commands to configure the package.
./configure --enable-fast-install --prefix=/usr
--mandir=/usr/share/man
touch configure-stamp
build: build-stamp
build-stamp: configure-stamp
dh_testdir
# Add here commands to compile the package.
$(MAKE)
touch build-stamp
clean:
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
-$(MAKE) clean
dh_clean
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Add here commands to install the package into debian/rheolef.
$(MAKE) install DESTDIR=$(CURDIR)/debian/rheolef
# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.
# Build architecture-dependent files here.
binary-arch: build install
dh_testdir
dh_testroot
dh_installchangelogs ChangeLog
dh_installdocs
dh_installexamples
dh_installman
dh_link
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure
DESTDIR is set correctly for the make install, and so is prefix during
configuration. What makes me think it isn't related to that is the fact
that after compilation, the binaries in .libs directories are already
linked to my shared library, but not to /usr/lib/librheolef.so.513 as
they should be (I checked with flac package, after compilation the flac
binary is linked to a shared library that should be located under /usr/lib).
What I'll try now to convince myself (I hope I'm right) that it was only
a matter of --enable-fast-install, I'll try to disable it and compile
flac (because for this package it is enabled by default, not for
rheolef). If it fails, I'm done with this, if it works I'll have to dig
a little bit further maybe.
Now, the problem I want to resolve is the following one. The upstream
author has included in his sources the config.{guess,sub} files, which I
remove and replace by links to the /usr/share/libtool/config.{guess,sub}
ones). This works fine. But he also gives a ltmain.sh file, and the
libltdl directory which are also to be found into /usr/share/libtool/.
Do I have to replace them too ? If I try (by hand or by using
libtoolize), after configuration I'm getting a non-working libtool, as I
explained in my previous message. Not touching ltmain.sh seems to work,
but I don't want this to be a temporary solution, I want to be sure that
I can let it as it is, or if I have to fix something.
could I have a look at your debian/rules file?
perhaps you are changing prefix instead of DESTDIR when running
the install target?
Are you using CDBS? It should handle autotool packages quite well
out of the box.
No, actually I only use debhelper, but apparently (having read the docs)
it should handle autotools correctly too. I'll give a try to CDBS also
to see.
Thanks for helping Martin :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libtool and packaging
Hello again, I changed the debian/rules of the flac source package, adding a --disable-fast-install at the parameters passed to the configure script and it fails! Well, fails, it doesn't link the libraries as expected. So that's good news, I found the solution to my first problem. The weird thing though is that I found no info whatsoever on the internet, nobody seems to mention that this is something that we should check. Anyway, I'm now going to try to get rid of the other problem, the ltmain.sh issue that is. If someone has some info on this, do respond... Thanks in advance -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libtool and packaging
Hi there, I'm finally on the working computer. After having tried to build the .dev package again, here is the missing info. The command used for compiling 'geo' (one of the binaries that must be linked to librheolef.so (the shared library)) is the following one : /bin/sh ../../libtool --mode=link i386-linux-g++ -O2 -ansi -Wall -Wno-unused -o geo xgeo.o ../lib/librheolef.la i386-linux-g++ -O2 -ansi -Wall -Wno-unused -o .libs/geo xgeo.o ../lib/.libs/librheolef.so -L/usr/lib/gcc-lib/i486-linux/3.3.5 -L/usr/lib/gcc-lib/i486-linux/3.3.5/../../.. -ldl -lstdc++ -lm -lc -lgcc_s -Wl,--rpath -Wl,/here/is/the/top/build/dir/nfem/lib/.libs creating geo When the binary is to be installed, here's the error message I receive : /bin/sh ../../libtool --mode=install /bin/sh ../../config/install-sh -c 'geo' '/here/is/the/top/build/dir/debian/rheolef/usr/bin/geo' /bin/sh ../../config/install-sh -c geo /here/is/the/top/build/dir/debian/rheolef/usr/bin/geo libtool: install: warning: cannot relink `geo' libtool: install: warning: `../lib/librheolef.la' has not been installed in `/usr/lib' Now the funny thing is that if I copy the command above (used to install the binary) and execute it by myself, it works (well almost, I at least get a binary file in debian/rheolef/usr/bin/, but it's still linked to /here/is/the/top/build/dir/nfem/libs/.libs/librheolef.so.513). I downloaded flac source package since it was quite similar to what I'm trying to do, that is an executable depending on a shared library not yet installed, and all of that from the same sources. The main difference I found was the --rpath missing option in the compilation of flac executable. I tried to find a way to remove it but with no luck, I could only append a second --rpath to the end of the command, which was of course ignored. I'm not quite sure what to do now, I'll try to use flac sources to find a way out... Thanks for helping... Alexis Papadopoulos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libtool and packaging
While looking for a solution I realized that it had something to do with the libtool that was generated in the top_builddir. If I used /usr/bin/libtool the -rpath was correct. So with some help from `diff` I found out what seemed to be a cause, enable-fast-install must be enabled. I'm trying now to recompile the whole thing with taking care to pass --enable-fast-install to ./configure. The funny thing is that now the generated libtool script simply fails. If I change the first line though, which defines the variable Xsed=`sed -e ` to Xsed=`/bin/sed -e ` it seems to work. I have no clue why I get this error, I thought it was because of my PATH variable (even though the error isn't `sed command or file not found`, but wno knows), but /bin is there. I really don't understand what is going on. Anyway, I'll spend another couple of days looking for that (unless someone helps ;) ), but at least it will be done... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libtool and packaging
hoi :) On Mon, Jun 27, 2005 at 01:26:47PM +0200, Alexis Papadopoulos wrote: I'm actually trying to create a .deb package from sources using automake, autoconf and libtool. The resulting files consist of some shell scripts, a shared library and some binaries that must be linked to it. this should all just work. if you provide a pointer to the source package in question we can have a look at the problem. -- Martin Waitz signature.asc Description: Digital signature
Re: Libtool and packaging
this should all just work. Well it almost does. The problem is that in tmp/installation/dir/usr/bin (actually it's top_builddir/debian/rheolef/usr/bin) I only get the wrapper scripts created by libtool, and not the executables linked to the library. I don't have now access to the computer on which I'm working therefore I cannot copy the exact error message I'm receiving (because there is one, something goes wrong with libtool when the binaries are installed into debian/rheolef/usr/bin) but the thing is that when I go and check in the source directories, and look into the .libs, the binaries there are linked to my shared library at debian/usr/lib/lib*.so and not /usr/lib/lib*.so). So something goes wrong before... if you provide a pointer to the source package in question we can have a look at the problem. The upstream's author sources are available at : https://gna.org/projects/rheolef I will give you a link with the control files I'm using by tomorrow. Thanks for helping me out. Alexis Papadopoulos - envoyé via Webmail/IMAG ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Libtool and packaging
Hello, I'm actually trying to create a .deb package from sources using automake, autoconf and libtool. The resulting files consist of some shell scripts, a shared library and some binaries that must be linked to it. I'm having the following problem : the binaries are temporarily linked with lib*.la and put into the .libs directories. When 'make install' is called from debian/rules though, the final linking with the lib*.so shared library fails because it cannot be found. The upstream author first installed it in /usr/lib, and then made the libtool calls. I know that I can inform libtool of the location of the lib*.so library, but the problem is that given the fact that I'm installing in a temporary location (debian/mypackage/), the linking will be made against debian/mypackage/usr/lib/lib*.so. What I want to do, is to link against /usr/lib/lib*.so even though it is not there yet. How can that be accomplished ? I downloaded the flac source, since it used the autotools and libtool, while building binaries and shared libraries. They seem to use libtool's relink mode with -rpath. Problem is that I'm not familiar with libtool, and would like to know if it's possible to avoid this method, by using 'libtool install' and just forcing it to link against /usr/lib/lib*.so Hope I was clear enough, thanks in advance Alexis Papadopoulos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
