and sorry for mess English.
In theory while debugging in qt-creator show fields of classes defined in Qt.
But it doesn't do it and display only or mem address.
I think that the problem in GDB or Python scripts.
GDB loaded from http://origin.releases.qt-project.org/gdb/ gives what is described above.
I tried to Build GDB myself with config flags
configure --prefix=<DIR> --target x86_64-linux-gnu --with-python
and
configure --target x86_64-linux-gnu --disable-nls --with-libiconv --with-expat --with-python
but they crash while starting from Qtcreator
i'm running on Ubuntu 12.10 x64
Qt version is 4.8.4 (from Git)
and creators are 2.5.2(from qt-project site) and 2.6.81 (git)
GDB versions:
build myself - 7.5
download from qt-project - 7.4.1
on Win8 subject works fine in combination QtCreator(2.6.81)-Qt-4.8.4-MinGW-GDB-7.5(build myself from source with Py. support)
UPD: Try to build with http://qt.gitorious.org/qt-creator/qt-creator/trees/master/dist/gdb
it didn’t help
SOLUTION: Qt libs didn't contain debug simbols. I was caught by flag -debug-and-release. It work in macOS and windows (MinGW) but not in Linux. Be careful!
Are you sure the version of Qt you use has been built with debug symbols? What does readelf -S /path/to/your/libQtCore.so say?
Related
I need to use tools that depend on clang on a Unix machine I remote onto at work. Anything I install is locally installed onto ~/local. I do not have root permissions.
/usr is pretty outdated, with gcc being at version 4.4.7. clang requires gcc 4.7+
I read on linux from scratch that a gcc 6.1 installation requires 8.4 gb. This is not something I can do, because that's huge.
Can someone advise me on the best workaround to install up to date clang on my ~/local?
Please and thanks.
Edit:
Courtesy of Nishant, here is the short answer:
Set up a personal machine running the same linux distro and cross compile using gcc to your specific architecture. For me, I will run a Redhat 6.5 VM and compile using gcc an arm x64 binary. Thanks Nishant!
You can get pre-build binaries for Unix system from LLVM's release website: http://llvm.org/releases/
You can then put the binaries in any local folder you want and source it using the PATH variable, which can be done by modifying your ~/.bashrc file by appending:
export PATH=$PATH:<clang-binary-directory>
Now you will able to use clang from the command line terminal as if it was installed.
If you want to build from source only, you can get older source code of clang which will use gcc 4.4.7 and build it and then use clang to build clang. Or get the latest clang binary and use it to build latest clang.
In Cygwin a search for g++ shows:
gcc-g++
mingw-gcc-g++
mingw64-x86_64-gcc-g++
What are the differences between these?
Binaries built with Cygwin's gcc-g++ link against cygwin1.dll which is an implementation of the POSIX API for Windows.
mingw64-x86_64-gcc-g++ is instead part of the Mingw-w64 toolchain which builds native Windows applications that do not depend on Cygwin. The mingw-gcc-g++ on your system is probably either a symlink to this, or is the version that produces 32-bit binaries.
You can verify this difference by inspecting the import tables of a "hello world" program built with each using objdump -x hello.exe.
I'm cross compiling wxWidgets using that tutorial. Could anyone explain me what --host=i586-mingw32msvc does?
I know that prefix give the information where cross-compiler is. However, I compiled minGW from source manually, because then I can use the newest GCC so I can't only copy&paste.
Prefix should be prefix=/usr/local/i386-mingw32 because there is my cross-compiler. And what about host?
I use Lubuntu 14.04 LTS AMD64 .
--host is a typical ./configure option that specifies the "host" system for the program to run on, i.e. the configuration that you will be compiling for.
In other words, --host activates cross-compiling behaviour if you specify a host that is not the same as your build machine.
The format of the host spec differs occasionally between platforms, but it generally takes the form
processorfamily-osfamily[-osversion][-abi]
I have a problem running QT 5.2.1 applications on linux embedded (all of them, even the simplest "hello world" exits with code 1).
I cross compiled QT 5.2.1 for a linux embedded device (TI AM335x) using the toolchain supplied by TI (SDK 6.00.00). I also added ICU support (because I am planning to cross-compile QtWebkit too and ICU is a required dependency).
So, I previously built ICU (version 52) and then I cross-compiled QT using the following configuration:
./configure -prefix /opt/qt5 -opensource -confirm-license -platform linux-g++
-icu -I /opt/icu/include -L /opt/icu/lib -R /opt/icu/lib -no-cups -no-nis
-no-dbus -no-pch -no-accessibility -no-gtkstyle -no-xcb -eglfs -no-directfb
-qpa eglfs-xplatform linux-arm-gnueabihf-g++ -opengl es2 -nomake examples
-nomake tests -v
(previously built ICU libraries reside in /opt/icu/lib).
QT was then compiled using make && make install, as usual.
Then I configured my QT Creator IDE on development machine (Ubuntu 12.04 LTS 32-bit) for compiling applications against the new QT version, just cross-compiled, using the same toolchain provided by TI (SDK 6.00.00).
Everything is fine: my console-based "hello, world" application is compiled and then I am able to deploy it to the device (setting all the requested environment variables required for letting QT find its own libraries).
BUT here comes the problem:
the application always exits with code 1 and produces no output.
If I strace my application, running strace -o trace.log ./TestConsole then it produces the output that you can find here.
In other words it seems that somebody is calling exit_group(1) just after having loaded libicudata.so.52.
But who is calling it? and why?
Please consider that if I cross-build QT without ICU support, then I can compile and run applications against it... So I think it is something ICU-related... Any ideas about that?
I found the problem: the problem is ICU-related.
I noticed that even the execution of the tool /opt/icu/bin/icuinfo on the target platform exits with 1 at startup (you can find the full strace log here).
A new ICU-related question has been published here, so I think that this question can be closed.
I've cross-compiled the bulk of my 32-bit code on my x64 Ubuntu install, but I can't work out how to do the same trick with libcurl.
I've tried many permutations of --host and/or --build i486, x86, etc. but none have helped. I've also tried editing the makefiles to include gcc's -m32 flag manually, but it never shows up when I run them.
What should I be doing?
After you download and extract the libcurl source package, as a root user, run this command for setting up the build environment.
configure --host=i686-pc-linux-gnu CFLAGS=-m32 CC=/usr/bin/gcc
followed by
make
you can find the libs under ./lib/.libs/libcurl.so from where you ran the make command.
if you dont find /usr/bin/gcc, you will have to install gcc for 32-bit cross compilation env in a 64-bit machine.
It would help if you gave us an error message. I've had issues on Ubuntu x64 systems compiling 32-bit code with 'ld' errors.. I solved it by adding LDEMULATION=elf_i386 to my environment.