Error trying to compile C file: mkfifo: cannot create fifo 'stderr': Operation not supported - c

We are trying to compile this by following instructions in the readme. I must say that we are not specialists with C at all, we are students of a web development bootcamp and trying to do our last project.
It's a command line tool to calculate ephemerides of multiple celestial bodies, and as you can read in the setup in the readme file, it need to download certain data from the internet, and then compile.
All is done through the setup.sh script.
So, we have tried:
In Windows 10 ubuntu WSL terminal
If we type $./setup or $./prettymake, after download the data, gives the error:
$mkfifo: cannot create fifo 'stderr': Operation not supported
$mkdir -p obj obj/argparse obj/coreUtils obj/ephemCalc obj/listTools obj/mathsTools obj/settings
cc -Wall -Wno-format-truncation -Wno-unknown-pragmas -g -c -I /mnt/d/reboot/ephemeris-compute-de430/src -O3 -D DEBUG=0 -D MEMDEBUG1=0 -D MEMDEBUG2=0 -fopenmp -D DCFVERSION=\"2.0\" -D DATE=\"09/06/2019\" -D PATHLINK=\"/\" -D SRCDIR=\"/mnt/d/reboot/ephemeris-compute-de430/src/\" src/ephemCalc/constellations.c -o obj/ephemCalc/constellations.o
If we do it with $sudo ./setup, the error printed is:
$mkfifo: cannot create fifo 'stderr': Operation not supported
$cat: stderr: No such file or directory
$mkdir -p obj obj/argparse obj/coreUtils obj/ephemCalc obj/listTools obj/mathsTools obj/settings
cc -Wall -Wno-format-truncation -Wno-unknown-pragmas -g -c -I /mnt/d/reboot/ephemeris-compute-de430/src -O3 -D DEBUG=0 -D MEMDEBUG1=0 -D MEMDEBUG2=0 -fopenmp -D DCFVERSION=\"2.0\" -D DATE=\"09/06/2019\" -D PATHLINK=\"/\" -D SRCDIR=\"/mnt/d/reboot/ephemeris-compute-de430/src/\" src/ephemCalc/constellations.c -o obj/ephemCalc/constellations.o
In macOS terminal
If we type $./prettymake, gives the error:
$mkdir -p obj obj/argparse obj/coreUtils obj/ephemCalc obj/listTools obj/mathsTools obj/settings
cc -Wall -Wno-format-truncation -Wno-unknown-pragmas -g -c -I /Users/rominaelorrietalopez/Documents/Descargas2/ephemeris-compute-de430-master/src -O3 -D DEBUG=0 -D MEMDEBUG1=0 -D MEMDEBUG2=0 -fopenmp -D DCFVERSION=\"2.0\" -D DATE=\"09/06/2019\" -D PATHLINK=\"/\" -D SRCDIR=\"/Users/rominaelorrietalopez/Documents/Descargas2/ephemeris-compute-de430-master/src/\" src/argparse/argparse.c -o obj/argparse/argparse.o
$clang: error: unsupported option '-fopenmp'
$make: *** [obj/argparse/argparse.o] Error 1
We have tried certain things to no avail, like granting permissions and what not, but have no idea what to do next.
It seems that it have something to do with the prettymake file:
mkfifo stderr
cat stderr | sed 's/\(.*\)/\1/' &
make $# 2>stderr | sed 's/\(.*\)/\1/'
rm stderr
It's like its trying to create a pipe to save the errors of the compilation but somehow it fails.
Also possibly worth of mention, it have a Makefile associated.
Since the github project does not have Issues, we've contacted the creator via email, but well, we thought maybe someone could help us here too.
Any kind of help would be honestly appreciated, thanks.

A comment from the OP invites me to answer; here it is.
The prettymake script creates a named fifo in order to receive the messages produced by make on its standard error.
A background process (cat) consumes the data from this fifo and sends them to a sed command (see right after) in order to transform these data before writing to standard output.
(note that cat is useless here since sed could have directly read from the named fifo thanks to <)
However, the two sed commands as shown in the question don't do anything since they just capture each line of text (\(.*\)) and repeat them unchanged (\1), thus they could have been omitted.
In this case, the script could just contain make $# 2>&1, it would have produced the same effect.
On a system where creating the named fifo is problematic (old version of WSL apparently), this change in the script should produce the same effect as expected.
Looking at the link provided in the question, we can see that the original prettymake script actually contains transformations in the sed commands in order to display standard output and standard error of the make command with different colours.

