Makefile error : target pattern contains no '%'. #747

Potomac · 2021-03-30T19:45:19Z

Bug description:

Can not compile last version of tduck (3.25-2237) when using a rolling release linux distrubition like archlinux,

I got an error during the last step "make install" :
/home/potomac/compilation/tsduck/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-ultima-dbr/objs-utest/utestPESPacketizer.dep:1: *** target pattern contains no '%'. Stop.

full error message :

/home/potomac/compilation/tsduck/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-ultima-dbr/objs-utest/utestPESPacketizer.dep:1: *** target pattern contains no '%'.  Stop.
make[1]: *** [Makefile:47: install-tools] Error 2
make: *** [Makefile:101 : install-tools] Erreur 2
make: *** Attente des tâches non terminées....
  [DEP] utestContinuity.cpp
  [DEP] utestConfig.cpp
  [DEP] utestChannels.cpp
  [DEP] utestByteBlock.cpp
  [DEP] utestBuffer.cpp
  [DEP] utestBoolPredicate.cpp
  [DEP] utestBCD.cpp
  [DEP] utestARIBCharset.cpp
  [DEP] utestArgs.cpp
  [DEP] utestAlgorithm.cpp
  [DEP] tsunit.cpp
  [DEP] dependenciesForStaticLib.cpp
/home/potomac/compilation/tsduck/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-ultima-dbr/objs-utest/utestPESPacketizer.dep:1: *** target pattern contains no '%'.  Stop.
make[1]: *** [Makefile:47: install-devel] Error 2
make: *** [Makefile:101 : install-devel] Erreur 2

How to reproduce:

Use archlinux, try to install tsduck, I use this PKGBUILD :
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=tsduck

Expected behavior:

The compilation should run without errors

Errors and logs:

/home/potomac/compilation/tsduck/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-ultima-dbr/objs-utest/utestPESPacketizer.dep:1: *** target pattern contains no '%'.  Stop.
make[1]: *** [Makefile:47: install-tools] Error 2
make: *** [Makefile:101 : install-tools] Erreur 2
make: *** Attente des tâches non terminées....
  [DEP] utestContinuity.cpp
  [DEP] utestConfig.cpp
  [DEP] utestChannels.cpp
  [DEP] utestByteBlock.cpp
  [DEP] utestBuffer.cpp
  [DEP] utestBoolPredicate.cpp
  [DEP] utestBCD.cpp
  [DEP] utestARIBCharset.cpp
  [DEP] utestArgs.cpp
  [DEP] utestAlgorithm.cpp
  [DEP] tsunit.cpp
  [DEP] dependenciesForStaticLib.cpp
/home/potomac/compilation/tsduck/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-ultima-dbr/objs-utest/utestPESPacketizer.dep:1: *** target pattern contains no '%'.  Stop.
make[1]: *** [Makefile:47: install-devel] Error 2
make: *** [Makefile:101 : install-devel] Erreur 2

Environment:

OS: linux
OS version: archlinux 64 bits
TSDuck full version: 3.25-2237
Installation type:

Additional information:

The text was updated successfully, but these errors were encountered:

piotr-serafin-red · 2021-03-30T21:40:27Z

Hi @Potomac, as I already mentioned in AUR comment (https://aur.archlinux.org/packages/tsduck/#comment-799467) please provide log how you tried to install it? I've just checked two approaches:

Clone https://aur.archlinux.org/tsduck.git and execute makepkg -si
Using AUR helper: yay -S tsduck.

and both are working.

Also @lelegard is not AUR package maintainer which is completely separated from TSDuck project , I am , so I suggest to close this "bug" and continue on AUR.

Best Regards,
Piotr Serafin

lelegard · 2021-03-31T07:14:15Z

Hi,

The .dep are automatically generated by the makefile when obsolete, before compilation. As @piotr-serafin-epam mentioned, it works in all know configurations, especially on Arch where Piotr is the maintainer. I have an Arch VM but I use it when necessary only.

Maybe, your issue could be the result of a scenario like this:

Already have a git repo with an old version.
TSDuck was built and not cleanup.
Pull the latest version, with some structure change in the source directories (it happens)
For some reasons, the existing .dep files create an issue with the modified source files structure.

For any project (non only TSDuck), when getting a weird build issue like this one, the first thing to do should be make distclean and retry the build.

Potomac · 2021-04-06T20:10:24Z

I still have the error "target pattern contains no '%",
it's not a problem related to an old version of a git repo, all the process (makepkg) is done on a clean directory (but not in a chroot environment, I use a /home directory with my normal account),

options used in /etc/makepkg.conf :
MAKEFLAGS="-j4"
BUILDENV=(!distcc color ccache check !sign)

I tried also "git clone https://aur.archlinux.org/tsduck.git" and execute makepkg -si : I get exactly the same error during the "package()" step,

I suspect a problem with package versions (for the dependencies), the PKGBUILD doesn't check the version of dependencies, it checks only if 4 packages are installed : pcsclite, curl, srt and jq, but not their versions.

The archlinux package versions I use :

pcsclite 1.9.1-1
curl 7.76.0-1
srt 1.4.2-1
jq 1.6-4
make 4.3-3
cmake 3.20.0-1
gcc 10.2.0-6

lelegard · 2021-04-07T07:26:18Z

Hi,

Not being an Arch expert, I only have an Arch VM (one of 7 distros VM) to test potential issues with TSDuck. This VM is basic: I installed it once and do the rolling upgrades from time to time. There are the minimum tools and libraries to build TSDuck. I haven't hacked the system tree in any way.

I run this:

git clone https://aur.archlinux.org/tsduck.git
cd tsduck
makepkg -si

And it works. TSDuck 3.25 is built and installed.

I suspect a problem with package versions (for the dependencies), the PKGBUILD doesn't check the version of dependencies, it checks only if 4 packages are installed : pcsclite, curl, srt and jq, but not their versions.

There is zero reason that a dependency version produces an error in the .dep file of a unitary test.

I agree with @piotr-serafin-epam, there is something weird on your system that creates this issue. Noone can troubleshoot it without access to your system. You must provide more details, more logs, more tests.

For a start, I would suggest to do this in an empty directory:

git clone https://github.com/tsduck/tsduck.git
cd tsduck
build/install-prerequisites.sh
make -j10 &>make.log

If you still have the problem, please post the make.log file here.

fraxinas · 2021-04-07T10:07:41Z

I've got the same issues as Potomac trying to build tsdruck-3.25-2237 from AUR using yay.

  [DEP] dependenciesForStaticLib.cpp
/home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest/utestArgs.dep:1: *** target pattern contains no '%'.  Stop.
make[1]: *** [Makefile:47: install-devel] Error 2
/home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest/dependenciesForStaticLib.dep:1: *** target pattern contains no '%'.  Stop.
make[1]: *** [Makefile:47: install-tools] Error 2

it does however build properly when manually cloning the repo and making, like lelegard suggested.

lelegard · 2021-04-07T12:02:19Z

What is the content of the .dep file with error? Could you post it here?

For instance, my utestArgs.dep contains:

/home/thierry/tsduck/bin/release-x86_64-vmarch/objs-utest/utestArgs.o /home/thierry/tsduck/bin/release-x86_64-vmarch/objs-utest/utestArgs.dep : utestArgs.cpp \
 /home/thierry/tsduck/src/libtsduck/base/tsArgs.h \
 /home/thierry/tsduck/src/libtsduck/base/tsReport.h \
 /home/thierry/tsduck/src/libtsduck/base/tsUString.h \
 /home/thierry/tsduck/src/libtsduck/base/tsUChar.h \
 /home/thierry/tsduck/src/libtsduck/base/tsPlatform.h \
.....

fraxinas · 2021-04-07T12:11:10Z

absolutely!

$ more /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest/utestArgs.dep
/home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest//home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest/
utestArgs.o /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest/utestArgs.dep : /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/releas
e-x86_64-afrdell/objs-utest/utestArgs.dep : utestArgs.cpp \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsArgs.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsReport.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsUString.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsUChar.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsPlatform.h \
 /usr/include/PCSC/winscard.h /usr/include/PCSC/pcsclite.h \
 /usr/include/PCSC/wintypes.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsVersionString.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/tsVersion.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsArgMix.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsEnumUtils.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsStringifyInterface.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsArgMixTemplate.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsUStringTemplate.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsEnumeration.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsException.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsVariable.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsVariableTemplate.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsArgsTemplate.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsReportBuffer.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsNullMutex.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsMutexInterface.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsReportBufferTemplate.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsGuard.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsSysUtils.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsTime.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsCerrReport.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsSingletonManager.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsMutex.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsSysUtilsTemplate.h \
 tsunit.h

$ more /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest/dependenciesForStaticLib.dep
/home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest//home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest/
dependenciesForStaticLib.o /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest/dependenciesForStaticLib.dep : /home/fraxinas/.cache/yay/tsduck/s
rc/tsduck-3.25-2237/bin/release-x86_64-afrdell/objs-utest/dependenciesForStaticLib.dep : dependenciesForStaticLib.cpp \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/dtv/static/tsStaticReferencesDVB.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsPlatform.h \
 /usr/include/PCSC/winscard.h /usr/include/PCSC/pcsclite.h \
 /usr/include/PCSC/wintypes.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/base/tsVersionString.h \
 /home/fraxinas/.cache/yay/tsduck/src/tsduck-3.25-2237/src/libtsduck/tsVersion.h

lelegard · 2021-04-07T13:16:43Z

Thanks for your .dep file. The make message is misleading and occurs in many different kinds of dependency errors (as seen using Google). The actual error is that the full directory path of the object file in the dependency line is duplicated.

I think I understand the error but not the root cause. Maybe you could analyze it on your system. First, we need to explain how the .dep files are created.

A .dep file is created in two commands using this rule from Makefile.common:

$(OBJDIR)/%.dep: %.cpp
	@echo '  [DEP] $<'; \
	mkdir -p $(OBJDIR); \
	$(CC) -MM $(CPPFLAGS) $(CXXFLAGS_INCLUDES) $(CXXFLAGS_STANDARD) $(CXXFLAGS_NO_WARNINGS) $< >$@ && \
	$(SED) -i 's,\($*\)\.o *: *,$(OBJDIR)/\1.o $@ : ,g' $@ || \
	rm -f $@

The first command gcc -MM generates a dependency file like this:

utestArgs.o: utestArgs.cpp \
 /home/thierry/tsduck/src/libtsduck/base/tsArgs.h \
 ...

We need to fix two things here with the second sed command:

The object file shall have a full path so that make can handle the dependency correctly.
We also add the .dep file as target for these dependencies so that the .dep is also regenerated when the dependencies are updated.

After the sed command, the .dep file becomes:

/home/thierry/tsduck/bin/release-x86_64-vmarch/objs-utest/utestArgs.o /home/thierry/tsduck/bin/release-x86_64-vmarch/objs-utest/utestArgs.dep : utestArgs.cpp \
 /home/thierry/tsduck/src/libtsduck/base/tsArgs.h \
 ...

In your case, if the directory path of the object file is duplicated, it may be because the original .dep file, after the gcc -MM command, already had a full directory path, instead of the base name as seen in all other cases. I do not know why.

It never happen to me, on many flavors of Linux and macOS. Furthermore, it does not happen to you outside the AUR package installation. Since it does not happen to me or @piotr-serafin-epam within the AUR package installation either, it is difficult to understand why it happens on some systems only and in the context of the package installation only.

heftig · 2021-04-07T15:11:18Z

I can also reproduce this. Why not use the -MT argument to specify the dep rule targets? This fixes the problem for me, and also avoids the sed hackery.

$(CC) -MM -MT $(OBJDIR)/$*.o -MT $@ …

heftig · 2021-04-07T15:23:34Z

I think the root cause is that make install with parallelism (e.g. MAKEFLAGS=-j8) will then launch make -C src install-tools and make -C src install-devel in parallel.

Both sub-makes then process the dep rules and race with each other. It can then happen that a dep file is written by cc, overwritten by another cc, then modified by sed and again modified by another sed, leading to a broken file.

lelegard · 2021-04-07T16:50:24Z

I think the root cause is that make install with parallelism (e.g. MAKEFLAGS=-j8)

Yes, this is known. This is why it is recommended to build with parallelism and make install afterwards, without parallelism. But if I correctly read the PKGBUILD file from AUR, the make install has no parallelism. So, this cannot be the root cause of this specific issue (unless the makepkg system automatically add -j options to make).

The only advice I could make is to build and install with the same options, specifically NOTEST=true. It is a good idea to build with that option since the unitary tests are quite long to build. The install phase does not need anything from the unitary tests and won't build anything but, without NOTEST=true, it will still recurse into the test directories and realize that there is nothing to build. But the simple action of recursing into a source directory forces the regeneration of outdated .dep files since they are included in makefiles. This is what is done in the Homebrew formula for macOS, a system which is similar to AUR in principle.

lelegard · 2021-04-07T17:12:50Z

Why not use the -MT argument to specify the dep rule targets? This fixes the problem for me, and also avoids the sed hackery.

@heftig, good idea, thank you. Done. I do not know why I didn't see that before. The .dep generation dates back from V1 in 2005. Maybe that option was not available at that time (I don't find anything more clever for my defense 😄 ). We will see if anyone complains with old gcc compilers (TSDuck can be compiled back to gcc 4.8 I think).

