How to debug cmake - debugging

I am trying to figure out why configure step for Qt6.4 on MacOS fails.
As investigating logs and googling leads nowhere I started to debug underlying cmake.
Now I am in function that looks like:
function(qt_evaluate_to_boolean expressionVar)
if(${${expressionVar}})
set(${expressionVar} ON PARENT_SCOPE)
else()
set(${expressionVar} OFF PARENT_SCOPE)
endif()
endfunction()
Where expressionVar is TEST_openssl_headers.
The result of this operation is FALSE. I need to know why.
In the logs there is no TEST_openssl_headers, so apparently the test compilation is not even called.
Why? How can I know what happens at the "if" line? Where it calls? How does it evaluate if it is true?

Related

Goland ssh debug mode fail: executable doesn't containt debug information

I use Goland ssh to write code. I fail to use debug mode in my project, the breakpoints turn into gray crossed circles and report error "executable doesn't containt debug information".
The error information is here.
This is the Run/Debug Configuration of my project
However, I still could use debug mode and set normal breakpoints in Testing file.
I met exactly the same problem just now.
Finally I find the reason is the function which I set breakpoint doesn't been called in the repo.
It's called by another repo, so compile and debug the repo that call this function can solve this problem.
The error "error layer=debugger error loading binary "/lib/x86_64-linux-gnu/libpthread.so.0": could not parse .eh_frame section: pointer encoding not supported 0x9b at 0x12e8" still exists, but the breakpoints won't turn into gray crossed circles.
please see this https://youtrack.jetbrains.com/issue/GO-13005 .
Next 2022.2 nightly build bundles delve which doesn't produce an error.

How can I specify a minimum compute capability to the mexcuda compiler to compile a mexfunction?

I have a CUDA project in a .cu file that I would like to compile to a .mex file using mexcuda. Because my code makes use of the 64-bit floating point atomic operation atomicAdd(double *, double), which is only supposed for GPU devices of compute capability 6.0 or higher, I need to specify this as a flag when I am compiling.
In my standard IDE, this works fine, but when compiling with mexcuda, this is not working as I would like. In this post on MathWorks, it was suggested to use the following command (edited from the comment by Joss Knight):
mexcuda('-v', 'mexGPUExample.cu', 'NVCCFLAGS=-gencode=arch=compute_60,code=sm_60')
but when I use this command on my file, the verbose option spits out the following line last:
Building with 'NVIDIA CUDA Compiler'.
nvcc -c --compiler-options=/Zp8,/GR,/W3,/EHs,/nologo,/MD -
gencode=arch=compute_30,code=sm_30 -gencode=arch=compute_50,code=sm_50 -
gencode=arch=compute_60,code=sm_60 -
gencode=arch=compute_70,code=\"sm_70,compute_70\"
(and so on), which signals to me that the specified flag was not passed to the nvcc properly. And indeed, compilation fails with the following error:
C:/path/mexGPUExample.cu(35): error: no instance of overloaded function "atomicAdd" matches
the argument list. Argument types are: (double *, double)
The only other post I could find on this topic was this post on SO, but it is almost three years old and seemed to me more like a workaround - one which I do not understand even after some research, otherwise I would have tried it - rather than a true solution to the problem.
Is there a setting I missed, or can this simply not be done without a workaround?
I was able to work my way around this problem after some messing around with the standard xml-files in the MatLab folder. The following steps allowed me to compile using -mexcuda:
-1) Go to the folder C:\Program Files\MATLAB\-version-\toolbox\distcomp\gpu\extern\src\mex\win64, which contains xml-files for different versions of msvcpp;
-2) Make a backup of the file that corresponds to the version you are using. In my case, I made a copy of the file nvcc_msvcpp2017 and named it nvcc_msvcpp2017_old, to always have the original.
-3) Open nvcc_msvcppYEAR with notepad, and scroll to the following block of lines:
COMPILER="nvcc"
COMPFLAGS="--compiler-options=/Zp8,/GR,/W3,/EHs,/nologo,/MD $ARCHFLAGS"
ARCHFLAGS="-gencode=arch=compute_30,code=sm_30 -gencode=arch=compute_50,code=sm_50 -gencode=arch=compute_60,code=sm_60 -gencode=arch=compute_70,code=\"sm_70,compute_70\" $NVCC_FLAGS"
COMPDEFINES="--compiler-options=/D_CRT_SECURE_NO_DEPRECATE,/D_SCL_SECURE_NO_DEPRECATE,/D_SECURE_SCL=0,$MATLABMEX"
MATLABMEX="/DMATLAB_MEX_FILE"
OPTIMFLAGS="--compiler-options=/O2,/Oy-,/DNDEBUG"
INCLUDE="-I"$MATLABROOT\extern\include" -I"$MATLABROOT\simulink\include""
DEBUGFLAGS="--compiler-options=/Z7"
-4) Remove the architectures that will not allow your code to compile, i.e. all the architecture flags below 60 in my case:
ARCHFLAGS="-gencode=arch=compute_60,code=sm_60 -gencode=arch=compute_70,code=\"sm_70,compute_70\" $NVCC_FLAGS"
-5) I was able to compile using mexcuda after this. You do not need to specify any architecture flags in the mexcuda call.
-6) (optional) I suppose you want to revert this change after you are done with the project that required you to make this change, if you want to ensure maximum portability of the code you will compile after this.
Note: you will need administrator permission to make these changes.

