Control: clone -1 -2
Control: clone -1 -3
Control: affects -2 libxslt
Control: affects -3 libxslt
Control: block -1 by -2
Control: block -1 by -3
Control: retitle -2 should flush timestamps early enough
Control: retitle -3 should flush timestamps early enough
Control: reassign -2 hurd
Control: reassign -3 kfreebsd-10
Hello,
Andreas Beckmann, on Sat 08 Oct 2016 11:22:41 +0200, wrote:
> libtool: relink: cc -shared -fPIC -DPIC .libs/libxsltmod_la-libxslt.o
> .libs/libxsltmod_la-types.o .libs/libxsltmod_la-libxslt-py.o
> -L/«PKGBUILDDIR»/debian/tmp-dbg/usr/lib/i386-kfreebsd-gnu
> -L/usr/lib/i386-kfreebsd-gnu -lxslt -lexslt -lpython2.7 -lpthread -ldl -lutil
> -lm -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now
> -Wl,--as-needed -Wl,-soname -Wl,libxsltmod.so -o .libs/libxsltmod.so
For information, here are my findings so far:
- The link should be including the -L../debian/tmp/usr/lib/... since the
.la file contains that but it's not.
- That is apparently due to the make install insisting on recompiling
e.g. the libxslt.c file.
- That is due to the dependency on e.g. libxsltclass.py: running ls just
before the make install step shows that its timestamp is actually
after the libxslt.lo file.
- libxsltclass.py is generated by the generator.py python script at
build time.
- That kind of odd timestamp issue has already be seen to pose problems
in cmake.
In my memory, this odd timestamp is due to kFreeBSD and Hurd being more
lazy about updating it, and thus it ends up being later than what is
noticed on Linux, and notably later than libxslt.lo which gets compiled
right after it.
It seems to me like a bug in kFreeBSD and Hurd rather than a bug
in the build system: at the very worse, the "modified" timestamp
of libxsltclass.py should not be later than the exit time of the
generator.py script, and even better, at closure time of the
file. Otherwise one can't write makefile rules using timestamps of
generated files.
An odd workaround which triggers the timestamp is e.g. to stat the
generated file, as the attached patch does. It does fix the build both
on hurd-i386 and kfreebsd-amd64, so it really looks like it's the same
issue on both.
Another (less odd) way to fix the issue is to provide the flags again
during doinstall, as the attached patch2 does.
Samuel
--- python/Makefile.am.original 2016-10-27 13:46:43.000000000 +0000
+++ python/Makefile.am 2016-10-27 13:57:03.000000000 +0000
@@ -65,6 +65,7 @@
gen_prog: $(srcdir)/$(GENERATE) $(API_DESC)
SRCDIR=$(srcdir) $(PYTHON) $(srcdir)/$(GENERATE)
+ stat libxsltclass.py
touch gen_prog
$(libxsltmod_la_OBJECTS): $(GENERATED)
--- debian/rules.original 2016-10-27 13:59:37.000000000 +0000
+++ debian/rules 2016-10-27 14:26:36.000000000 +0000
@@ -38,6 +38,8 @@
dobuild-python%: BUILD_DIR=builddir/main/$*
dobuild-python%-dbg: BUILD_FLAGS = PYTHON_INCLUDES=/usr/include/$(*:-dbg=_d) \
LDFLAGS="$(LDFLAGS) -L$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)"
CFLAGS="$(CFLAGS) -Wall -O0"
+doinstall-python%-dbg: BUILD_FLAGS =
PYTHON_INCLUDES=/usr/include/python$(*:-dbg=_d) \
+ LDFLAGS="$(LDFLAGS) -L$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)"
CFLAGS="$(CFLAGS) -Wall -O0"
override_dh_auto_clean:
rm -rf builddir debian/tmp-dbg config.sub config.guess autogen.sh
@@ -67,7 +69,7 @@
sed -i "/dependency_libs/ s/'.*'/''/"
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/*.la
doinstall-python%-dbg:
- $(MAKE) -C builddir/main/python$*-dbg DESTDIR=$(CURDIR)/debian/tmp-dbg
install-pythonLTLIBRARIES
+ $(MAKE) -C builddir/main/python$*-dbg DESTDIR=$(CURDIR)/debian/tmp-dbg
install-pythonLTLIBRARIES $(BUILD_FLAGS)
prename 's/(?<!_d)\.so$$/_d.so/'
debian/tmp-dbg/usr/lib/python$*/*-packages/*.so
doinstall-python%:
