I want to change the behavior of the ARM toolchain arm-linux-gnueabi-gcc in my Linux machine, that the compiled code will be in Thumb mode as default - same as passing the -mthumb flag.
I came across this document, which under the section of --with-mode describes exactly what I try to achieve. However, I couldn't understand from their explanation how can I actually set this option.
Can anyone clarify this for me, or suggest another way to achieve my goal?
You can "mask" the executable file /usr/bin/arm-linux-gnueabi-gcc with your own script that is named the same inside /usr/local/bin.
Create a file /usr/local/bin/arm-linux-gnueabi-gcc
With the content
#!/bin/sh
/usr/bin/arm-linux-gnueabi-gcc -mthumb "$#"
Add executable permissions to /usr/local/bin/arm-linux-gnueabi-gcc
Because PATH should list /usr/local/bin directory before /usr/bin, when you type arm-linux-gnueabi-gcc without the path in your console, your script will chosen first and will execute the real arm-linux-gnueabi-gcc executable with the additional option.
I want to avoid typing "-std=c++11" on the command line every time.
Is there any simple/direct solution to my question?
If you can, upgrade to GCC 6.
The default mode for C++ is now -std=gnu++14 instead of -std=gnu++98.
You can get a GCC supporting new GCC for example here:
https://nuwen.net/mingw.html
Windows has the DOSKEY command to define macros (which are analogous to Unix aliases).
Something like this should work:
doskey g++="g++ --std=c++11 $*"
A Makefile and the CXXFLAGS variable is an alternative (e.g. see Makefile c++11 support).
By default, when running make to compile a C source code file named prog.c
make prog
the default command that executes is
cc prog.c -o prog
Sometimes I really need to include some additional flags. I know that when there are no Makefiles, make relies on some environment variables.
On Ubuntu 14.04, how to configure these variables to change the command that gets executed by default?
Step by step answers will be appreciated!
When no makefile is present (or no rule exists in that makefile) make relies on a default built-in database of rules. Run make -p to get make to spit out all the rules it knows about (in the no makefile case that will be the default ones).
When you look at that list you will find a pattern rule for building C source into object files or executables. Those rules have variables in them (like CFLAGS, LDFLAGS, etc.) that can be used to control exactly what you are trying to. That's why they are there (and are why that default command has such funny spacing, in case you ever wondered about that).
I am trying to set up CMake to generate a MSVC (2010) solution for our project, and need to configure the projects so that they use our specific build system rather than compiling using the default command line.
Here's what the project file looks like for VS2008 (which we generate using another script that I'd like to get away from):
<Tool
Name="VCNMakeTool"
BuildCommandLine="../bam.bat -j %%NUMBER_OF_PROCESSORS%%"
ReBuildCommandLine="../bam.bat -j %%NUMBER_OF_PROCESSORS%% -c && ../bam.bat -j %%NUMBER_OF_PROCESSORS%%"
CleanCommandLine="../bam.bat -j %%NUMBER_OF_PROCESSORS%% -c "
Output="..\..\..\common\win32\container.exe"
PreprocessorDefinitions=""
IncludeSearchPath=""
ForcedIncludes=""
AssemblySearchPath=""
ForcedUsingAssemblies=""
CompileAsManaged=""
/>
It's basically the three CommandLine settings I'd like to be able to specify from my cmake config.
I've found the build_command command in the documentation but from the description it sounds like it does sort of the opposite of what I want, i.e. writes the command line it'll generate to a variable rather than take a string and set the command line to that.
Something that seems a bit related is the cross-compile feature in CMake but I'm sure if that is a good way to do this.
Basically I just want VS to run a batch file when I do a build and then parse the results back to get nice error messages etc.
It looks to me like what you want is simply a "custom command" in CMake parlance.
Something like:
set(custom_exe "${CMAKE_CURRENT_BINARY_DIR}/common/win32/container.exe")
add_custom_command(OUTPUT ${custom_exe}
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/bam.bat -j $ENV{NUMBER_OF_PROCESSORS}
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bam.bat
)
add_custom_target(bam ALL DEPENDS ${custom_exe})
Maybe you need to write your own CMake Toolchain. You can see examples of toolchains in CMAKE_ROOT/share/Modules/Platform, or in CMake documentation, but i'm not sure whether cmake can generate MSVC solution for custom compiler.
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/".