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]
