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.
It is one of the results I got for this google search: temporary batch file created by make does not work msys2
The reason for that search is that Richard suggested there is an option to ensure that make's output becomes a lot more verbose. The option is -d and it produces a lot more output if you use it.
In that output I noticed that make created a temporary batch file and tried to execute it but failed.
The content of that batch file was this: mkdir -p build/./main/, exactly the error that a standard make call produced.
So: apparently make could not execute the batch files it creates itself so I googled so as to know why and found the result mentioned above.
It suggested I was using the wrong version of make to try and build my application and as it turns out that was exactly what was wrong.
The make I was using was the one that was installed with the toolchain and when you type make -v it reports:
GNU Make 3.82
Built for i686-pc-mingw32
I then used pacman -S make to install the proper make version and that one reports this:
GNU Make 4.3
Built for x86_64-pc-msys
End result: when you run things in the latest mingw64 or mingw32 shell it requires the newer make version built for msys instead of the earlier version which did work in the older version of mingw32 shell. When I use the later version of make Built for x86_64-pc-msys it works like a charm again.
What is does is build an example application ( simply "hello world" ) on the windows machine, transfer it to the raspberry PI and run/debug it using a GDB server on the Pi and a GDB client from Vscode on the windows machine.
Now I would like to try and expand that a bit to develop a GUI based application in the same way.
I have done some checking and I think that using the GTK-2.0 library is probably the way to go. On the PI I have installed that library successfully but now I would like to transfer it to the appropriate location in the msys32 directory where the cross compilation tools are located as well. The problem is that it is not entirely clear to me where all the header and library files are located on the PI. Running pkg-config --cflags --libs gtk+-2.0 does tell me what I should add as extra includes when I run the gcc build tool on the PI but it is not clear how and where I could copy the required header and library files so that the cross compilation tool on the windows machine could find them.
Any suggestions/ideas would be very much appreciated.
Edit: added "directory' to indicate that the mentioned msys32 is a directory.
Thanks. I have recently done an application like that: a VB.NET application developed/built on a Windows 10 machine and then executed on the Raspberry PI using mono. It worked well but I am now investigating if there is a more native way to do it.
I have found some interesting info in a document called "An introduction to C&GUI programming" by Simon Long, one of the engineers who works for the Raspberry PI Foundation.
Unfortunately everything in it is built on the Raspberry PI itself via command line etc... and I really like to use my VScode IDE on my Windows machine .
If I don't succeed I will revert to Visual studio, C#.NET and mono on the PI but I will keep looking for a while.
The remote development option for VScode does work very neatly. Edit/develop everything from Visual studio code on the windows 10 machine, build and test everything on the Raspberry PI. It takes a bit of doing to get it all to work nicely together but I have a working application that uses the GTK-2.0 library that is installed on the PI. Thanks for the suggestion.
One of the most beautiful pieces of kit ever built, I think. Second would be the LNER Class A4, which has held the speed record for steam engines at 126 MPH since 1938! Maybe I should change my name to Mallard, instead?
I have dual citizenship. Born in the UK, but we emigrated to Canada when I was only six, which was over 50 years ago, now. So, yeah, I do, bit it's somewhat tenuous. I don't really remember much about life in Britain.
I generally do not like when post ask " I am using / have X ..." and poster receives "advise" "why don't you use XYZ instead.."
I have been struggling using Linux version of X IDE together with "plug-in" called "Terminal communication framework" - TCF.
It is rather obscure framework , but does all the "dirty work" after the code is cross-compiled.
My app is intended to run on RPi and so far TCF works as expected.
i set up python 3.4 and PostgreSQL 10.6 on Oracle Linux 7.4.
when i create plpython3u it's error.
could not load library "/u01/PostgreSQL/10/lib/postgresql/plpython3.so": libpython3.4m.so.1.0: cannot open shared object file: No such file or directory
then i add export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH in file ~/bash_profile
Finally, i have to restart services postgreSQL : pg_ctl restart ==> it's ok.
but when i reboot linux , it will be error again, i guess LD_LIBRARY_PATH load after service postgres start. How i Can resolve it ?
Thank you !
There should be some information in the PostgreSQL installation guide as to how to set this up. But if not then I would guess it needs to be set in one of the /etc/rc startup scripts. You will need to check the Linux man pages to decide which one you should use.
to /lib/systemd/system/postgresql.service. The best place for that would be right after the line that says Export=PGDATA=path-to-pgdata
Meanwhile, I would follow Richard's advice and contact the PostgreSQL mailing list and ask there. They may have a better solution so that when you update to PGSQL 10.XX or 11.XX, you won't have to continually remember to edit the startup script.