Well, the title pretty much says it all. I start up Qt Creator, I create a new project and click the plain C++ option. It creates the following code in the main.cpp file:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World!" << endl;
return 0;
}
I put a breakpoint on the line beginning with cout or return.
I set the project mode to debug.
I click the play button with the bug on it.
It doesn't stop at the breakpoint.
If I do the exact same thing but having created a Qt GUI Application, it works.
Help'd be much appreciated.
Thank you.
Oh yeah, if it makes any difference, I'm using the latest version of Linux Mint and from what I can tell, GCC and GDB are installed.
Edit: Here is the:
Compile Output:
23:27:37: Running build steps for project untitled2...
23:27:37: Starting: "/usr/bin/qmake-qt4" '/home/jean-luc/Desktop/untitled folder/untitled2/untitled2.pro' -r -spec linux-g++ CONFIG+=debug CONFIG+=declarative_debug
23:27:37: The process "/usr/bin/qmake-qt4" exited normally.
23:27:37: Starting: "/usr/bin/make" -w
make: Entering directory `/home/jean-luc/Desktop/untitled folder/untitled2-build-desktop-Qt_4_8_1_in_PATH__System__Debug'
g++ -c -pipe -g -Wall -W -DQT_WEBKIT -I/usr/share/qt4/mkspecs/linux-g++ -I../untitled2 -I../untitled2 -I. -o main.o ../untitled2/main.cpp
g++ -o untitled2 main.o
{ test -n "" && DESTDIR="" || DESTDIR=.; } && test $(gdb --version | sed -e 's,[^0-9]\+\([0-9]\)\.\([0-9]\).*,\1\2,;q') -gt 72 && gdb --nx --batch --quiet -ex 'set confirm off' -ex "save gdb-index $DESTDIR" -ex quit 'untitled2' && test -f untitled2.gdb-index && objcopy --add-section '.gdb_index=untitled2.gdb-index' --set-section-flags '.gdb_index=readonly' 'untitled2' 'untitled2' && rm -f untitled2.gdb-index || true
make: Leaving directory `/home/jean-luc/Desktop/untitled folder/untitled2-build-desktop-Qt_4_8_1_in_PATH__System__Debug'
23:27:38: The process "/usr/bin/make" exited normally.
Application Output:
Debugging starts
Debugging has finished
Even though this is already a few days old, I'd like to add this resolution, as the problem described occasionally happens with Qt and Creator: Qt Creator has the nasty habit to suggest having the release and the debug objects in the same folder. So if you compile a release build, then decide to debug your program and make a debug build, it will link a debug application with release objects.
These objects cannot have a breakpoint set into. You need to clean the project completely, call qmake and make all in debug mode. Then you should be able to set breakpoints properly.
You can simply give cmake command cmake -DCMAKE_BUILD_TYPE=Debug
or
SET(CMAKE_BUILD_TYPE Debug) add this line to CMakeLists.txt and debug now. Breakpoints will get hit properly.
Related
I am facing issues with a make command. I am compiling Scilab on RHEL for ppc64. The ./configure went well, now when I did make all, I have an issue when compiling the module umfpack. I can reproduce this error by entering the modules/umfpack folder, and by typing there make all. This is the output:
enter[root#rhel70-misurio umfpack]# /bin/sh ../../libtool --tag=CC --mode=link gcc -D_LARGEFILE64_SOURCE -DNDEBUG -fno-stack-protector -g -O2 -version-number 5:5:1 -Wl,--no-as-needed -o libsciumfpack.la -rpath /usr/local/lib/scilab sci_gateway/c/libsciumfpack_la-gw_umfpack.lo sci_gateway/c/libsciumfpack_la-sci_res_with_prec.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chdel.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chfact.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chget.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chinfo.lo sci_gateway/c/libsciumfpack_la-sci_taucs_chsolve.lo sci_gateway/c/libsciumfpack_la-sci_umf_ludel.lo sci_gateway/c/libsciumfpack_la-sci_umf_lufact.lo sci_gateway/c/libsciumfpack_la-sci_umf_luget.lo sci_gateway/c/libsciumfpack_la-sci_umf_luinfo.lo sci_gateway/c/libsciumfpack_la-sci_umf_lusolve.lo sci_gateway/c/libsciumfpack_la-sci_umfpack.lo libsciumfpack-algo.la -L-lumfpack -lsuitesparseconfig -lumfpack -lpthread -ldl -lcurses -lm
../../libtool: line 6000: cd: -l: invalid option
cd: usage: cd [-L|[-P [-e]]] [dir]
libtool: link: cannot determine absolute directory name of `-lumfpack'
So it is apparent that somewhere the code is doing "cd -"something. But where...? this is folder where I am.
[root#rhel70-hostname umfpack]# ls
etc libsciumfpack-algo.la make_all_log sci_gateway umfpack.iss
examples license.txt Makefile src UMFPACK_license.txt
help locales Makefile.am TAUCS_license.txt
includes macros Makefile.in tests
Which are the candidates, in your opinion, where I have to investigate where the mistake is? What would you do in my place to debug?
Thanks!
Many thanks for your suggestions! I went into the libtool file and indeed I found that at line 6'000 there was this line of code:
absdir=`cd "$dir" && pwd`
test -z "$absdir" && \
func_fatal_error "cannot determine absolute directory name of \`$dir'"
And I realised that it was doing "cd -lumfpack" in the script. That was an input I had given to the ./configure script, in which I had to explicitly provide the libumfpack and libsuitesparseparseconfig as an option, since it was using other libraries by default. In that option, I had given:
--with-umfpack-library="-lumfpack -lsuitesparseconfig"
so then make was doing "cd -lumfpack". So I thought about providing the absolute path of both libraries! So I gave as input:
--with-umfpack-library="/usr/local/lib/libumfpack.a /usr/local/lib/libsuitesparseconfig.a"
And it successfully ran the configure script and the make.
Another "solution" would have been to remove the umfpack libraries altogether with the option to the configure script:
--without-umfpack
Hope it helps future programmers compiling Scilab!
Honestly, I think another way could have been feasible, that is specifiying the libumfpack and libsuitesparseconfig libraries in the configure script directly, but I didn't have time then to investigate this. If I will do, I will update this post.
I got the below makefile which works perfectly fine under linux as well as mac os. However it fails to do anything on FreeBSD, and I have no clue why. It gives the following output:
19:31:35 user#host:~/libhttp++/src> make
-
Making HTTP++ library..
make[1]: don't know how to make obj/libhttp++.a. Stop
make[1]: stopped in /usr/home/user/libhttp++/src/obj
*** Error code 2
Stop.
make: stopped in /usr/home/user/libhttp++/src
I also tried gmake, which gives the following output:
19:31:35 user#host:~/libhttp++/src> gmake
-
Making HTTP++ library..
Building Lib ...
ar -rs obj/libhttp++.a obj/html.o obj/http.o obj/object.o
ar: warning: creating obj/libhttp++.a
ar: warning: can't open file: obj/html.o: No such file or directory
ar: warning: can't open file: obj/http.o: No such file or directory
ar: warning: can't open file: obj/object.o: No such file or directory
ar: fatal: Failed to open 'obj/libhttp++.a'
*** Error code 70
Stop.
make[1]: stopped in /usr/home/user/libhttp++/src
gmake: *** [all] Error 1
One issue might be that i'm trying to keep all intermediate object files as well as the lib itself in a separate subdirectory ("obj").
The problem is, I dont know much about makefiles, and the freebsd handbook as well as any example makefiles i could find via google did not help much. The makefile is basically copied from a working linux makefile I found somewhere, and well, it works on linux and mac os. Is there a way to convert it to a format which works on all 3 platforms? any help would be much appreciated.
makefile:
#--------------------------------------------------------------------------
# defines
#--------------------------------------------------------------------------
LIBDIR = ../lib
INCDIR = ../include
OBJDIR = obj
CXX = g++
doLib = ar -rs
doCompile = $(CXX) $(CXXFLAGS)
doLink = $(CXX) $(LFLAGS)
doClean = rm -f *.o *~ *.a
#--------------------------------------------------------------------------
# Library
#--------------------------------------------------------------------------
OBJECTS = $(OBJDIR)/html.o \
$(OBJDIR)/http.o \
$(OBJDIR)/object.o
LIBXMLPATH=~/Development/libxml2_2
LIBCURLPATH=~/Development/libcurl
#CDEF += -D__FORIOS__
CXXFLAGS ?= -I ./ -I $(LIBXMLPATH)/include -I $(LIBCURLPATH)/include/curl $(CDEF) -c -ggdb -Wreturn-type -Wformat -pedantic -Wunused-variable -Wunused-label -Wunused-value -Wno-long-long
DISTLIB = http++
#--------------------------------------------------------------------------
# compile lib objects
#--------------------------------------------------------------------------
lib: all
all:
#(echo -; echo Making HTTP++ library..; make $(OBJDIR)/lib$(DISTLIB).a)
$(OBJDIR)/lib$(DISTLIB).a: $(OBJECTS)
#echo Building Lib ...
$(doLib) $# $(OBJECTS)
clean:
#(echo Cleanup HTTP++ library)
$(doClean)
(cd $(OBJDIR); $(doClean))
install:
#(echo Installing HTTP++ library in ../include ../lib)
(mkdir -p $(LIBDIR); mkdir -p $(INCDIR))
(cp -p *hpp *h $(INCDIR)/ ; cp -p $(OBJDIR)/lib$(DISTLIB).a $(LIBDIR)/)
#--------------------------------------------------------------------------
# Compiler Call
#--------------------------------------------------------------------------
$(OBJDIR)/%.o: %.cc
#echo Compile "$(*F)" ...
$(doCompile) $(*F).cc -o $#
#--------------------------------------------------------------------------
# dependencies
#--------------------------------------------------------------------------
CHECK = def.h
$(OBJDIR)/html.o : html.cc $(CHECK) html.hpp
$(OBJDIR)/http.o : http.cc $(CHECK) http.hpp
$(OBJDIR)/object.o : object.cc $(CHECK) object.hp
GNU make has a number of extensions beyond the make on BSDs (which is sometimes available on non-BSD boxes as bsdmake). You can look at the FreeBSD man page for make to see the differences, but the most salient one is that the syntax
%.target: %.source
is only available on GNU make (there's a similar syntax, though less flexible, in BSD make).
I'd have thought that gmake would work, though. Hmm...
Looking at the makefile, I can't see anything that creates $(OBJDIR), so it might be that that's the problem – it's the first thing I'd try to fix, at any rate. If so, then just mkdir obj beforehand might work.
Yesterday I found the problem:
all:
#(echo -; echo Making HTTP++ library..; make $(OBJDIR)/lib$(DISTLIB).a)
This line is bad when the makefile is used with gmake, because it calls make instead of gmake. So the fix is:
all:
#(echo -; echo Making HTTP++ library..; gmake $(OBJDIR)/lib$(DISTLIB).a)
Now it works perfectly without any adjustments when using gmake.
I am having problems getting any kernel modules to build on my machine. Whenever I build a module, modpost always says there are zero modules:
MODPOST 0 modules
To troubleshoot the problem, I wrote a test module (hello.c):
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
#include <linux/init.h> /* Needed for the macros */
static int __init hello_start(void)
{
printk(KERN_INFO "Loading hello module...\n");
printk(KERN_INFO "Hello world\n");
return 0;
}
static void __exit hello_end(void)
{
printk(KERN_INFO "Goodbye Mr.\n");
}
module_init(hello_start);
module_exit(hello_end);
Here is the Makefile for the module:
obj-m = hello.o
KVERSION = $(shell uname -r)
all:
make -C /lib/modules/$(KVERSION)/build M=$(shell pwd) modules
clean:
make -C /lib/modules/$(KVERSION)/build M=$(shell pwd) clean
When I build it on my machine, I get the following output:
make -C /lib/modules/2.6.32-27-generic/build M=/home/waffleman/tmp/mod-test modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-27-generic'
CC [M] /home/waffleman/tmp/mod-test/hello.o
Building modules, stage 2.
MODPOST 0 modules
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-27-generic'
When I make the module on another machine, it is successful:
make -C /lib/modules/2.6.24-27-generic/build M=/home/somedude/tmp/mod-test modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.24-27-generic'
CC [M] /home/somedude/tmp/mod-test/hello.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/somedude/tmp/mod-test/hello.mod.o
LD [M] /home/somedude/tmp/mod-test/hello.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.24-27-generic'
I looked for any relevant documentation about modpost, but found little. Anyone know how modpost decides what to build? Is there an environment that I am possibly missing?
BTW here is what I am running:
uname -a
Linux waffleman-desktop 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux
Edit
Here is make ran with V=1:
make -C /lib/modules/2.6.32-27-generic/build M=/home/waffleman/tmp/mod-test modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-27-generic'
test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/linux/autoconf.h or include/config/auto.conf are missing."; \
echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo; \
/bin/false)
mkdir -p /home/waffleman/tmp/mod-test/.tmp_versions ; rm -f /home/waffleman/tmp/mod-test/.tmp_versions/*
make -f scripts/Makefile.build obj=/home/waffleman/tmp/mod-test
gcc -Wp,-MD,/home/waffleman/tmp/mod-test/.hello.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.4.3/include -Iinclude -I/usr/src/linux-headers-2.6.32-27-generic/arch/x86/include -include include/linux/autoconf.h -Iubuntu/include -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i586 -mtune=generic -maccumulate-outgoing-args -Wa,-mtune=generic32 -ffreestanding -fstack-protector -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-larger-than=1024 -fno-omit-frame-pointer -fno-optimize-sibling-calls -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-dwarf2-cfi-asm -fconserve-stack -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hello)" -D"KBUILD_MODNAME=KBUILD_STR(hello)" -c -o /home/waffleman/tmp/mod-test/.tmp_hello.o /home/waffleman/tmp/mod-test/hello.c
set -e ; perl /usr/src/linux-headers-2.6.32-27-generic/scripts/recordmcount.pl "i386" "32" "objdump" "objcopy" "gcc" "ld" "nm" "" "" "1" "/home/waffleman/tmp/mod-test/hello.o";
(cat /dev/null; echo kernel//home/waffleman/tmp/mod-test/hello.ko;) > /home/waffleman/tmp/mod-test/modules.order
make -f /usr/src/linux-headers-2.6.32-27-generic/scripts/Makefile.modpost
scripts/mod/modpost -m -a -i /usr/src/linux-headers-2.6.32-27-generic/Module.symvers -I /home/waffleman/tmp/mod-test/Module.symvers -o /home/waffleman/tmp/mod-test/Module.symvers -S -w -s
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-27-generic'
waffleman#waffleman-desktop:~/tmp/mod-test$ cat /home/waffleman/tmp/mod-test/modules.order
kernel//home/waffleman/tmp/mod-test/hello.ko
I spent all day glued to my computer fighting this precise problem..which ended up mysteriously disappearing like for OP.
I can at least offer this meager detail from my experience: I was getting the same output as OP (for make V=1) and putting print statements in ${kernel_directory}/scripts/makefile.build showed that obj-m was strangely NOT being set after including my makefile, even though it was clearly typed as above.
I did a bunch of fooling around with the line "obj-m += hello.o" and the ones around it. Eventually it magically worked..although it looked exactly the same as before in the end. Maybe I had copied those lines from a tutorial online and it contained some sort of invalid/incorrect character?
For anyone experiencing this, verify that obj-m is in fact getting set to hello.o
If it mysteriously isn't, delete the line, hell the whole Makefile, and retype it.
I know that's not much help; I wish I could reproduce what happened!
In another thread I found that when I copy pasted the makefile contents, the -C after make was using the wrong "-" symbol and I had to re type it. It just so happens that this is the case for the obj-m += ... line above. You need to retype that character to make it valid. This should hopefully be found by anyone following the hello world module tutorial.
I guess you copied the contents of the Makefile from a PDF or some HTML document. The hyphens used are somewhat weird. Just try replacing the hyphens in the makefile; it will work like a charm.
I just ran into this same problem and for me it was caused by changing the default grep options via the GREP_OPTIONS environment variable. I didn't dig into the details, but something in the module build process didn't like my alternate grep output (include file name and line number). Removing the GREP_OPTIONS environment variable fixed things right up.
This happens because when you copy the make file contents from the PDF or any other tutorial websites and use it as it is. While you do a copy-paste, the contents will appear a bit weird in Linux environment. ie; Some special character issues will be there. If you retype the contents in Linux environment and do a make, this should work.
On the machine that fails does your .config have module support disabled?
Try doing "make menuconfig" and make sure module support is enabled.
I can only guess your kernel build environment is botched, because it passes both the theoretical check (the look of the developer) as well as the practical test:
make -C /lib/modules/2.6.36-rc8-32-desktop/build M=/dev/shm modules
make[1]: Entering directory `/usr/src/linux-2.6.36-rc8-32-obj/x86_64/desktop'
make -C ../../../linux-2.6.36-rc8-32 O=/usr/src/linux-2.6.36-rc8-32-obj/x86_64/desktop/. modules
CC [M] /dev/shm/hello.o
Building modules, stage 2.
MODPOST 1 modules
CC /dev/shm/hello.mod.o
LD [M] /dev/shm/hello.ko
make[1]: Leaving directory `/usr/src/linux-2.6.36-rc8-32-obj/x86_64/desktop'
The error mysteriously went away. If anyone has an idea what could cause this. I'd like to know in case there is a next time.
Try to remove modules string from the Makefile:
obj-m = hello.o
KVERSION = $(shell uname -r)
all:
make -C /lib/modules/$(KVERSION)/build M=$(shell pwd) # <--
clean:
make -C /lib/modules/$(KVERSION)/build M=$(shell pwd) clean
I was able to solve this problem by putting the
obj-m += <module name>.o
In a separate file named Kbuild. See Linux/documentation/kbuild/modules.txt for a hint as to why this might work
I had the same problem. Finally, I rebuilt the kernel, rewrote the makefile. It worked finally.
I guess the main reason is because I had M=$(PWD) modules in the following line right after make ARCH=arm...
I solved this problem by correcting Makefile, i.e.:
obj-m := modulename.o
I think it's not about special characters. I couldn't solve even when I manually typed! Then I tried again using kate text editor because previously I used nano and this time it worked like charm by even simple copy and paste. Because of that, I think the issue is the text editor
I compile this program:
#include <stdio.h>
int main()
{
printf("Hello World!");
return 0;
}
With this command:
gcc -c "hello.c" -o hello
And when I try to execute hello, I get
bash: ./hello: Permission denied
Because the permissions are
-rw-r--r-- 1 nathan nathan 856 2010-09-17 23:49 hello
For some reason??
But whatever... after changing the permissions and trying to execute again, I get
bash: ./hello: cannot execute binary file
I'm using gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
What am I doing wrong here? It's gotta be obvious... it's just too late for me to keep using my tired eyes to try and figure out this simple problem....
P.S. I do (sometimes) work on programs more sophisticated than Hello World, but gcc is doing this across the board...
Take the -c out. That's for making object files, not executables.
The -c flag tells it not to link, so you have an object file, not a binary executable.
In fact, if you ran this without the -o flag, you would find that the default output file would be hello.o.
For reference (and giggles), the man entry on the -c flag:
-c Compile or assemble the source files, but do not link. The linking stage simply is not done.
The ultimate output is in the form of an object file for each source file.
By default, the object file name for a source file is made by replacing the suffix .c, .i, .s,
etc., with .o.
Unrecognized input files, not requiring compilation or assembly, are ignored.
Compile with: gcc hello.c -o hello
I read the tutorial which advises me to run at util-linux package
./configure
I get
configuring util-linux-2.12q
You don't have <scsi/scsi.h>
You don't have <linux/blkpg.h>
You don't have <linux/kd.h>
You have <locale.h>You have <langinfo.h>
You have <sys/user.h>
You have <uuid/uuid.h>
You have <rpcsvc/nfs_prot.h>
You don't have <asm/types.h>
You don't have <linux/raw.h>
You have <stdint.h>
You don't have <sys/io.h>
You have inet_aton()
You have fsync()
You have getdomainname()
You have nanosleep()
You don't have personality()
You don't have updwtmp()
You have fseeko()
You have lchown()
You don't have rpmatch()
You have <term.h>
You have ncurses. Using <ncurses.h>.
You have termcap
You don't need -lcrypt
Strange... Static compilation fails here.
You don't have native language support
You have __progname
You don't have <pty.h> and openpty()
You have wide character support
You don't have SYS_pivot_root
You have a tm_gmtoff field in struct tm
Your rpcgen output does not compile - using pregenerated code
You have zlib
You don't have blkid
It then advises me to run the following command at misc-utils
make rename
I get the following warning
cc -pipe -O2 -mtune=i386 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1 -D_FILE_OFFSET_BITS=64 -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" -O2 -s rename.c -o rename
ld warning: option -s is obsolete and being ignored
How can you install rename -command for Mac?
That's a warning, not an error.
I've just tried this myself and it has built a rename executable.
Easily install rename using Homebrew
brew install rename
Do compile rename from linux. There are some minor differences to the indications in the tutorial. I used version 2.22 from the file util-linux-2.22.tar.gz
Download it and uncompress it. Go to the uncompressed folder in a terminal.
Don't just run ./configure, use this command with flags instead:
./configure --disable-su --disable-sulogin --disable-login
then from that very same folder, NOT changing into misc-utils, you do make rename
That's all, in the current folder you'll have the executable and in the misc-utils the man documentation if you need it.
Can you not just use mv instead of trying to compile rename? Maybe even alias it to rename?
(EDIT: Ignore my comment about build-essentials - as pointed out by yangyang, it looks like it should have built ok anyhow)
Try this:
function rename { from=$1; to=$2; shift 2; for i in "$#"; do j=`echo $i | sed "s/$from/$to/"`; mv "$i" "$j"; done }
Paste it into your .profile or .bashrc and run it just like the Red Hat rename utility:
$rename foo bar *.txt
Turns foo1.txt, foo2.txt and foofoo.txt into bar1.txt, bar2.txt but, somewhat irritatingly, barfoo.txt. Maybe someone can tweak it to fix this.
Test it by putting 'echo' before 'mv' so that it outputs a list of all changes it will make without making them.