Potomac · 2021-04-07T18:42:07Z

I think the root cause is that make install with parallelism (e.g. MAKEFLAGS=-j8)

Yes, this is known. This is why it is recommended to build with parallelism and make install afterwards, without parallelism. But if I correctly read the PKGBUILD file from AUR, the make install has no parallelism. So, this cannot be the root cause of this specific issue (unless the makepkg system automatically add -j options to make).

makepkg will read the configuration in /etc/makepkg.conf, the "-jX" option will be automatically added by makepkg if the option exists in /etc/makepkg.conf (MAKEFLAGS variable)

piotr-serafin-red · 2021-04-07T20:31:31Z

I think the root cause is that make install with parallelism (e.g. MAKEFLAGS=-j8)

Yes, this is known. This is why it is recommended to build with parallelism and make install afterwards, without parallelism. But if I correctly read the PKGBUILD file from AUR, the make install has no parallelism. So, this cannot be the root cause of this specific issue (unless the makepkg system automatically add -j options to make).

makepkg will read the configuration in /etc/makepkg.conf, the "-jX" option will be automatically added by makepkg if the option exists in /etc/makepkg.conf (MAKEFLAGS variable)

Please try to add manually -j1 in PKGBUILD if it will work for you I will update PKGBUILD to avoid this race condition, this is also mentioned in archwiki:

