Clearly there's similarities in the underlying operating system when it comes to Unix and Linux.

Is there a reason why compiling a Makefile won't compile on a Linux OS versus on a FreeBSD or OSX OS won't compile?

For instance, installing the following application compiles successfully on a FreeBSD OS but won't compile on CentOS or Ubuntu.


Are there libraries or kernel headers that are missing within the Linux OS that require to build this specific Makefile?

Here's the Makefile for reference: https://github.com/SuperScript/trigger/blob/master/src/Makefile

Here's what I get when trying to run package\compile on Linux machine.

# package/compile
sh makefile.build default.build load load
makefile.build: line 30: .: default.build: file not found
sh makefile.build default.build systype systype
makefile.build: line 30: .: default.build: file not found
sh makefile.build default.build compile compile
makefile.build: line 30: .: default.build: file not found
sh makefile.build default.o.build trigger-pull.o trigger-pull
makefile.build: line 30: .: default.o.build: file not found

Having looked at the various and peculiar build scripts that this software package is using, it appears as if it's written for a /bin/sh shell that by default allows the . command (source in the bash shell) to read and run dot-scripts from the current directory even when the script's path is not explicitly given and the current directory is not in $PATH (or the developers assume that you have . in $PATH, which you generally don't have and shouldn't have).

The solution to this is to patch the src/makefile.build script so that the build_do shell function on line 29 reads

build_do() {
  ( . ./"$build_it_cmds" "$1" "$2" "$3" > "$3" )

Note the added ./.

You should probably then also submit a bug report about this to the project. This is fortunately extremely easy to do with GitHub, although I see that no development has been happening on this project since 2012 so I don't know whether it's dead or not.

  • Thank you, @Kusalananda. I'll do some testing and I'll submit a bug report. – hfranco Apr 2 at 20:33
  • 1
    Or you could look at the issues list and see that this is issue #1. (-: – JdeBP Apr 2 at 22:11
  • @JdeBP Issue #2 is the same but with a pull request attached. That software is probably abandoned. – Kusalananda Apr 2 at 22:13
  • If M. Baxter had abandoned it, it would not be on GitHub in the first place, given when xe first published some of this stuff. It is more likely that GitHub "issues" aren't the way to communicate with the author. – JdeBP Apr 3 at 7:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.