Code::Blocks debugger shows some other path which isn't included in the project

I'm trying to use code::blocks debugger. I followed this basic tutorial on how to do it. I also watched two videos on you tube. I was actually trying it on a bigger file which had its declaration & implementation in separate files (one was header file tree.h, one had its implementation tree.cpp & the last one had implementation_tree.cpp main function to check the header file) but it didn't work so I tried it on a very simple program. But now debugger shows this error
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: F:\Coding\test\test\
Adding source dir: F:\Coding\test\test\
Adding file: F:\Coding\test\test\bin\Debug\test.exe
Changing directory to: F:/Coding/test/test/.
Set variable: PATH=.;C:\Program Files\CodeBlocks\bin;C:\Program Files\CodeBlocks;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0
[debug]Command-line: F:\Coding\Data Structures\tree.h -nx -fullname -quiet -args F:/Coding/test/test/bin/Debug/test.exe
[debug]Working dir : F:\Coding\test\test
Starting debugger: F:\Coding\Data Structures\tree.h -nx -fullname -quiet -args F:/Coding/test/test/bin/Debug/test.exe
failed
Whatever is in this line [debug]Command-line: is the address of my tree.h file which I was trying to debug earlier. But now I've removed all the breakpoints & everything related to that file from Code::Blocks & even changed that file's location but it still shows that same address in Starting debugger:. I've also rebuilt my test program after deleting everything related to it several times but I'm still getting the same error. I'm using GDB.
I'm so sorry if this question sounds very silly as I'm trying this for the first time & not being able to proceed through any tutorials or any other forum or anything else. I've also seen other related questions on stackoverflow but none of them works for me. So, please help. Thanks.
Settings -> Compiler -> Search Directories.. Delete all paths from there.

How do I get GDB to break on a GLib assertion failure?

Somewhere in a mass of code that I did not write (but I am trying to debug), an assertion fails in the GLib library:
(process:31987): GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed
However, GDB and the code keeps on going. I would like GDB to break where this assertion fails so that I can find out why it is failing. I am not given any more information about where this assertion is. Is there a way to get GDB to break on such a failure?
You should add an environment variable like this:
G_DEBUG=fatal_warnings gdb ...
Break on g_log(). This covers all cases like g_warning(), g_critical(), etc.

What could cause the error message 'Target "1" does not exist in the project "xxx".' running Ant on Windows?