Improving compile times
Parallel compilation
The make build system uses the MAKEFLAGS environment variable to specify additional options for make. The variable can > also be set in the makepkg.conf file.

Users with multi-core/multi-processor systems can specify the number of jobs to run simultaneously. This can be accomplished with the use of nproc to determine the number of available processors, e.g. MAKEFLAGS="-j$(nproc)". Some PKGBUILDs specifically override this with -j1, because of race conditions in certain versions or simply because it is not supported in the first place. Packages that fail to build because of this should be reported on the bug tracker (or in the case of AUR packages, to the package maintainer) after making sure that the error is indeed being caused by your MAKEFLAGS.

lelegard · 2021-04-08T07:00:16Z

The parallel installation is not a problem, it works well since both parts (tools & devel) work on distinct sets of files.

The problem can be (still not fully convinced that this is the root cause) the parallel automatic regeneration of make include files (.dep). To avoid that, make sure that make and make install work in the same environment so that all .dep files are generated in the build phase and no additional .dep is necessary in the install phase. In short, also use NOTEST=true in the install phase also rather than forcing -j1.

This shoud be fine on AUR for version 3.25.

For next version 3.26, I have applied the following modifications:

Force NOTEST=true with all installation targets (nothing is "installed" from the test area). This will avoid recursion in the utest directory in the installation phase, regardless of the way the build phase was performed.
Use -MT in the generation of .dep files as suggested by @heftig.