Related

Using rm -i !(*.c|Makefile) in Makefile?

I have a directory where I have some C program files and a Makefile with executables of those C files. I can simply run this to remove all the executable at once in rm !(*.c|Makefile).
But when i am adding this to my makefile
CFLAGS= -Wall -g -lm
SHELL=/bin/bash
careful:
echo "nothing"
clean:
rm -i !(*.c|Makefile)
I am getting this error while executing the command
/bin/bash: -c: line 1: syntax error near unexpected token `('
/bin/bash: -c: line 1: `rm -i !(*.c|Makefile)'
make: *** [Makefile:8: clean] Error 2
I am not too knowledgeable about Bash syntax but I know that () is treated as a subshell, I think that's why I can't run rm (*.c) directly in the terminal because *.c is not a command (or any valid syntax). But running rm -i !(*.c) works in the terminal. So I guess !() is treated differently in Bash.
My assumption on all this: in Makefile when I am running make clean it is treating !(*.c|Makefile), differently than in normal terminal, or somehow it is disregarding ! in !(*.c|Makefile)
So my questions are:
Are !() and () treated differently in Bash?
Why does !(wildcard) work in the terminal but not in my Makefile
How can I make it work in the Makefile?
The Bash-specific extended globbing patterns are not enabled out of the box for noninteractive shells.
!(...) is purely part of this wildcard syntax, and has nothing with subshells to do.
Probably a better solution anyway is to refactor this so you don't depend on Bash.
.PHONY: clean
clean:
rm -i $(filter-out $(wildcard *.c) Makefile,$(wildcard *))
The Bash Reference Manual doesn't have a good anchor to link to, but the extended globbing syntax available with extglob is described in the section on Pattern Matching
If you really wanted to, you could shopt -s extglob in your Makefile, too, but this gets rather complicated as you will have to hide the statement from the parser until the shell is configured to understand this syntax. For example,
.PHONY: clean
clean:
shopt -s extglob; \
eval 'rm -i !(*.c|Makefile)'
Notice also how shopt and eval need to be on the same logical line, as make out of the box executes each recipe line in a separate new shell instance (though you can change that with .ONESHELL)

clang-tidy reporting many error: unknown argument

I am running an embedded C project based on a tricore-gcc compiler.
I made a compile_commands.json file that works well.
However, there are some arguments that clang-tidy cannot recognize.
For example I get the following
error: unknown argument: '-fstrict-volatile-bitfields' [clang-diagnostic-error]
when I run clang-tidy.
This is not a surprise of course, since -fstrict-volatile-bitfields is an option for gcc but not for clang-tidy.
However, I would like to suppress output messages due to unknown compiler options.
I tried to append --extra-arg=-Wno-unknown-warning-option as suggested here but the problem persists.
I had the same problem when using clang-tidy for a project compiled with GCC. The two compilers have different set of recognized flags. My compile_commands.json, which was generated by intercept-build, contained a number of options used by GCC that clang-tidy did not understand.
I solved this by a somewhat hackish solution of redacting the compile database before initiating the static analysis pass.
My script contains a number of Sed lines similar to this:
sed -i -E 's#-fconserve-stack##g' compile_commands.json
sed -i -E 's#-maccumulate-outgoing-args##g' compile_commands.json
sed -i -E 's#-mindirect-branch-register##g' compile_commands.json
sed -i -E 's#-mindirect-branch=thunk-extern##g' compile_commands.json
sed -i -E 's#-mpreferred-stack-boundary=3##g' compile_commands.json
sed -i -E 's#-mfunction-return=thunk-extern##g' compile_commands.json
This way, the unsupported flags are made invisible to clang-tidy, which allows to work without errors.

I'd like to create a batch file with certain rules

