Build JVMTI Agent with Qt/qmake - qt

After I successfully implemented my first JVMTI agent and the building completes with the g++ compiler I want to go over integrate the building process into my Qt project.
However I am facing some build process configuration issues:
The parameters I would run with the g++ compiler looks like this:
g++ -fPIC -shared agent.cpp -o libagent.so -I /usr/lib/jvm/java-6-openjdk/include -I /usr/lib/jvm/java-6-openjdk/include/linux
This works very well. Now to qmake:
I am aware of the parameter CXXFLAGS to add further parameters to the C++ compiler used by qmake, but how can I convert this parametrized compiler call into qmake?

With the help of Qt Undocumented qmake I figured out a custom configuration in qmake. However, it is not flawless, it produces now a libagent.so and a agent.o which is not needed.
SOURCES_AGENT = agent.cpp
agent.name = agent
agent.input = SOURCES_AGENT
agent.dependency_type = TYPE_C
agent.variable_out = OBJECTS
agent.output = libagent.so
agent.commands = $${QMAKE_CXX} $(CXXFLAGS) -fPIC -shared -o libagent.so $(INCPATH) ${QMAKE_FILE_IN}
QMAKE_EXTRA_COMPILERS += agent

I don't know the specific answer but...
As JVMTI agents are "usually" headless are you using qmake because your project has a head that you are developing in kdevelop/qtcreator? Is the head using the attach API?
If not and it is purely headless then would not a different editor/cmake be better? qmake is now a preproc for cmake, for the MOC stuff, no?
I must admit I'm a bit fuzzy on q/cmake although I'm hoping to move to cmake for my work.

Related

How do I use clang to compile for avr (arduino)

When I search I found 7yr old results talking about a fork of clang instead of clang itself.
Using avr-gcc I can compile and upload my code with
avr-gcc a.cpp -DF_CPU=16000000 -mmcu=atmega2560 -Wall -Werror -Wextra -Os
avr-objcopy -j .text -j .data -O ihex a.out my.hex
sudo avrdude -patmega2560 -cwiring -P/dev/ttyACM0 -b115200 -D -Uflash:w:my.hex:i
I'd like to replace the first step with clang++. The changes I made here
avr-gcc to clang++
Added --target=avr
Added -nostdlib because I'll include it myself
Added -I/usr/avr/include/ because path wasn't implicit
Added -L/usr/avr/lib/avr6 -lc -latmega2560 so it has enough info to build an elf
I found device-specs at /usr/lib/gcc/avr/10.2.0/device-specs/specs-atmega2560 which mentions crtatmega2560.o and -latmega2560 which appears to be located at /usr/avr/lib/avr6/. So I came up with the following and got these errors. How should I be compiling so I can get a hex to upload using avrdude?
$ clang++ a.cpp -DF_CPU=16000000 -mmcu=atmega2560 -Wall -Werror -Wextra -Os --target=avr -I/usr/avr/include/ -nostdlib -L/usr/avr/lib/avr6 -lc -latmega2560
/usr/bin/avr-ld: skipping incompatible /usr/avr/lib/avr6/libc.a when searching for -lc
/usr/bin/avr-ld: cannot find -lc
/usr/bin/avr-ld: skipping incompatible /usr/avr/lib/avr6/libatmega2560.a when searching for -latmega2560
/usr/bin/avr-ld: cannot find -latmega2560
AVR target is experimental in LLVM compiler for which clang is the C and C++ front-end. To enable experimental targets you must compile LLVM from source. This Stack Overflow answer describes how to do it.
Looking at the bug tracker I see there are good reasons why it is experimental.
I am not sure what to answer finally.
Probably it is not the worst idea to compile .o file with clang, and link everything manually just like you wish.
I am not sure, if it is needed to enable any experiment features, due I tried to compile something to AVR, and it works fine with clang-12 when I use llvm repository apt.llvm.org.

Linking webrtc with Qt on Windows

I'm trying to link libwebrtc library with Qt application on Windows platform.
I get a lot of linking errors like this:
webrtc.lib(jitter_estimator.obj):-1: error: LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in ....obj
Apparently this is because the libwebrtc is compiled with -MT (static runtime) buiflag, and Qt application is compiled with -MD flag.
Is it possible to make Qt application compile with -MT? Is it possible to make libwebrtc to compile with -MD ?
Summary of my investigations:
a) It is possible to compile libwebrtc with -MD flags. This is not possible without modifying the sources, but the modification is trivial:
change src/build/config/win/BUILD.gn: in the statement config("default_crt")
replace
#Desktop Windows: static CRT
configs = [":static_crt"]
to
configs = [":dynamic_crt"]
b) It is possible to recompile Qt from sources with -MT -MTd flags.
To do this: edit Src/qtbase/mkspecs/common/msvc-desktop.conf, replace -MD -MDd in this file with -MT -MTd.
configure with option -static.
Both solutions seems to work, at least produce compilable and linkable binaries.

qmake how to add extra flags

I am using qmake to cross-compile my ARM based program on Ubuntu. I have ran into the multithreading issue as described in this thread:
C++ 11 Threads, Error Pure virtual function called
One answer suggests adding the flag to the compilation as:
g++ -pthread -std=c++11 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4} thread1.cpp
I am not sure how to add this -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4} in my qmake project file.
I did QMAKE_CXXFLAGS += -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4}. My error still remains so I wanted to confirm if this is the right way to add that flag.
It's a bash glob/wildcard. Expands to
-D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4

