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.
Related
My SCons project depends on a lot of third party libs, each providing dozens or hundreds of include files.
My understanding of how SCons works is that, on each build, it parses the source files of my project to find the #include directives, and it uses the value of env['CPPPATH'] to find these files and compute their md5 sum.
This scanning is costly, and thus I would like to optimize this process by teaching SCons that all the headers of my third party files will never change. This property is actually enforced by the tool that manages our third party libs.
I know there is a --implicit-deps-unchanged option that forces scons to assume that the implicit dependencies did not change, but it works globally. I did not find a way to restrict this option to a particular directory. I tried to find if the default Scanner of implicit C++ files can be configured, but found nothing. I think it is possible to avoid using CPPPATH, and instead only give the -I option to the compiler directly, but it is cumbersome.
Is there any way to optimize SCons by teaching him that files in a directory will never, ever change?
You can try pre-expanding the list of header file paths into CCFLAGS.
Note that doing so means they will not be scanned.
for i in list_of_third_party_header_directories:
env['CCFLAGS'].append('-I' + i)
In this case the contents of CPPPATH would be your source directories, and not the third-party ones which you assert don't change.
Note that changing the command line of your compile commands in any way (unless the arguments are enclosed in $( $)) will cause your source files to recompile.
If I have two libraries with the same library name but stored in different directories (and they may contain different code) and I list both directories in the LDFLAGS variable in a makefile, how does the linker know where to look first and which library to use?
LDFLAGS+= \
-L${INSTALL_DIR}/lib\
-L${EVO_INSTALL_DIR}/lib\
Will it look in the INSTALL_DIR path first or in the EVO_INSTALL_DIR path?
INSTALL_DIR. It will look in the order they are listed.
By the way, it's your linker (probably the same program as your compiler) that's making this choice, not the Makefile. Make (which is reading your Makefile) only runs the build tools.
Is it possible to DISABLE source code view in backtrace, to display only line numbers and file names?
I mean do NOT include these informations to application, because you can also read from the application file.
I don't want anyone to see my source code.
If it's impossible in GDB, is there any other debugger with such feature?
GDB can only show your source code if it can find your original source files. If people can see your source in the backtrace, then presumably they can also see your entire source base.
Therefore, I suspect you mean that you do not want the compiler to include any of your sources in the application binaries?
In fact, the application binaries only contain the source filenames, line numbers, symbol names (such as function and variable names), and some type information. If you use -g3 then they might also include preprocessor macros, but most people just use -g.
The easiest way to exclude the 'source' information is to not ship binaries with debug information. You can either build it without using -g in the first place, or you can use strip to remove it after the fact.
Not building with debug info will remove all symbol names that are not absolutely necessary (including static functions, and all local variable names), but it will not remove the symbol names for externally visible functions: the linker needs to see those. strip can remove some of those also, I think, although I've never tried. Beware that libraries must have symbol names for externally visible function.
Removing debug info will also remove line-number information, and source file names, so this still isn't quite what you want.
I'd suggest a) refactoring your source code so that isn't embarrassing and/or give away any clues, and b) don't ship with debug info.
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.
I'm trying to write a configure.ac file such that the resulting configure script searches for a library directory containing a given static library e.g. libsomething.a. How can I do this? At the moment I have it check just one location with:
AC_CHECK_FILE([/usr/local/lib/libsomething.a],[AC_SUBST(libsomething,"-L/usr/local/lib -lsomething")],[AC_SUBST(libcfitsio,'')])
But I want it to try and find it automatically. And if the library isn't in one of the default locations, I'd like configure to say that the library wasn't found and that a custom location can be specified with --use-something=path as is usually done. So I also need to then check if --use-something=path is provided. I'm pretty new at creating configure files, and the M4 documentation isn't very easy to follow, so would appreciate any help.
Thanks!
It's not the job of configure to search where libraries are installed. it should only make sure they are available to the linker. If the user installed them in a different location, he knows how to call ./configure CPPFLAGS=-I/the/location/include LDFLAGS=-L/the/location/lib so that the tools will find the library (this is explained in the --help output of configure and in the standard INSTALL file).
Also --with-package and --enable-package macros are not supposed to be used to specify paths, contrary to what many third-party macros will do. The GNU Coding Standards explicitly prohibit this usage:
Do not use a --with option to
specify the file name to use to find
certain files. That is outside the scope
of what --with options are for.
CPPFLAGS and LDFLAGS are already here to address the problem, so why redevelop and maintain another mechanism?
The best way to figure this out is to look at other autoconf macros that do something similar. Autoconf macros are an amalgam of Bourne shell script and M4 code, so they can literally solve any computable problem.
Here's a link to a macro I wrote for MySQL++ that does this: mysql++.m4.