Hi I would like to create a bat file that executes the following commands:
avr-gcc -Os -DF_CPU=16000000UL -mmcu=atmega328p -c -o battery.o battery.c
avr-gcc -mmcu=atmega328p battery.o -o battery
avr-objcopy -O ihex -R .eeprom battery battery.hex
avrdude -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -v -p ATMEGA328P -c arduino -P COM4 -b 57600 -U flash:w:battery.hex:i
I've ran this as a bat but the commands aren't recognized. Should I move to the directories that has the executables first?
The second command always throw an error in a msgbox that doesn't really matter, can it 'ok' the msgbox by itself and carry on to the next command?
Thank you very much.
Why would you expect that to work. It will work if the batch file is in same directory as the files.
ALWAYS SPECIFY FULL PATHS
%windir%\system32\setx
is one way to do it, above is same as
C:\Windows\system32\setx

cscope: -c or -T mismatch between command line and old symbol database

I'm trying to create tags for *.c, *.x and *.h files.
These are the following commands which I executed.
find <absolute_path_of_code> -name *.c -o -name *.x -o -name *.h > cscope.files
cscope -bkqc cscope.files
Till here everything is ok.
But after this when I execute the command,
cscope -Rb
I get the following message at console.
cscope: -c or -T option mismatch between command line and old symbol database
How do I resolve this?
If you generate a database using the -c or -T options (you use -c in your original command) you are required to pass those options to every subsequent invocation of cscope. Just add -c to your second command (making it cscope -Rbc) and it should work.
cscope -Rb generates only cscope.out file but cscope -bkqc -I cscope.files generates cscope.in.out, cscope.po.out and cscope.out. So there is no need to execute cscope -Rb.

Cross compiling OpenSSL - openssl binary cannot be executed

I'm trying to cross compile OpenSSL for PowerPC with the FIPS module. My build host's architecture is not PowerPC. I was able to cross compile the FIPS module just fine. However, when I run make on openssl, during the linking phase, it tries to execute certain binaries to run tests. The issue is that those binaries are produced for the target architecture and, as a result, I get the error "cannot execute binary file". Is there a way to produce executables of these tests on the host architecture rather than the target architecture? Should I be handling this process differently? Here are the following commands I used to build openssl. I replaced certain directories with DIR_HIDDEN.
export FIPS_DIRECTORY="$PWD/../../openssl-fips/tgt/linux-ppc603e/"
export cross="DIR_HIDDEN/powerpc-linux-gnu-"
make clean || exit 1
make dclean || exit 1
./Configure --prefix=$PWD/../tgt/linux-ppc603e linux-ppc fips --with-fipsdir=${FIPS_DIRECTORY}
make depend || exit 1
make CC="$FIPS_DIRECTORY/bin/fipsld" RANLIB="${cross}ranlib" AR="${cross}ar r" LD="$FIPS_DIRECTORY/bin/fipsld" FIPSLD_CC="${cross}gcc" HOSTCC="/usr/bin/gcc" || exit 1
make install || exit 1
I get the following error during the make command:
shlib_target=; if [ -n "" ]; then \
shlib_target="linux-shared"; \
elif [ -n "libcrypto" ]; then \
FIPSLD_CC="/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld"; CC=/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld; export CC FIPSLD_CC; \
fi; \
LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o" \
LIBDEPS=" $LIBRARIES -ldl" \
link_app.${shlib_target}
make[2]: Entering directory `/DIR_HIDDEN/openssl/openssl-1.0.1i/apps'
( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto -ldl}"; LDCMD="${LDCMD:-/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT -I/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//include -DSHA1_ASM -DSHA256_ASM -DAES_ASM}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld: line 185: ./openssl: cannot execute binary file
make[2]: *** [link_app.] Error 126
When invoking the make command again and again, I get the same error but for all the applications located in the /test directory of the openssl tarball. Examples include bntest, ectest, and ecdhtest.
I received a similar error when I was cross compiling the FIPS module, but I was able to resolve that by including the host compiler in the HOSTCC variable. A similar trick did not work for the openssl compilation.
Any guidance would be appreciated. Thanks!
I was able to modify the make command to get the process to complete. I was missing the FIPS_SIG environment variable, which points to the incore script. The make command is now:
make FIPS_SIG=$PWD/`find ../../openssl-fips/ -iname incore` CC="$FIPS_DIRECTORY/bin/fipsld" RANLIB="${cross}ranlib" AR="${cross}ar r" LD="$FIPS_DIRECTORY/bin/fipsld" FIPSLD_CC="${cross}gcc"
I still see prints to console that indicate that openssl cannot be executed, but these are warnings and don't halt the makefile. Not really sure why or how this fixed the problem, but I'll take it.

Resources