piotr-serafin-red · 2021-04-08T07:54:37Z

@lelegard @heftig @Potomac @fraxinas ,

I have updated PKGBUILD according to your suggestions, please check if it is working for you. Works on my env 😅

fraxinas · 2021-04-08T08:43:54Z

@piotr-serafin-epam i can acknowledge that it works with the latest update to the PKGBUILD file

piotr-serafin-red · 2021-04-08T08:55:15Z

@piotr-serafin-epam i can acknowledge that it works with the latest update to the PKGBUILD file

Great, please upvote the package in AUR if possible to gain more attention:)

piotr-serafin-red · 2021-04-08T08:55:41Z

@lelegard we can close this ticket.

Potomac added the bug label Mar 30, 2021

lelegard removed the bug label Mar 31, 2021

lelegard changed the title ~~[BUG] Makefile error : target pattern contains no '%'.~~ Makefile error : target pattern contains no '%'. Mar 31, 2021

lelegard closed this as completed Apr 8, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Makefile error : target pattern contains no '%'. #747

Makefile error : target pattern contains no '%'. #747

Potomac commented Mar 30, 2021

piotr-serafin-red commented Mar 30, 2021 •

edited

lelegard commented Mar 31, 2021

Potomac commented Apr 6, 2021 •

edited

lelegard commented Apr 7, 2021

fraxinas commented Apr 7, 2021

lelegard commented Apr 7, 2021

fraxinas commented Apr 7, 2021

lelegard commented Apr 7, 2021

heftig commented Apr 7, 2021

heftig commented Apr 7, 2021 •

edited

lelegard commented Apr 7, 2021

lelegard commented Apr 7, 2021

Potomac commented Apr 7, 2021

piotr-serafin-red commented Apr 7, 2021

lelegard commented Apr 8, 2021

piotr-serafin-red commented Apr 8, 2021 •

edited

fraxinas commented Apr 8, 2021

piotr-serafin-red commented Apr 8, 2021

piotr-serafin-red commented Apr 8, 2021

Makefile error : target pattern contains no '%'. #747

Makefile error : target pattern contains no '%'. #747

Comments

Potomac commented Mar 30, 2021

Bug description:

How to reproduce:

Expected behavior:

Errors and logs:

Environment:

Additional information:

piotr-serafin-red commented Mar 30, 2021 • edited

lelegard commented Mar 31, 2021

Potomac commented Apr 6, 2021 • edited

lelegard commented Apr 7, 2021

fraxinas commented Apr 7, 2021

lelegard commented Apr 7, 2021

fraxinas commented Apr 7, 2021

lelegard commented Apr 7, 2021

heftig commented Apr 7, 2021

heftig commented Apr 7, 2021 • edited

lelegard commented Apr 7, 2021

lelegard commented Apr 7, 2021

Potomac commented Apr 7, 2021

piotr-serafin-red commented Apr 7, 2021

lelegard commented Apr 8, 2021

piotr-serafin-red commented Apr 8, 2021 • edited

fraxinas commented Apr 8, 2021

piotr-serafin-red commented Apr 8, 2021

piotr-serafin-red commented Apr 8, 2021

piotr-serafin-red commented Mar 30, 2021 •

edited

Potomac commented Apr 6, 2021 •

edited

heftig commented Apr 7, 2021 •

edited

piotr-serafin-red commented Apr 8, 2021 •

edited