I'm trying to build the azure storage sdk and have hit a build failure. Looking at the build commands, I see that it is trying to use an old CXXFLAGS value (not sure if this is the reason for the failure but would like to clean this up).
My steps were essentially:
export CXXFLAGS="-fPIC"
run cmake3 and make on cpprestsdk
unset CXXFLAGS
run cmake3 on azure-storage-cpp
Then when I look at my compile_commands.json file, I still see the -fPIC option being used. I tried deleting the directory and cloning again but it is still there.
CXXFLAGS is not set anymore, even tried using a new shell but still no luck:
$ echo $CXXFLAGS
Any ideas what is going on?
Edit:
I'm using the following command:
cmake3 .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
and am following CentOS instructions from https://github.com/Azure/azure-storage-cpp
I'm trying to debug a compilation problem, but I cannot seem to get GCC (or maybe it is make??) to show me the actual compiler and linker commands it is executing.
Here is the output I am seeing:
CCLD libvirt_parthelper
libvirt_parthelper-parthelper.o: In function `main':
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:102: undefined reference to `ped_device_get'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:116: undefined reference to `ped_disk_new'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:122: undefined reference to `ped_disk_next_partition'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:172: undefined reference to `ped_disk_next_partition'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:172: undefined reference to `ped_disk_next_partition'
collect2: ld returned 1 exit status
make[3]: *** [libvirt_parthelper] Error 1
What I want to see should be similar to this:
$ make
gcc -Wall -c -o main.o main.c
gcc -Wall -c -o hello_fn.o hello_fn.c
gcc main.o hello_fn.o -o main
Notice how this example has the complete gcc command displayed. The above example merely shows things like "CCLD libvirt_parthelper". I'm not sure how to control this behavior.
To invoke a dry run:
make -n
This will show what make is attempting to do.
Build system independent method
make SHELL='sh -x'
is another option. Sample Makefile:
a:
#echo a
Output:
+ echo a
a
This sets the special SHELL variable for make, and -x tells sh to print the expanded line before executing it.
One advantage over -n is that is actually runs the commands. I have found that for some projects (e.g. Linux kernel) that -n may stop running much earlier than usual probably because of dependency problems.
One downside of this method is that you have to ensure that the shell that will be used is sh, which is the default one used by Make as they are POSIX, but could be changed with the SHELL make variable.
Doing sh -v would be cool as well, but Dash 0.5.7 (Ubuntu 14.04 sh) ignores for -c commands (which seems to be how make uses it) so it doesn't do anything.
make -p will also interest you, which prints the values of set variables.
CMake generated Makefiles always support VERBOSE=1
As in:
mkdir build
cd build
cmake ..
make VERBOSE=1
Dedicated question at: Using CMake with GNU Make: How can I see the exact commands?
Library makefiles, which are generated by autotools (the ./configure you have to issue) often have a verbose option, so basically, using make VERBOSE=1 or make V=1 should give you the full commands.
But this depends on how the makefile was generated.
The -d option might help, but it will give you an extremely long output.
Since GNU Make version 4.0, the --trace argument is a nice way to tell what and why a makefile do, outputing lines like:
makefile:8: target 'foo.o' does not exist
or
makefile:12: update target 'foo' due to: bar
Use make V=1
Other suggestions here:
make VERBOSE=1 - did not work at least from my trials.
make -n - displays only logical operation, not command line being executed. E.g. CC source.cpp
make --debug=j - works as well, but might also enable multi threaded building, causing extra output.
I like to use:
make --debug=j
https://linux.die.net/man/1/make
--debug[=FLAGS]
Print debugging information in addition to normal processing. If the FLAGS are omitted, then the behavior is the same as if -d was specified. FLAGS may be a for all debugging output (same as using -d), b for basic debugging, v for more verbose basic debugging, i for showing implicit rules, j for details on invocation of commands, and m for debugging while remaking makefiles.
Depending on your automake version, you can also use this:
make AM_DEFAULT_VERBOSITY=1
Reference: AM_DEFAULT_VERBOSITY
Note: I added this answer since V=1 did not work for me.
In case you want to see all commands (including the compiled ones) of the default target run:
make --always-make --dry-run
make -Bn
show commands executed the next run of make:
make --dry-run
make -n
You are free to choose a target other than the default in this example.
I am trying to integrate valgrind into my unit test framework by using the following m4 macro described at https://www.gnu.org/software/autoconf-archive/ax_valgrind_check.html. In my configure.ac I have
AC_CONFIG_MACRO_DIR([m4])
...
AX_VALGRIND_DFLT()
AX_VALGRIND_CHECK
I have placed the .m4 script provided, in both ./m4 and in /usr/share/aclocal. To generate the configure script etc, I run the following:
aclocal && autoconf && autoreconf --no-recursive --install && \
autoheader && libtoolize --force && automake --force-missing \
--add-missing
However when I go an run ./configure I get the following error
./configure: line 12914: syntax error near unexpected token `AX_VALGRIND_CHECK'
./configure: line 12914: `AX_VALGRIND_CHECK'
What do I need to do to get my configure script to work with the macros provided by the .m4 script above. I am not sure what other information to provide.
Below is my configure.ac. I will try to find at which point things break using this configure.ac vs the one generated by autoreconf -i as posted by #Kusalananda.
AC_INIT([binary_balanced], [0.1], [mehoggan#gmail.com])
AM_INIT_AUTOMAKE([-Wall -Werror foreign subdir-objects])
AC_CONFIG_SRCDIR([./src/])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_MACRO_DIR([m4])
AC_PROG_CC
AM_PROG_AR
AM_PATH_CHECK
LT_INIT
# Checks for programs.
AC_PROG_CC
# Checks for libraries.
AX_VALGRIND_DFLT()
AX_VALGRIND_CHECK
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
AC_CONFIG_FILES([Makefile
src/Makefile
tests/Makefile])
AC_OUTPUT
I can not re-create your problem.
I also very seldom run anything other than autoreconf -i. This will re-run the other autotools as needed.
I put the ax_valgrind_check.m4 into a ./m4 directory and created a stub configure.ac:
AC_PREREQ([2.69])
AC_INIT([test],[0.0.0-dev])
AM_INIT_AUTOMAKE([foreign])
AC_CONFIG_MACRO_DIR([m4])
AX_VALGRIND_DFLT()
AX_VALGRIND_CHECK
Running autoreconf -i creates a configure script that does the following:
$ ./configure
checking for a BSD-compatible install... /Users/kk/sw/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /Users/kk/sw/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for valgrind... no
So the macros are picked up (which they weren't in your case).
So, run autoreconf -i to see if that sorts things out for you.
If you can't get this to work, try installing the autoconf-archive package for whatever Unix you're on. It will also contain this macro.
I am trying to copy a directory using a CMake script.
execute_process(COMMAND ${CMAKE_COMMAND} -E tar czf "${name}.orig.tar.gz" "${folder}"
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/Debian)
but it is throwing an error.
CMake Error: archive_write_header: Can't translate pathname 'files/osgModels/textures/índice.jpeg' to UTF-8
Now I end up with an archive which doesn't contain all the files.
However I can successfully create the archive when running tar independently, i.e. not using CMake.
I think you're seeing this CMake bug which was resolved after version 2.8.12.2. I'm not sure whether the fix made it into 3.0.0 or if it was 3.0.1, but either way, if you update CMake to the current version, you should see the problem disappear.
(I expect the í character of índice is the problem here)
I am trying to install the pdfgrep command line utility on a Windows Server 2008 R2 from this sources unfortunaly, I had no idea about what to do with those source files after download it so i seach on stackoverflow related problem and i found a ticket who tell to install cygwin, I have done that but when I make the ./configure, it doesn't work, here are the output I get:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... no
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether the C++ compiler works... no
configure: error: in `/home/Administrateur/pdfgrep-1.2':
configure: error: C++ compiler cannot create executables
See `config.log' for more details.
So what I still have to install for this to work ?
I know the user found a solution but I didn't have the option of installing Cygwin (for reasons...) and i found a simple solution.
Note: I am running windows 10, so this might not work for Windows below 7.
All you need to do is extract the folder and then go to DOS or command prompt.
There are two ways to go about it now.
Go to the folder itself and run it from there
cd C:\to\where\the\folder\is
pdfgrep -i keyword1|keyword2|etc C:\wherever\the\file\is.pdf
OR
2. run code directly from where ever you are in command prompt
C:\to\where\the\folder\is\pdfgrep -i keyword1|keyword2|etc C:\wherever\the\file\is.pdf
the -i is ignore case (one of pdfgrep options).
Hopefully this helps out other people
Sorry for the useless question, I found it by myself, I just rerun cygwin installer and select a c++ compile before reinstall