Here’s a tip if you are using Fedora and trying to use one of the Google Sanitizers with clang and is having problems doing so. One of the common problems is not being able to find libclang_rt.asan-x86_64.a:
/usr/bin/ld:cannot find/usr/bin/../lib64/clang/3.8.0/lib/linux/libclang_rt.asan-x86_64.a:No such file ordirectory
This can be resolved by simply installing the compiler-rt package:
There’s, probably, a better way to do this. Per documentation, it should be possible to set it up permanently by creating a file on /etc/X11/xorg.conf.d however I did not manage to create a file that works so far.
Ignore the upgrade steps provided by the application. They are incomplete. If you execute them, the upgrade will finish with success but no rules will be enabled after that. Instead, execute the steps provided in this StackOverflow comment.
Newer versions of SonarQube have stopped supporting MariaDB and you may need to switch to MySQL instead. While I’d rather use MariaDB, I understand that it is not within the supported matrix. Therefore I am documenting the steps here. The steps are focused on RHEL 7 (they probably would work on Centos 7 as well, but I did not test it).
Before start with this process, shutdown your SonarQube instance as well as any other analysis that may access the database.
The first step is to use mysqldump to create a backup of your MariaDB database:
After the backup is complete, shutdown and disable your MariaDB instance:
systemctl stop mariadb;systemctl disable mariadb
Then install MySQL 5.7 from Software Collections. The process is documented on this page. These steps are for 5.6, however, you can just replace 56 with 57 in all the steps and the result is the same.
With the new MySQL 5.7 installed and running, create the database:
In the MySQL sheel recreate the database with the same credentials and permissions as the old one:
I have been on a intense session of C/C++ hacking lately and one of the things I came across is this interesting StackOverflow topic about how to colorize the GDB output. There are plenty of tips there, but since I prefer vanilla GDB, I just stick to the first one and downloaded a customized GDB for myself.
Today I decided to reorganize my GitHub repository. In the past, I added a lot of learning projects there and as time passed by, it was growing considerably. Since I currently have some work-related projects there, I thought it deserved some reorganization.
My idea was to consolidate some of the larger projects I had into a single repository where each component is a sub-module of the project. This was a rather natural choice because most of those projects are written in Java and use Maven, therefore being very easy to refactor into a module-based project layout.
One requirement I had was that I wanted to retain the commit history. After looking at some solutions involving git’s submodule or subtree features, I found one that was fairly simple. The process couldn’t be simpler: you have to add the projects as remote to your new project and run a couple of commands to merge, move and commit the files.
Additionally, since my projects usually follow the same standard, it was quite simple to automate. After running the initial steps to configure the new (consolidated) repository, I was able to run the mass import using the following command line:
formodule in$(echo"project1 project2");dogit merge-m"Merged $module master for repository reorganization"$module/master;mkdir$module;(forfile in$(echo"README.md pom.xml src test");do[[-e$file]]&&git mv$file$module/;done);git status;git commit-m"UPD: moved $module old files from a separate repo to a separate module".;done
I was even able to import the old branches for each of the sub-components I wanted to merge.