I have quit checking the actual file descriptor because perror gives a more information when it fails.
This could be a problem: perror() prints the associated error string with the current errno, but a successful library call does not reset errno to zero. If you're going to rely on perror(), and by extension errno, you need to make sure you set errrno to zero before any library call that might set errno. Otherwise, you could be getting invalid error information. Every library function I can think of will return a value that will indicate that it failed (e.g. -1 for open(), or NULL for fopen(), etc). You really should be testing the return value for failure before checking perror()
When a system call fails, it usually returns -1 and sets the variable
errno to a value describing what went wrong. (These values can be
found in <errno.h>.) Many library functions do likewise. The
function perror() serves to translate this error code into human-
readable form. Note that errno is undefined after a successful
system call or library function call: this call may well change this
variable, even though it succeeds, for example because it internally
used some other library function that failed. Thus, if a failing
call is not immediately followed by a call to perror(), the value of
errno should be saved.
And I am not the only one using perror wrong. Take this gem
I have commented out here just to show the original code.
This "example" shows why some coders do not check the call result.
I have moved the code to run on RPi ARM and have NO ISSUES!
I shall go ahead and finish my experiment passing data using bluetooth on SAME hardware,
Perhaps when I get it fully working it will be easier to find why it fails on X86.
Thanks four your help.
I do what I can but I haven`t found exactly what I was looking for, though that`s only because I wasn`t looking for the right thing maybe. I know there is tons of material out there but I don`t trust them unless I`m specifically pointed to a resource by someone.
Richard thanks for your useful feedback.
Today I tried to run a python script but it needed python 3.7. I did not have that in the Msys32 setup I was using. After some searching I tried to put the Msys32 configuration up to date but it completely failed and became totally inoperable. It was not even possible to start the Mingw32 shell in it any more.
I Also had an Msys64 setup available and tried to update that one and it worked perfectly. I installed python 22.214.171.124 and was able to run the python script from within the updated Mingw64 shell. The Msys64 setup also contains a Mingw32 shell which runs equally well.
So far so good but now I have a completely different problem: whenever I try to run the make command for my project ( either manually in the Mingw32 or Mingw64 shell or from Visual studio code ) I get a really odd error message:
mkdir -p build/./main/
The syntax of the command is incorrect.
make: *** [build/./main/hello_world_main.c.o] Error 1
It is the mkdir -p build/./main/ which appears to be the culprit but strangely enough that used to work perfectly and when I type the exact same command from within either the Mingw32 or Mingw64 shell it executes perfectly without the slightest trace of an error message.
For completeness I have included the Makefile content below but this has really thrown a spanner in the works. Does anyone have an idea as to what may be the cause of this?
Just took a look and it seems that the commands make will process are at or near the top of the file, and then the rules that make used follow e.g.
$ make -p hello > make.out 2>&1
$ head -20 make.out
cc hello.c -o hello
# GNU Make 4.2.1
# Built for arm-unknown-linux-gnueabihf
# Copyright (C) 1988-2016 Free Software Foundation, Inc.
# License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
# This is free software: you are free to change and redistribute it.
# There is NO WARRANTY, to the extent permitted by law.
# Make data base, printed on Tue Feb 4 12:02:00 2020
<D = $(patsubst %/,%,$(dir $<))
?F = $(notdir $?)
.SHELLFLAGS := -c
XDG_SESSION_CLASS = user
Trying to figure out the rules that make used to generate the commands can sometimes be challenging, though.