Hello Paul, It seems I'm awake a little longer than you are.
The second paragraph as you see it, belongs to 1) The fourth paragraph as you see it, belongs to 2) The actual command invocations (a Makefile, a make.sh script) can be found in the attachment, as indicated on the first line of the mail. In the attachment there are two directories, one and two, belonging to 1) and 2) respectively. I'm not into Vulcan mindmelds, so I hope everything from the first mail makes sense to you and everyone on this mailing list now. Best regards, Mischa Baars. On Mon, Mar 11, 2024 at 5:01 PM Paul Smith <psm...@gnu.org> wrote: > On Mon, 2024-03-11 at 09:56 +0100, Mischa Baars wrote: > > I've attached the problem. It consists of two parts: > > > > 1) multi-threaded bash script and / or multi-threaded Makefile > > > > Running bash script functions as expected, but executing the same > > line of code with make and / or the command line, does not function. > > Perhaps someone could explain to me why? > > > > 2) passing a string argument from a bash script and / or Makefile to > > the gcc -D option > > > > Running the makefile functions as expected, but I have not been able > > to get similar code to work from a bash script. Can someone please > > explain to me what I'm doing wrong? > > I don't understand the problem. In the third paragraph above you say > the bash script works as expected and the makefile doesn't work, but in > the last paragraph you say that the makefile works as expected but you > can't get it to work in bash. > > Please provide actual command invocations (cut and pasted) showing the > output you received and explaining exactly what is wrong with it. > > But before you do that, be aware that make does NOT invoke /bin/bash as > its shell. It invokes /bin/sh. On some systems /bin/sh is actually an > alias for bash. On other systems it isn't. > > If you want your makefile to always use bash as its shell, you should > add an explicit: > > SHELL := /bin/bash > > to your makefile to force it. Maybe that will solve your problem. If > not we'll need details such as I mention above. >