How to include Qt's headers with -isystem (system headers) with qmake and qt5?

I compile my Qt5-based project with warnings enabled on g++:
# project.pro file
QMAKE_CXXFLAGS += -std=c++11 -Wall -Wextra -Wconversion -Weffc++
When compiling, Qt produces lots of warnings (1000+ with just one simple widget), hiding the warnings from my code.
How to tell qmake to use the -isystem switch when specifying the Qt's headers rather than -I to suppress the warnings? I don't want to turn warnings off I want to keep them for my code.
NOTE: I checked this SO question but it does not work in my case, it might be only for Qt4, I use Qt5.
NOTE 2: this is an acknowledged bug, I am looking for a workaround. I use a recent version of qmake compiled from sources 5.4.1, this version passes system headers from /include and /usr/include as system headers but not the Qt's headers.
NOTE 3: I know CMake would work but this is not an option for me.
I found two ways to suppress warnings from Qt's headers, one way by installing Qt in system's path (as suggested in the other answer) and the other directly from your pro file by using GCC flags.
When building your own Qt, configure the header's installation path to one of your system path:
$ ./configure -headerdir /usr/local/include
System paths are /usr/include or /usr/local/include or one of the rest listed in:
$ grep DEFAULT_INCDIRS mkspecs/qconfig.pri
QMAKE_DEFAULT_INCDIRS = /usr/include/c++/4.8 /usr/include/x86_64-linux-gnu/c++/4.8 /usr/include/c++/4.8/backward /usr/lib/gcc/x86_64-linux-gnu/4.8/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed /usr/include/x86_64-linux-gnu /usr/include
Source: this thread in Qt's devel list.
Or directly in your Qt pro file, simply add the -isystem flag into the QMAKE_CXXFLAGS:
# the line below suppresses warnings generated by Qt's header files: we tell
# GCC to treat Qt's headers as "system headers" with the -isystem flag
QMAKE_CXXFLAGS += -isystem $$[QT_INSTALL_HEADERS]
The resulting GCC command line looks like:
g++ -c -pipe -isystem /usr/local/Qt-5.4.1/include -Wall ...
-I/usr/local/Qt-5.4.1/include
-I/usr/local/Qt-5.4.1/include/QtWidgets
...
Note how the Qt's include paths are still added with -I, allowing Qt Creator to "see" all Qt headers, but GCC sees the -isystem flag and suppresses warnings for all subfolders.
Did you install Qt in a system path? Otherwise qmake won't pass -isystem.
You can check which paths are system paths according to qmake by reading your mkspec/qconfig.pri (after you run configure), the system paths are set to the QMAKE_DEFAULT_INCDIRS variable. Here:
QMAKE_DEFAULT_INCDIRS = /usr/include/c++/4.8 /usr/include/x86_64-linux-gnu/c++/4.8 /usr/include/c++/4.8/backward /usr/lib/gcc/x86_64-linux-gnu/4.8/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed /usr/include/x86_64-linux-gnu /usr/include

Sqlite load extension disabled?

I'm trying to use this sqlite extension to calculate stdev in Sqlite dbs, on Linux, I use this command to compile the lib
gcc -fPIC -lm -shared extension-functions.c -o libsqlitefunctions.so
but seems that the .load command is not in the sqlite .help command list, and I got error:
unknown command or invalid arguments: "load". Enter ".help" for help
Same thing happens when I use the command:
sqlite> SELECT load_extension('./libsqlitefunctions.so');
SQL error: no such function: load_extension
I tried to use this instruction to compile sqlite:
0. untar latest sqlite3 source code in a new directory
1. cd to the newly untarred sqlite directory
2. Comment out the line in Makefile.in to enable loadable extensions:
# TCC += -DSQLITE_OMIT_LOAD_EXTENSION=1
3. ./configure LIBS=-ldl && make sqlite3
4. export LD_LIBRARY_PATH="`pwd`:$LD_LIBRARY_PATH"
5. gcc -I`pwd` -shared src/test_loadext.c -o half.so
6. ./sqlite3
But couldn't find the line "TCC += -DSQLITE_OMIT_LOAD_EXTENSION=1" in the newest Sqlite source code.
It looks like configure was updated but not the documentation. Try
./configure --enable-dynamic-extensions
The reference is the configure source code. Digging further, it looks like the dynamic extensions are enabled by default. From README:
The generic installation instructions for autoconf/automake are found
in the INSTALL file.
The following SQLite specific boolean options are supported:
--enable-readline use readline in shell tool [default=yes]
--enable-threadsafe build a thread-safe library [default=yes]
--enable-dynamic-extensions support loadable extensions [default=yes]
So I think load is present. It's the second part of the error invalid arguments that's the problem.
The cause seems to be that you're using Linux instructions. That won't work. Macs don't generally have .so files, which is what your compilation command is generating.
The method of compiling and loading a Mac dynamic library, loadable as an extension, is at this location. The compile command is going to look something like
gcc -bundle -fPIC -I/path-to-sqlite/sqlite3 -o filename.sqlext filename.c
Note the -bundle and -fPIC that are important for dynamic loading, but which you were missing. The resulting filename will be filename.sqlext, so use that in your path.
It may be worth noting that you may get a "missing symbols" error when you load the library - this is due to the fact that the -lm flag needs to be at the end of the compile command thus:
gcc -fPIC -shared extension-functions.c -o libsqlitefunctions.so -lm
Regards Fat jonnie

Resources