The valgrind tool's source code releases (http://valgrind.org/downloads/current.html) show suppression files in the root directory, such as darwin16.supp.
If I want to use these files do I have to obtain them from a source download or are they added to some location on a machine during installation?
e.g. If I have my CI install valgrind will I then be able to reference one of these supp files from some location within the system or do I need to make it available in some other way?
Analysis of Valgrind's build system, particularly its top-level Makefile.am, shows that at build time it creates one default suppression file appropriate for the platform, and that it installs that file at the installation stage. The default suppression file seems to be built from zero or more of the individual suppression files you're looking at, but the individual files are not installed.
What is or is not included in a particular pre-built Valgrind package is an entirely different question. You can probably rely on the generated default suppression file to be included, as Valgrind depends on it. For example, the Valgrind 3.12.0 packages for CentOS 7 indeed do include it. Those particular packages do not include the individual component files from the Valgrind source, which is not surprising because the build system does not install them. Other packages might nevertheless provide them.
Related
I have a simple CMake project with CTest and CPack. It uses the Lua C API to load and execute an script file called script.lua.
This script will be in different location when built vs when installed/packed, it's location would be:
[build] : ${CMAKE_CURRENT_SOURCE_DIR}/src/scripts
[install]: ../scripts (relative to app which is in bin directory)
What I'm trying to achieve here is to have install step regenerate configure_file then rebuild using new configure_file and only then proceed to do the normal install step and of course revert the configure_file back to it's original state afterwards.
Any help regarding this issue is appreciated.
My understanding is that CMake's configure_file command has its full effect during the execution of the cmake program. It has no representation in generated makefiles, or whatever other build system components cmake generates. Thus, if you want to configure a file differently for installation than for pre-installation testing,
You would need to perform completely separate builds (starting with executing cmake) for the two cases, and
You would need to use some attribute of the cmake command line or execution environment to convey the wanted information, such as using a -D option to define a CMake variable on the command line.
I advise you not to pursue this route. Aside from being overcomplicated, it's also poor form to install a different build of the software than is tested.
You have a variety of alternatives that could serve better. Among those are
Give the program itself the ability to accept a custom location for the Lua script. That is, make it recognize a command-line argument or environment variable that serves this purpose. Make use of that during pre-installation testing.
If indeed the program is using a relative path to locate the script at runtime, then just (have CMake) put a copy of the script at the appropriate location in the build tree, so that the program will find it normally during testing.
I worked on GIS project and i need 64 bit gis lib.And than;
What did i?
I download lzo-2.10 file.
I run visual studio 2015 64x command prompt
cd C:\Users\user\Desktop\lzo-2.10
./configure
and ı got some error like that:
'.' is not recognized as an internal or external command,
operable program or batch file.
INSTALL.txt which include lzo-2.10 said that:
The simplest way to compile this package is:
cd' to the directory containing the package's source code and type
./configure' to configure the package for your system. If you're
using csh' on an old version of System V, you might need to type
sh ./configure' instead to prevent csh' from trying to execute
configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
Type `make' to compile the package.
Optionally, type `make check' to run any self-tests that come with
the package.
Type `make install' to install the programs and any data files and
documentation.
You can remove the program binaries and object files from the
source code directory by typing make clean'. To also remove the
files thatconfigure' created (so you can compile the package for
a different kind of computer), type make distclean'. There is
also amake maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
But I even couldn't first step. I searched but couldn't fix this situation.pls help me.
It looks like your GIS library require linux to be build. Given that you use VS2015 I assume you work on Windows instead.
I am trying to use GLScene (a third-party FireMonkey component for C++Builder and Delphi). I downloaded the zip, and in it, among other things, are .bpl files for use in C++Builder. When I try to install the package in my project (a C++Builder multi-device application) under Component > Install Packages... > Add, I get this error:
My directory structure:
The _Installation directory and the Readme's are not very helpful. I have tried the other .bpl files and also tried importing all of them at once, but the same error occurs. How do I fix this?
There are several problems.
The XE3 extension is suspicious. I just downloaded and unzipped the GLScene download. The .BPLs in the CBXE3 and CBXE4 seem to be compiled for XE3 and XE4 respectively. But packages are version-dependent.
You should recompile the sources (also included) for 10.2 Tokyo. Just copy the DelphiXE4 directory to a new directory, and load the .groupproj file or the single .dpk files into the IDE. You might want to change the suffixes (currently XE3) of the packages to, say, Tokyo, in the project options, to avoid DLL (or BPL) hell.Also take a look at the pictures in the _Installation directory for the other options that must be set. Note that your paths may differ, theirs are just an example.
The compiler needs to be able to find the .bpi and .lib etc. files in order to be able to link. Set the directories with those files in the project options, as shown in the _Installation pictures.
The newly compiled .bpl files should be compiled to a directory on the Windows path, so they can be found by the system at runtime. In their example setup, (and in the _Installation pictures) that is the shown C:\Library\GLScene path.
I just installed CodeLite onto a brand new PC and I am not able to compile anything. I want to write a console application in C
Simple Executable (gcc)
Compiler: gnu gcc
Debugger: GNU gdb debugger
However, I can't even build a default "hello world" application. All I get is this error:
C:\Windows\system32\cmd.exe /C mingw32-make.exe -j 4 -e -f Makefile
'mingw32-make.exe' is not recognized as an internal or external command,
operable program or batch file.
Now I "googled" this and found out, I have to set up mingw32-make, (which I didn't have to do on 3 other computers) but I can't find a tutorial on how to do that.
Any advice will be highly appreciated!
Thanks in advance.
CodeLite does not install MinGW for you. You need to do it for yourself.
Obviously, CodeLite does not know where to find mingw32-make.exe otherwise, it wouldn't use just mingw32-make.exe instead it uses the full path to mingw32-make, something like C:\TDM-GCC-64\bin\mingw32-make.exe
What you need to do is:
Run CodeLite setup wizard again from Help->Run the Setup Wizard
Follow the steps (5 in total), pay close attention to the Setup Compilers step
If you have installed MinGW before, just click on the Scan button
If you don't have, click the Install button
Open your project settings->General page and select the compiler you just installed in the Compiler field
Make enables the end user to build and install your package without knowing the details of how that is done -- because these details are recorded in the makefile that you supply.
Make figures out automatically which files it needs to update, based on which source files have changed. It also automatically determines the proper order for updating files, in case one non-source file depends on another non-source http://file.As a result, if you change a few source files and then run Make, it does not need to recompile all of your program. It updates only those non-source files that depend directly or indirectly on the source files that you changed.
Make is not limited to any particular language. For each non-source file in the program, the makefile specifies the shell commands to compute it. These shell commands can run a compiler to produce an object file, the linker to produce an executable, ar to update a library, or TeX or Makeinfo to format documentation.
I just started coding in C, and ran someone else's Makefile with the default C compiler set to gcc. I am on Mac OSX 10.8 Mountain Lion and I believe I installed the compiler with "XCode Command Line Tools." After running "make" on command line, I get these annoying .dSYM files for each program. I read that these are debug files, but are they really necessary? Is there any way to prevent them from being generated from command line?
The -g flag to GCC will generate debug symbols. You may simply remove that flag from CFLAGS.
Yes, the dSYM files are necessary. Specifically, they contain the symbol tables that are included within Xcode debug builds; release builds put the symbols in this separate file. If you ever need to analyze a stack trace from a release build you will need this. And make sure you don't lose the files, because doing the build again, even if the source is absolutely the same, won't produce a usable dSYM file. Each build is given a UUID and that changes with each build, even if the source has not changed. (I guess it includes a timestamp or even a random number.)
If you throw away the dSYM files, then if you suddenly find your app crashing a lot, you may be sorry.
They're only necessary if you need to interpret locations in stack traces within a crash report.