Bug#905472: libtextwrap FTBFS: cannot find -ltextwrap
On Sun, Aug 05, 2018 at 09:11:14AM +0200, Helmut Grohne wrote: > Control: tags -1 + patch > > On Sun, Aug 05, 2018 at 08:55:32AM +0200, Helmut Grohne wrote: > > Scanning the recent upload history, automake-1.16 looks suspicious now. > > Yes, it looks like a missing Makefile.am dependency. The attached patch > makes it build. > > Helmut > --- libtextwrap-0.1.orig/Makefile.am > +++ libtextwrap-0.1/Makefile.am > @@ -9,3 +9,4 @@ > bin_PROGRAMS = dotextwrap > dotextwrap_SOURCES = dotextwrap.c > dotextwrap_LDADD = -ltextwrap > +EXTRA_dotextwrap_DEPENDENCIES = libtextwrap.la That's then a race condition that also exists with older automake, and the new automake just reshuffled the build order. The correct fix is to fix the bug one line earlier with s/-ltextwrap/libtextwrap.la/ cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#905472: libtextwrap FTBFS: cannot find -ltextwrap
Control: tags -1 + patch On Sun, Aug 05, 2018 at 08:55:32AM +0200, Helmut Grohne wrote: > Scanning the recent upload history, automake-1.16 looks suspicious now. Yes, it looks like a missing Makefile.am dependency. The attached patch makes it build. Helmut --- libtextwrap-0.1.orig/Makefile.am +++ libtextwrap-0.1/Makefile.am @@ -9,3 +9,4 @@ bin_PROGRAMS = dotextwrap dotextwrap_SOURCES = dotextwrap.c dotextwrap_LDADD = -ltextwrap +EXTRA_dotextwrap_DEPENDENCIES = libtextwrap.la
Bug#905472: libtextwrap FTBFS: cannot find -ltextwrap
On Sun, Aug 05, 2018 at 07:31:55AM +0200, Helmut Grohne wrote: > libtextwrap fails to build from source on amd64 in unstable. A build log > ends with: > > | touch configure-stamp > | dh_testdir > | /usr/bin/make > | make[1]: Entering directory '/<>' > | /usr/bin/make all-am > | make[2]: Entering directory '/<>' > | gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -MT dotextwrap.o -MD -MP -MF .deps/dotextwrap.Tpo -c > -o dotextwrap.o dotextwrap.c > | mv -f .deps/dotextwrap.Tpo .deps/dotextwrap.Po > | /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -Wl,-z,relro -o dotextwrap dotextwrap.o -ltextwrap > | libtool: link: gcc -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro -o > dotextwrap dotextwrap.o -ltextwrap > | /usr/bin/ld: cannot find -ltextwrap > | collect2: error: ld returned 1 exit status > | make[2]: *** [Makefile:515: dotextwrap] Error 1 > | make[2]: Leaving directory '/<>' > | make[1]: *** [Makefile:373: all] Error 2 > | make[1]: Leaving directory '/<>' > | make: *** [debian/rules:56: build-stamp] Error 2 > | dpkg-buildpackage: error: debian/rules build subprocess returned exit > status 2 > > This looks very strange and more of a breakage of makefile dependencies. > It didn't even try building -ltextwrap and links it already. The issue > is reproducible without parallelism. I haven't seen it until "recently" > though since meson and then pcre3 have fucked up bootstrap qa lately, > "recently" means like two weeks here though reproducible builds didn't > encounter the issue (yet?). The make-dfsg upload looks a bit suspicious, > so I'm Ccing Ben here. make seems to be a wrong guess here. After downgrading make, it fails the same way. Sorry, Ben, for the noise. Also thank you for having taken care of it. Scanning the recent upload history, automake-1.16 looks suspicious now. I also rescheduled libtextwrap on reproducible.d.n and it fails there as well. Another data point for a fairly recent regression. Helmut
Bug#905472: libtextwrap FTBFS: cannot find -ltextwrap
Source: libtextwrap Version: 0.1-14.1 Severity: serious Tags: ftbfs User: helm...@debian.org Usertags: rebootstrap libtextwrap fails to build from source on amd64 in unstable. A build log ends with: | touch configure-stamp | dh_testdir | /usr/bin/make | make[1]: Entering directory '/<>' | /usr/bin/make all-am | make[2]: Entering directory '/<>' | gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -MT dotextwrap.o -MD -MP -MF .deps/dotextwrap.Tpo -c -o dotextwrap.o dotextwrap.c | mv -f .deps/dotextwrap.Tpo .deps/dotextwrap.Po | /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -o dotextwrap dotextwrap.o -ltextwrap | libtool: link: gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro -o dotextwrap dotextwrap.o -ltextwrap | /usr/bin/ld: cannot find -ltextwrap | collect2: error: ld returned 1 exit status | make[2]: *** [Makefile:515: dotextwrap] Error 1 | make[2]: Leaving directory '/<>' | make[1]: *** [Makefile:373: all] Error 2 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:56: build-stamp] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 This looks very strange and more of a breakage of makefile dependencies. It didn't even try building -ltextwrap and links it already. The issue is reproducible without parallelism. I haven't seen it until "recently" though since meson and then pcre3 have fucked up bootstrap qa lately, "recently" means like two weeks here though reproducible builds didn't encounter the issue (yet?). The make-dfsg upload looks a bit suspicious, so I'm Ccing Ben here. I hope that someone can make sense of this, or at least reproduce it. Helmut