I'm using ant.bat (in Ant 1.7.1) to build the all target in a build.xml file, on Windows 2003 Server. (I've substituted "xxx" in the error message for the project name in that file.)
It builds successfully, but then ends with:
2009-06-10 17:26:03 | all:
2009-06-10 17:26:03 |
2009-06-10 17:26:03 | BUILD FAILED
2009-06-10 17:26:03 | Target "1" does not exist in the project "xxx".
...and returns with a non-zero error code.
I've searched build.xml unsuccessfully for anything that might lead to this error. (There is no target "1", of course, nor any dependencies that might resolve "1".)
I'm hoping someone out there might recall seeing this. I don't expect anyone to debug the XML for me, but a Google search turned up http://simile.mit.edu/mail/ReadMsg?listId=9&msgId=2735, which contains "I found an email thread on this problem and will
retry.". I wish I could find that thread.
Update - here's the command-line:
D:/build/toolchain/noarch/ant-1.7.1/bin/ant.bat all -DBRANCH_NAME="main" -DBUILD_NUMBER="66675" -DCHANGE_NUMBER="1061789" -DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1 -DGOBUILD_VICLIB_ROOT=d:/build/ob/bora-66675/compcache//viclib/ob-65655/windows -DGOBUILD_VIMBASE_ROOT=d:/build/ob/bora-66675/compcache//vimbase/ob-64494/windows -DOBJDIR="beta" -DPRODUCT_BUILD_NUMBER="82" -DPUBLISH_DIR="d:/build/ob/bora-66675/publish" -DRELTYPE="beta" -DREMOTE_COPY_SCRIPT="D:/build/toolchain/win32/python-2.5/python.exe D:/build/gobuild/script/gobuildc.py bora-66675"'
Hopefully it's of some help.
Do you have any targets that depend on "1"? Perhaps due to a typo?
<target name="SomeTarget" depends="1">
....
</target>
Update: You explained (paraphrased) that the error message was a result of the (partial) command-line
-DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1
Although there's a space between those two define statements, it's being treated like this:
-DGOBUILD_AUTO_COMPONENTS=-DGOBUILD_OFFICIAL_BUILD=1
because something is expected to follow '='. And it appears that the second '=' is being treated as a whitespace, perhaps because ANT is confused. I would not expect that. The correct way to do what you want to do is:
-DGOBUILD_AUTO_COMPONENTS="" -DGOBUILD_OFFICIAL_BUILD=1
That way, something follows the equals sign and ANT won't get confused.
could you add the commandline you are using. it could be that ant agrees with you that there is no target '1' but that it believes you are passing one in.
This posting helped me resolve this error and wanted to share my version of the problem.
Target "listener" does not exist in the project "null".
ANT will use an environment variable ANT_ARGS if it is set. I was using the -listener option and set this option in my Windows envvar, ANT_ARGS. When I pasted the options into the Env Var:
-listener org.apache.tools.ant.listener.Log4jListener -lib D:\apache-ant-1.7.1\lib
I was missing the 'minus' sign in front of the 'listener' option.
This is similar to the problem above, but was hidden by the fact that I used the envvar ANT_ARGS.
Ya goose :-) You changed the project to "xxx" in the heading but left it as "vireporting" in the error output.
So the cat's out of the bag. You may as well make our life easier and post the XML since our ability to help you (psychic debugging) is greatly limited. If you want, sanitize the XML you post (better than you sanitized the original, hopefully).
And your comment ('There is no target "1"') makes sense since that's what ant is telling you. What you may have done is inadvertently created a dependency on that non-existent target.
It turns out this error message is the result of "-DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1" in the command-line. I guess having nothing after the '=' in that -D option confuses Ant. (As an experiment, I changed "-DGOBUILD_OFFICIAL_BUILD=1" to "-DGOBUILD_OFFICIAL_BUILD=2" in this programmatically-generated command-line and the error message changed to "Target "2" does not exist in the project "xxx".")
Removing "-DGOBUILD_AUTO_COMPONENTS=" eliminated the build failure.
If someone can clearly explain why Ant emits such a strange error message in this case (or perhaps why it's not strange if one looks at it correctly), I'll accept your answer.

Resources