In Android.mk, I read the context of system environment variable like $(MY_ENV_VARIABLE). The env variable contains following string inside "Program(x86) Files".
But the build fails, claiming that the specified library cannot be found. The failure takes place of windows style weird space in "Program(x86) Files".
So my question is, is there any mechanism to automatically escape the special symbols like space (i.e "Program(x86)\ Files", for my case).
You might be able to try using the windows pathing conventions of using the tilde character so instead of C:\Program(x86) Files\mydir it would be C:\PROGRA~2\mydir (PROGRA~1 is for the 64 bit program files).
Like eldar said in the comments it is better to not use spaces in path names because most of make's functions use spaces as delimiters. Another option you could try is to take a look at my suggestion here: WINAVR not finding file in include path with whitespace
Since Android is a pretty complicated build environment it might be hard to see where to place the final substitution unless you know what you're doing and hopefully won't break anything else in the makefile.
Related
There is a LIBS environment variable for mpicxx. But the man page only says
Libraries added when invoking the linker
I wish to know detailed syntax for this variable, for example, should we prefix -L before directory, should we just write the directory name or the lib filename, should we separate multiple libraries by space or comma or something else, etc.? I tried to google the syntax but could find no information about it. So I ask here. Thanks for your help.
I wish to know detailed syntax for this variable
The LIBS variable recognized by MPI compiler wrappers is not specific to those programs, and it does not have a syntax of its own. The variable is just expanded (unquoted) to form part of the link command line, at a position among the arguments appropriate for the designation of libraries to include in the link. The general syntax is a subset of the syntax of shell commands, and the specific significance of the contents is governed by linker.
Do note that to the extent that it matters, "the linker" is probably not ld directly, but rather (for mpicxx) a C++ compiler front-end such as g++. You specify libraries and library search path entries in the same form that you would do when linking your program with a non-MPI C++ compiler.
should we prefix -L before directory
If you want to add directories to the library search path then yes, you would use -L options.
should we just write [...] the lib filename
Most conventional would be to use -l options, so to link libfoo.so, you would use -lfoo. Alternatively, you should also be able to specify a relative or absolute path to the library file (without -l), in which case the search path is irrelevant. Specifying libraries via a specific path is normally used only for libraries built as part of the same project.
should we separate multiple libraries by space or comma or something else
You are specifying options and arguments that are expanded to be part of a shell command. Multiple arguments must be separated by whitespace.
etc.
The details all follow from the manner in which the variable is used, as already described. Some available features (but not usually anything described above) may vary from system to system, depending on the options recognized by the underlying linker.
I'm sure this is one of the dumbest problems asked on this site, but I am very new to linux, and a little out of my depths. I'm working off of this tutorial here and am stuck on the "add the path" and verify steps.
For this one the tutorial told me to use this:
export PATH=${PATH}:${DTITK_ROOT}/bin:${DTITK_ROOT}/utilities:${DTITK_ROOT}/scripts
I have already defined DTITK_ROOT, and have a few questions about the above instructions.
Should the ${} be left around the DTITK_ROOT?
My DTITK_ROOT is the full path (I think that's the right term) to the file I extracted the program to, should I change that?
What do I write for ${PATH} in that case? I understand that I'm supposed to replace it with something, but I don't know what. Everything I've tried doesn't pass the verify step.
I'm sorry if it seems like a dumb or really simple question, but I don't even know any keywords to google in order to find how to get the answer.
Yes. This is how you access the path stored in DTITK_ROOT. This is called parameter expansion. You can read more about it here.
No, don't change anything. Also, a more commonly used term is absolute path, in comparison to relative path. The absolute path is a path from the root directory, /. Relative path is a path from your current working directory. You can read more about paths in general and the difference between absolute and relative paths here.
You don't replace it with anything. Once again, parameter expansion comes into play and this will be replaced with what is already stored in your path variable. So really all this command is doing is taking your path variable, adding some more paths to it, and then storing it back into your path variable. If you didn't know, the path variable contains paths to all executable files that you would like to execute without typing the full path. Here is a good discussion on path variables, along with other environment variables.
1st command takes care of path
export DTITK_ROOT=mypathonSystem/dtitk
2nd command
export PATH=${PATH}:${DTITK_ROOT}/bin:${DTITK_ROOT}/utilities:${DTITK_ROOT}/scripts
I am not too sure but I think second command should run as is since you defined DDTITK_ROOT in first command
${PATH} is letting the system know where the resources can be found at
have you tried running first command, then running second command unmodified?
Should the ${} be left around the DTITK_ROOT?
Yes. In the case of the shell, it is not essential here because the / that follows the $DTITK_ROOT is enough to signal that we have reached the end of the variable name, but doing ${DTITK_ROOT} explicitly says that the variable name is DTITK_ROOT and not that plus whatever characters might be on the end of it. Other programs (such as make) which allow you to write shell commands to execute might not be so accommodating - make would think that $DTITK_ROOT would be the value of $D followed by the literal characters TITK_ROOT. So, it is a good practice to just get used to putting {} around shell variable names that are longer than a single character.
My DTITK_ROOT is the full path to the file I extracted the program to, should I change that?
If you mean the full path to the directory that you extracted the program to, then that is what you should use. I am assuming that you have something like "export DTITK_ROOT=/Users/huiz/unix/dtitk" (per the example).
On thing you can do is to verify that the value of DTITK_ROOT is available by executing a "echo ${DTITK_ROOT}" to verify that it has the proper value.
I am trying to debug an application that is cross-compiled on a Windows host for a Linux target.
The problem:
Because the initial compilation is in windows the stored source file paths in the binary is of the form C:\Users\foo\project\.... On the Linux target I have put the source files under \home\foo\project\.... By default gdb does not find the source file because of the different path.
What I have tried so far:
Use "directory" command in gdb to give an exact path for the .c source file in the target Linux system where the app is being debugged. This works but unfortunately there are literally hundreds of files so this solution is unrealistic.
Use the set substitute-path C:\\Users\\foo\\project /home/foo/project command to have gdb substitute all prefixes. Note that the \\ seems necessary such that show substitute-path registers the right string. This unfortunately does not work. My guess is that the substitute-path command does not handle ms-dos style paths.
Tried separating the debug info out into a separate .debug file (see How to generate gcc debug symbol outside the build target?) and then using debugedit to change the paths with the command debugedit --base-dir=C:\Users\foo --dest-dir=/home/foo project.debug. Unfortunately this does not work either. debugedit seems to work fine if the existing path is all UNIX/Linux like but doesn't seem to work with ms-dos style paths.
I have looked around stackoverflow and while there are similar topics I can't find anything that will help me. Would really appreciate any suggestions/help. I realize that cross compiling from Windows is a very roundabout way but can't avoid that for the moment.
Thanks
Although it's rather old question, I did encountered the same problem. I managed to resolve it but using sed on binary executable... (yeah, a 'bit' hack-ish, but did not found another way). With sed I've managed to replace symbols paths right inside the executable, the trick is that new path's length should be the same as the old one.
sed -i "s#C:/srcpath#/srcpath/.#g" ./executable
Be sure to make new path the same length, otherwise the executable will brake.
I also have this same problem. Your option 1 isn't as bad as you think because you can script creating all the 'directory' commands with something like this python code:
def get_directory_paths():
return_array = list()
unix_path = os.path.join('my','unix','path')
for root, dirs, files in os.walk(unix_path):
for dir in dirs:
full_unix_path = os.path.join(root,dir)
escaped_unix_path = re.sub("\s", "\\\\ ", full_unix_path)
return_array.insert(0, "directory " + escaped_unix_path)
return '\n'.join(return_array)
The downside is that if you have two source files with the same name in different directories, I don't think gcc can pick the right one. That worries me, but in my particular situation, I think I'm safe.
For option 2 (which I suspect would fix the aliasing condition from #1), I think the problem is that the substitutions are not ending with a "file separator" according to the linux so they aren't applied:
To avoid unexpected substitution results, a rule is applied only if the from part of the directory name ends at a directory separator. For instance, a rule substituting /usr/source into /mnt/cross will be applied to /usr/source/foo-1.0 but not to /usr/sourceware/foo-2.0. And because the substitution is applied only at the beginning of the directory name, this rule will not be applied to /root/usr/source/baz.c either." (from https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html#index-set-substitute_002dpath )
I haven't tried anything like your #3 and I also considered something like #dragn suggestion, but in my situation the paths are not even close to the same length, so that will be an issue.
I think I'm stuck with #1 and a script, but if anyone has other suggestions, I'm interested options :-)
I have a project I can build on both Linux and Windows using CMake. The only issue is that Unix-style paths, in CMakeLists.txt, can't work on Windows (which uses backslashes instead of slashes, also requiring the drive letter).
Is there any way I can write a cross-platform CMakeLists.txt?
You question affects different details:
Just don't use backslashes. Windows will also process slashes.
Don't use drive letters. Use relative paths everywhere.
GET_FILENAME_COMPONENT(X "${CMAKE_CURRENT_SOURCE_DIR}" REALPATH) can solve the whole path without writing any absolute paths.
Add the tool binary paths into your PATH environment variable. So you do not need to search them by yourself (with absolute paths) or
Use FIND_PROGRAM() to get the tools absolute path without guessing around. You could add hints in which registry entries and paths cmake will search for the tool or
Consider to write your own module for every tool. You can copy the skeleton from any module of the modules folder (have a lock at FindJava.cmake; a very good and portable example on how to search a program).
If all those does not help, you can detect the platform by IF(WIN32) or IF(UNIX).
Hope, this helps...
On Linux and other Unix-likes, how do I find the path to a specific file that I can use because of the PATH environment variable? For example, if I can use, from the command line:
ls # technically the file name is "ls.exe"
is there a way I can find the path of the ls.exe file explicitly without looking through the PATH variable myself (i.e. maybe have a program search through it but not look myself)?
I understand there are many pitfalls/caveats of doing this, for example a PATH can be a file or even part of a file (I think), plus symlinks, etc. could make it unreliable, but I'm looking for general use cases.
The reason I am asking is I have Windows with msysgit so I have A LOT of folders in my path, and searching every one would be annoying & time-consuming, not to mention harder because of Windows limitations, but I can still presumably use almost anything Linux can use.
$ type ls.exe
ls.exe is /usr/bin/ls.exe