I have a CMake such that when I executed the build (make) in verbose mode, it prints commands such as:
/usr/bin/nvcc -forward-unknown-to-host-compiler -DBOOST_ALL_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_PP_VARIADICS -DBOOST_TIMER_DYN_LINK -DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK --expt-relaxed-constexpr --extended-lambda -Xcudafe "--display_error_number --diag_suppress=implicit_return_from_non_void_function --diag_suppress=class_and_member_name_conflict" --generate-code=arch=compute_61,code=[compute_61,sm_61] -std=c++17 -x cu -c /home/correaa/prj/alf/boost/multi/adaptors/thrust/test/array.cu -o CMakeFiles/array.cu.x.dir/array.cu.o
presumably, this is a bash-compatible command because I have no problem running it in bash.
However it is not a valid zsh command (the shell I use) because it gives an error:
zsh: no matches found: --generate-code=arch=compute_61,code=[compute_61,sm_61]
I presume it is the square brackets that trip zsh [...].
First question is how can I correct manually this command to run on both zsh and bash?
Second question is, is there a way to for CMake to generate makefiles that contain commands that are compatible with zsh?
I'm trying to run a shell script, which executes a cmake command. It runs on windows on the git-bash.
My run.sh code looks like this:
CMAKE_GENERATOR="'Unix Makefiles'"
performStrict cmake -G "${CMAKE_GENERATOR}" /path/to/dir/
And delivers the following output:
cmake -G 'Unix Makefiles' /path/to/dir/
CMake Error: Could not create named generator 'Unix
I also tried it with (escaped) double quotes. Unfortunately, it gives the same result. Also with many other possible combinations.
When I try
gcc -c *.c
I get an invalid argument error, and it says no input files.
If you run gcc from a directory where no C source files are present, gcc will receive the *.c argument unexpanded, will try to open a file named *.c and fail, will report this failure and in the absence of further arguments, will complain about the missing input files:
$ gcc -c *.c
gcc: error: *.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
$
The wildcard expansion is performed by the command line interpreter, aka the shell. On a unix system, there are many different shells, sh, csh, tcsh, bash, zsh... all of which expand unquoted wildcards before running the commands. On Windows, the default shells do not expand wildcards for external commands, some programs do it on their own, but most don't. If you run bash on Windows, with or without cygwin, you will get the Unix behavior, but if you run cmd.exe, you won't.
MinGW is a set of development tools to make Windows native executables. It does not provide a shell and favors using the native libraries and utilities when possible. This is the reason why your command gcc -c *.c does not undergo wildcard expansion on your machine. Install bash or cygwin for a more unix-friendly environment.
This should do what you're looking for.
find . -name '*.c' -print | xargs gcc -c
I have the following gcc command taken from a tutorial to compile my simple mysql c test program.
gcc mysql_test.c `mysql_config --cflags --libs`
I am trying to understand what is happening here with mysql_config. But I cannot find any information by googling or searching SO for the use of accents (the lower case tilde character) in gcc commands. I don't see anything relevant in the gcc options index.
Can anyone explain this or describe what gcc process the accent is invoking?
The backticks here are for the shell, not for gcc. The shell executes the command inside the backticks and substitutes the output of the command. Presumably the msql_config command with those options produces the options you should pass to gcc.
On Windows, I'm cross-compiling a program for ARM/Linux using CodeSourcery's cross-compiler suite. I use MinGW MSYS as my command interpreter, and very often it will mangle my paths and pathnames. For example, to build my program, I invoke
arm-none-linux-gnueabi-gcc.exe -Wall -g \
-Wl,--dynamic-linker=/usr/lib/myrpath/ld-linux.so.3 \
-Wl,-rpath=/usr/lib/myrpath \
-I../targetsysroot/usr/include \
myprogram.c -o myprogram
Of course, I want /usr/lib/myrpath inserted verbatim into the myprogram executable - the ARM Linux target I'm compiling for doesn't use MinGW or MSYS. But here's what ends up going into it:
...
0x0000000f (RPATH) Library rpath: [C:/MinGW/msys/1.0/lib/myrpath]
...
Not exactly what I wanted. If I invoke GCC on the cmd.exe command line directly, I get the right rpath in the executable. If I invoke GCC on the MSYS command line, I get the mangled rpath. If I invoke GCC with a Makefile that is run with make from the cmd.exe command line, I still get a mangled rpath (!)
Any ideas how I might turn off this annoying behavior?
There is a way to suppress the path translation by setting MSYS_NO_PATHCONV=1 in Windows Git MSys or MSYS2_ARG_CONV_EXCL="*" in MSYS2.
Alternatively, you can set the variable only temporarily just for that command by putting the assignment just before the command itself:
MSYS_NO_PATHCONV=1 arm-none-linux-gnueabi-gcc.exe -Wall -g \
-Wl,--dynamic-linker=/usr/lib/myrpath/ld-linux.so.3 \
-Wl,-rpath=/usr/lib/myrpath \
-I../targetsysroot/usr/include \
myprogram.c -o myprogram
I just discovered a neat trick to avoid MSYS/MinGW translating the paths for you.
If you use double-slash to start the path, then MSYS won't translate the path to DOS format. So in OP's example, the -rpath switch should be specified like this:
-Wl,-rpath=//usr/lib/myrpath
All Unix/Linux tools seem to handle such spurious slashes without any problem, so even though your binary's rpath will start with //usr/... I think the loader will do the right thing.
I don't think there's a way to switch this off. MSYS is a fork of an old Cygwin version with a number of tweaks aimed at improved Windows integration, whereby the automatic POSIX path translation when invoking native Windows programs is arguably the most significant. The trouble with that is that it isn't always possible to tell whether an argument is a path or something else, or whether, as in this case, it is in fact a path that nevertheless shouldn't be translated. The translation is guided by a set of heuristics.
You could try using MinGW make instead of MSYS make (yes, they're different things), which is a native Windows build of make without POSIX path support and conversion. Install with mingw-get install mingw32-make and invoke as mingw32-make.
Or you could try Cygwin, ideally with a Cygwin build of the toolchain.
Indeed, in the original MSYS project provided by MinGW.org, there is no way to disable the Posix path conversion.
That's why I made a little fork of the msys-core runtime which supports the MSYS_NO_PATHCONV flag introduced with the Git for Windows fork. In that way, you may use MSYS_NO_PATHCONV environment variable as in the Git for Windows but in the original MinGW/MSYS.
So in summary, to disable this Posix path convesion:
For MSYS2 (built-in): MSYS2_ARG_CONV_EXCL="*"
For Git for Windows (built-in): MSYS_NO_PATHCONV=1
For MinGW.org (with msys-core-extended): MSYS_NO_PATHCONV=1.
export MSYS_NO_PATHCONV=1 was necessary in my case on git-bash on windows (as noted by dx_over_dt above. )
Unfortunately putting two forward slashes for this example doesn't work as expected.
rsync -rvztn --delete --exclude="/application/logs/" ...
I want 'rsync' to exclude files only at /application/logs which is at the top level, hence the leading forward slash. Adding two forward slashes will not cause it to exclude this directory. I have to resort to the less accurate --exclude="application/logs/".