Visual Studio Code's intellisense doesn't recognize Arduino port managing - visual-studio-code

I'm trying to use VScode for Arduino Uno early development. I'd like to use intellisense but in the "Problems tab" it shows me errors:
identifier "DDRD" is undefined
identifier "PIND" is undefined
identifier "PORTD" is undefined
identifier "PORTD" is undefined
I can compile and upload the code flawlessly and it works.
I read everywhere that the solution to this is adding at the very top of the code the macro definition of the microcontroller, but it seems that this doesn't work for me only.
This is my code
#define __AVR_ATmega328P__
#include <avr/io.h>
#include <util/delay.h>
int main(void) {
int switchState = 0;
DDRD &= ~(1 << 2);
DDRD |= 1 << 3;
DDRD |= 1 << 4;
DDRD |= 1 << 5;
for (;;) {
switchState = 0x01 & (PIND >> 2);
if (!switchState) {
PORTD |= 1 << 3;
PORTD &= ~(1 << 4);
PORTD &= ~(1 << 5);
} else {
PORTD &= ~(1 << 3);
PORTD &= ~(1 << 4);
PORTD |= 1 << 5;
_delay_ms(250);
PORTD |= 1 << 4;
PORTD &= ~(1 << 5);
_delay_ms(250);
}
}
return 0;
}
If I right-click a DDRD underlined macro and select "Go to definition" it brings me to the DDRD macro definition in io76c711.h, while I expect been redirected in iom328p.h, because io.h contains
#elif defined (__AVR_ATmega328P__)
# include <avr/iom328p.h>
It seems that AVR_AT76C711 is defined somewhere else but I can't wonder where.
Do you have any suggestion? I also post my c_cpp_properties.json if there is something wrong in the one generated by the VScode Arduino extension
{
"configurations": [
{
"name": "Win32",
"includePath": [
"C:\\Program Files (x86)\\Arduino\\tools\\**",
"D:\\Arduino\\libraries\\**",
"C:\\Program Files (x86)\\Arduino\\libraries\\**",
"C:\\Program Files (x86)\\Arduino\\hardware\\tools\\**",
"C:\\Program Files (x86)\\Arduino\\hardware\\arduino\\avr\\**"
],
"forcedInclude": [
"C:\\Program Files (x86)\\Arduino\\hardware\\arduino\\avr\\cores\\arduino\\Arduino.h"
],
"defines": [
"USBCON"
],
"intelliSenseMode": "gcc-x64",
"compilerPath": "/usr/bin/gcc",
"cStandard": "gnu11",
"cppStandard": "gnu++14"
}
],
"version": 4
}

Add "__AVR_ATmega328P__" to the define section of your c_cpp_properties.json file as follows:
"defines": [
"__AVR_ATmega328P__",
Then it will be able to find the correct AVR IO include file.
In your case, AVR_AT76C711 was just one possibility for the definition, but it likely wasn't actually defined in your project.
Note: the define will automatically be removed the next time that the IntelliSense Configuration is rebuilt (e.g.: Verify or Upload). This issue is currently tracked here.

The issue is that the header files with register definitions/initializations such as <avr/iom328p.h> are only included at compile-time by the compiler. As a result, intellisense has no clue about those definitions while error-checking your code. By manually defining which board you use or by setting a compiler argument (which would normally be set at compile-time), you can get intellisense to recognize the necessary header files.
Adding the flag "-mmcu=atmega328" to my Arduino configuration's compilerArgs (within c_cpp_properties.json) resolved this intellisense issue. Obviously change the atmega chip number as needed.
"configurations": [
{
"name": "Arduino",
"compilerPath":
"path\\to\\your\\compiler",
"compilerArgs": [
"-mmcu=atmega328"
],
"intelliSenseMode": "gcc-x64",
"includePath": [
"paths\\to\\include"
]
}
]
If this change keeps getting cleared, it will be necessary to disable the auto-generation of the c_cpp_properties.json file. This setting ID is : arduino.disableIntelliSenseAutoGen

Related

Why do I get "Failed to open macho file..." when running program under VSCODE but not under normal shell?

I have a C++ program (compiled using CLANG++) that executes CLANG++ to compile another program. When I run this program using OSX shell it runs fine. When I run it under VSCODE debug it runs but following message is displayed: "023-01-12 15:01:02.577820-0800 clang++[10766:1004764] Failed to open macho file at /Library/Developer/CommandLineTools/usr/bin/clang++ for reading: Too many levels of symbolic links". I'm assuming that this message is coming from CLANG++ but I couldn't swear to that. Note, too, that the return code from clang++ is 0.
The routine that executes the compiler is (Note that I also have a routine that runs the compiled program but there isn't any problem with that):
void compileit(){
string codeLoc = "/usr/bin/clang++";
vector<char *> argv;
argv.push_back((char *)codeLoc.c_str());
argv.push_back((char *)"-g");
argv.push_back((char *)"-std=c++14");
argv.push_back((char *)"-otest.a");
argv.push_back((char *)"test.cpp");
argv.push_back((char *)NULL);
pid_t pid;
if ((pid = fork()) < 0) {
cout << "Fork failed" << endl;
exit(999);
}else if (pid > 0) {
cout << "Launching compiler" << endl;
int wstatus;
waitpid(-1, &wstatus, 0);
if (wstatus == 0){
cout << "CPP compiled successfully" << endl;
return;
}else{
cout << "Compile of CPP file failed: " << wstatus << endl;
}
}else{
int status = execv(codeLoc.c_str(),&argv[0]);
cout << "Couldn't launch the compiler" << endl;
exit(998);
}
}
type here
The program being compiled (by the code above) is:
#include <iostream>
using namespace std;
int main(int argc, char *argv[]) {
cout << "\nhello world" << endl;
return 0;
}
type here
The launch.json file is:
{
"version": "0.2.0",
"configurations": [
{
"name": "C/C++: clang++ build and debug active file",
"type": "lldb",
"request": "launch",
"program": "${workspaceFolder}/main",
"args": ["-b1"],
"cwd": "${workspaceFolder}",
"preLaunchTask": "C/C++: clang++ build active file",
}
]
}
And, the output displayed by VSCODE's terminal when I run the program (including the output when it is run) is:
Launching compiler
2023-01-12 15:01:02.577820-0800 clang++[10766:1004764] Failed to open macho file at /Library/Developer/CommandLineTools/usr/bin/clang++ for reading: Too many levels of symbolic links
CPP compiled successfully
From main: Launching test.a
test.a completed successfully
From forked main: Launching test.a
carl#McTreehouse test %
hello world
type here
A caveat: I'm new to Stack Overflow so If I've not provided enough or the correct information please let me know and I'll provide updates. I'm also more of a hobbyist c++ programmer than a professional (my background is Tandem/HP Nonstop TAL/Cobol).
My original code, which was related to a larger project, exhibited this behavior so I tried to reduce the specifics to the code described above. I had hoped that something I was doing in the larger context was causing the problem but after getting the specific code to its minimal state the problem persisted.
I spent some time looking at the VSCODE properties but couldn't spot anything that seemed like a problem. I also went looking for symlinks in the /Library/Developer directory but didn't spot anything (but could have easily missed it).
What I'm concerned about it this behavior showing up randomly when running the larger project from the shell or as a CGI.

Memory leak in C++ VScode with mingw-64 ,CRT: _CrtDumpMemoryLeaks() not showing the memory leak

I am on windows 11 using VScode to run a C++ code with ming-w64.
I have installed ming-w64 following all these steps
I am running a code that has a deliberate memory leak to see if there is a report by _CrtDumpMemoryLeaks().
this is my code:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#include <iostream>
#ifdef _DEBUG
#define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ )
// Replace _NORMAL_BLOCK with _CLIENT_BLOCK if you want the
// allocations to be of _CLIENT_BLOCK type
#else
#define DBG_NEW new
#endif
using namespace std;
int main()
{
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_DEBUG );
_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT );
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDOUT );
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDOUT );
int *i2 = new int(2);
cout << "address of i2 :" << i2 << endl;
bool check = _CrtDumpMemoryLeaks();
cout << "MEMORY check :" << check << endl;
cout << "After CrtDumpMemoryLeaks" << endl;
}
This is the TERMINAL:
PS C:\Users\שראל\Desktop\C_proj\projects\helloworld> & 'c:\Users\שראל\.vscode\extensions\ms-vscode.cpptools-1.9.7\debugAdapters\bin\WindowsDebugLauncher.exe' '--stdin=Microsoft-MIEngine-In-o0zd5lqu.up2' '--stdout=Microsoft-MIEngine-Out-gva0ndx0.ycm' '--stderr=Microsoft-MIEngine-Error-eec2m2xg.4x5' '--pid=Microsoft-MIEngine-Pid-fakhxofs.oyp' '--dbgExe=C:\msys64\mingw64\bin\gdb.exe' '--interpreter=mi'
address of i2 :0x190a9ff1a90
MEMORY check :0
After CrtDumpMemoryLeaks
And the OUTPUT is empty.
I don't understand what I am doing wrong here.

Visual Studio Code cant run c++ after resetting windows

I need help.
I installed Visual Studio Code, then I installed the latest version of MingW for C++ programming.
When I try to run the program, show this
[Running] cd "d:\projects\helloword" && g++ helloword.cpp -o helloword && "d:\projects\helloword"helloword
'g++' �����ڲ����ⲿ���Ҳ���ǿ����еij���
���������ļ���
[Done] exited with code=1 in 0.042 seconds
#include <iostream>
#include <vector>
#include <string>
using namespace std;
int main()
{
vector<string> msg {"Hello", "C++", "World", "from", "VS Code", "and the C++ extension!"};
for (const string& word : msg)
{
cout << word << " ";
}
cout << endl;
return 0;
}

Use VSCode to compile and run STM32 projects

I been using Visual Studio and VSCode for a long time; therefore, it will be great if I can use it instead of Eclipse or Keil. Should I move to those IDEs? I like having no dependencies where I have a make file that compiles and flashes my code to an stm32. Moreover, I can customize VSCode a lot. For example I have a plugin called highlight and I have a regex that will highlight everything that is between USER CODE BEGIN and USER CODE END. As a result my code looks like this:
Now I know that my code can only exist on the highlighted regions. That way if I make any changes using CubeMx my code will not be lost.
Thanks to this videos I am able to debug, compile and flash stm32 projects:
Part 1: https://youtu.be/PxQw5_7yI8Q
Part 2: https://youtu.be/PxQw5_7yI8Q
For some reason I had to create a build directory at the root of my project for my make file to run.
Anyways my question is how can I remove the squiggles on VSCode? It will be great if VSCode gave me no errors/warnings
For example I get a lot of squiggles on the SystemCLock_Config function:
But that is strange because if I press F12 on the __HAL_PWR_VOLTAGESCALING_CONFIG function it takes me to ...MyProject\Drivers\STM32L1xx_HAL_Driver\Inc\stm32l1xx_hal_pwr.h and the definition is #define __HAL_PWR_VOLTAGESCALING_CONFIG(__REGULATOR__) (MODIFY_REG(PWR->CR, PWR_CR_VOS, (__REGULATOR__)))
So for some reason F12 is able to find the definition but not the compiler. A solution would be to place this at the top of my main.c file:
#ifdefine _DEBUG
#define PWR 0
#endif
But it is tedious to do that for every squiggly error.
This question from stack-overflow has help me remove some errors but not all:
uint32_t does not name a type - VSCode with STM32 in Windows.
Anyways from doing research from the internet this is how my c_cpp_properties.json file looks like:
{
"configurations": [
{
"name": "STM32 L1",
"includePath": [
"${workspaceFolder}/**"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE",
"DUSE_HAL_DRIVER",
"DSTM32L152xE",
"STM32L1xx",
"__CC_ARM"
],
"intelliSenseMode": "gcc-arm",
"compilerPath": "${env:ARMGCC_DIR}/arm-none-eabi-gcc.exe",
"compilerArgs": [
"-mcpu=cortex-m3",
"-mthumb"
],
"cStandard": "c11",
"cppStandard": "c++17"
}
],
"version": 4
}
I am using this board: https://www.st.com/en/evaluation-tools/nucleo-l152re.html . I have also tried it with the bluepill and I get the same results.
Finally found the solution:
This file ...MyProject\Drivers\CMSIS\Device\ST\STM32L1xx\Include\stm32l1xx.h
Has this code
//.....
#if defined(STM32L100xB)
#include "stm32l100xb.h"
#elif defined(STM32L100xBA)
#include "stm32l100xba.h"
#elif defined(STM32L100xC)
#include "stm32l100xc.h"
#elif defined(STM32L151xB)
#include "stm32l151xb.h"
#elif defined(STM32L151xBA)
#include "stm32l151xba.h"
#elif defined(STM32L151xC)
#include "stm32l151xc.h"
#elif defined(STM32L151xCA)
#include "stm32l151xca.h"
#elif defined(STM32L151xD)
#include "stm32l151xd.h"
#elif defined(STM32L151xDX)
#include "stm32l151xdx.h"
#elif defined(STM32L151xE)
#include "stm32l151xe.h"
#elif defined(STM32L152xB)
#include "stm32l152xb.h"
#elif defined(STM32L152xBA)
#include "stm32l152xba.h"
#elif defined(STM32L152xC)
#include "stm32l152xc.h"
#elif defined(STM32L152xCA)
#include "stm32l152xca.h"
#elif defined(STM32L152xD)
#include "stm32l152xd.h"
#elif defined(STM32L152xDX)
#include "stm32l152xdx.h"
#elif defined(STM32L152xE)
#include "stm32l152xe.h"
#elif defined(STM32L162xC)
#include "stm32l162xc.h"
#elif defined(STM32L162xCA)
#include "stm32l162xca.h"
#elif defined(STM32L162xD)
#include "stm32l162xd.h"
#elif defined(STM32L162xDX)
#include "stm32l162xdx.h"
#elif defined(STM32L162xE)
#include "stm32l162xe.h"
#else
#error "Please select first the target STM32L1xx device used in your application (in stm32l1xx.h file)"
#endif
So I had to add the definition STM32L152xE on my c_cpp_properties.json file. My c_cpp_properties.json file contains this:
{
"configurations": [
{
"name": "Win32",
"includePath": [
"${workspaceFolder}/**"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE",
"DUSE_HAL_DRIVER",
"DSTM32L152xE",
"STM32L152xE"
],
"windowsSdkVersion": "10.0.19041.0",
"compilerPath": "${env:ARMGCC_DIR}/arm-none-eabi-gcc.exe",
"cStandard": "c17",
"cppStandard": "c++20",
"intelliSenseMode": "gcc-arm",
"compilerArgs": [
"-mcpu=cortex-m3",
"-mthumb"
]
}
],
"version": 4
}

How to build Qt 5.2 on Solaris 10?

The Qt page does not list pre-compiled Qt 5 packages for Solaris. Searching around, it does not seem to be included in the popular package repository OpenCSW, either. Some google hits suggest that building Qt 5 under Solaris involves some work under Solaris 10.
Thus my question: How to build Qt 5.2 under Solaris 10?
Basically it is:
cd qt-everywhere-opensource-src-5.2.0
./configure -prefix $MY_PREFIX -opensource -confirm-license -nomake tests \
-R /opt/csw/lib/64 -R /opt/csw/X11/lib/64 -qt-xcb -platform solaris-g++-64 \
-verbose
gmake -j16
gmake -j16 install
plus some adjustments because Qt 5 does not seem to be used on
Solaris much, yet.
Adjustments
Obtain the source
wget http://download.qt-project.org/official_releases/qt/5.2/5.2.0/single/qt-everywhere-opensource-src-5.2.0.tar.gz
md5sum qt-everywhere-opensource-src-5.2.0.tar.gz
228b6384dfd7272de00fd8b2c144fecd qt-everywhere-opensource-src-5.2.0.tar.gz
If the system does not habe md5sum you can use openssl md5 filename instead.
Install dependencies
I recommend to use OpenCSW because we need some dependencies to build Qt. The most important ones are:
CSWlibxcbdevel
CSWlibicu-dev # soft-dependency
CSWgcc4g++
CSWgmake
I suggest to use GCC to compile Qt. I am not aware of any advantages using the C++ compiler from Solaris Studio. On the contrary, the level of C++/STL support of this compiler may be not sufficient for a lot of use cases.
Setup environment
Make sure that you environment is clean. That means that /opt/csw/bin comes first and no LD_LIBRAYR_PATH* variables are set.
To simplify things it is probably a good idea that some directories are removed from PATH. For example such that no cc, CC commands from a Solaris Studio installation are accidentally picked up (e.g. during the compile of a bundled 3rd party component.
Adjust the specs
The software under /usr/sfw is just too outdated. /opt/csw from OpenCSW is a better replacement. Then the X-Open version is not sufficient for some used system functions.
--- a/qtbase/mkspecs/solaris-g++-64/qmake.conf
+++ b/qtbase/mkspecs/solaris-g++-64/qmake.conf
## -35,7 +35,7 ## QMAKE_LEX = flex
QMAKE_LEXFLAGS =
QMAKE_YACC = yacc
QMAKE_YACCFLAGS = -d
-QMAKE_CFLAGS = -m64 -D_XOPEN_SOURCE=500 -D__EXTENSIONS__
+QMAKE_CFLAGS = -m64 -D_XOPEN_SOURCE=600 -D__EXTENSIONS__
QMAKE_CFLAGS_DEPS = -M
QMAKE_CFLAGS_WARN_ON = -Wall -W
QMAKE_CFLAGS_WARN_OFF = -w
## -58,8 +58,8 ## QMAKE_CXXFLAGS_STATIC_LIB = $$QMAKE_CFLAGS_STATIC_LIB
QMAKE_CXXFLAGS_YACC = $$QMAKE_CFLAGS_YACC
QMAKE_CXXFLAGS_THREAD = $$QMAKE_CFLAGS_THREAD
-QMAKE_INCDIR = /usr/sfw/include
-QMAKE_LIBDIR = /usr/sfw/lib/64
+QMAKE_INCDIR = /opt/csw/include /opt/csw/X11/include
+QMAKE_LIBDIR = /opt/csw/lib/64 /opt/csw/X11/lib/64
QMAKE_INCDIR_X11 = /usr/openwin/include
QMAKE_LIBDIR_X11 = /usr/openwin/lib/64
QMAKE_INCDIR_OPENGL = /usr/openwin/include
Fix the shell
Solaris comes with a /bin/sh that violates POSIX to an extend such
that Qt's configure scripts and even shell-code in qmake-generated
code fails.
POSIX does not specify that /bin/sh has to be conforming it just specifies that the system must have a conforming shell available 'somewhere'. On Solaris it is e.g. under /usr/xpg4/bin/sh. The portable way to get a conforming shell is to search for it in the directories returned by getconf CS_PATH ...
Anyways, my choice for Solaris is to just use /usr/bin/bash:
Anyways, my choice for Solaris is to just use /usr/bin/bash:
--- a/configure
+++ b/configure
## -1,4 +1,4 ##
-#! /bin/sh
+#!/usr/bin/bash
#############################################################################
##
## Copyright (C) 2012 Digia Plc and/or its subsidiary(-ies).
--- a/qtbase/configure
+++ b/qtbase/configure
## -1,4 +1,4 ##
-#!/bin/sh
+#!/usr/bin/bash
#############################################################################
##
## Copyright (C) 2013 Digia Plc and/or its subsidiary(-ies).
## -6892,7 +6892,7 ## fi'`
echo "$CONFIG_STATUS" | grep '\-confirm\-license' >/dev/null 2>&1 || CONFIG_STATUS="$CONFIG_STATUS -confirm-license"
[ -f "$outpath/config.status" ] && rm -f "$outpath/config.status"
- echo "#!/bin/sh" > "$outpath/config.status"
+ echo "#!/usr/bin/bash" > "$outpath/config.status"
[ -n "$PKG_CONFIG_SYSROOT_DIR" ] && \
echo "export PKG_CONFIG_SYSROOT_DIR=$PKG_CONFIG_SYSROOT_DIR" >> "$outpath/config.status"
[ -n "$PKG_CONFIG_LIBDIR" ] && \
--- a/qtbase/qmake/generators/makefile.cpp
+++ b/qtbase/qmake/generators/makefile.cpp
## -2306,6 +2306,10 ## MakefileGenerator::writeHeader(QTextStream &t)
if (ofile.lastIndexOf(Option::dir_sep) != -1)
ofile.remove(0, ofile.lastIndexOf(Option::dir_sep) +1);
t << "MAKEFILE = " << ofile << endl << endl;
+
+ t << "# custom mod because Solaris /bin/sh is such a standard-violating choice\n"
+ << "# - gs, 2013-12-23" << endl;
+ t << "SHELL = /usr/bin/bash" << endl << endl;
}
QList<MakefileGenerator::SubTarget*>
Fix the ICU test
Solaris 10 comes with an outdated libicu - which is missing features Qt 5 needs. Thus, we simply extend the icu-test. Then either no ICU-support is build or proper one in case we install a recent libicu e.g. via OpenCSW.
--- a/qtbase/config.tests/unix/icu/icu.cpp
+++ b/qtbase/config.tests/unix/icu/icu.cpp
## -43,6 +43,16 ##
#include <unicode/ucol.h>
#include <unicode/ustring.h>
+// for testing if ucal_clone is there (i.e. if we have libicu >= 4.0)
+#include <unicode/ucal.h>
+
+static UCalendar *ucp(UCalendar *i)
+{
+ UErrorCode status = U_ZERO_ERROR;
+ UCalendar *r = ucal_clone(i, &status);
+ return r;
+}
+
int main(int, char **)
{
UErrorCode status = U_ZERO_ERROR;
## -50,5 +60,10 ## int main(int, char **)
if (U_FAILURE(status))
return 0;
ucol_close(collator);
+
+ UCalendar *cal = ucal_open(0, -1, "C", UCAL_GREGORIAN, &status);
+ UCalendar *x = ucp(cal);
+ ucal_close(x);
+
return 0;
}
Fix bundled pcre
Perhaps alternatively one can install a libpcre via OpenCSW.
--- a/qtbase/src/3rdparty/pcre/pcre_compile.c
+++ b/qtbase/src/3rdparty/pcre/pcre_compile.c
## -66,6 +66,8 ## COMPILE_PCREx macro will already be appropriately set. */
#endif
+#include <stdint.h>
+
/* Macro for setting individual bits in class bitmaps. */
#define SETBIT(a,b) a[(b)/8] |= (1 << ((b)&7))
Fix sha3
At least on Solaris 10/Sparc the functions fromBytesToWord and fromWordtoBytes are used by the code, thus:
--- a/qtbase/src/3rdparty/sha3/KeccakF-1600-opt64.c
+++ b/qtbase/src/3rdparty/sha3/KeccakF-1600-opt64.c
## -324,7 +324,7 ## static void KeccakPermutation(unsigned char *state)
KeccakPermutationOnWords((UINT64*)state);
}
-#if 0 // Unused in the Qt configuration
+#if 1 // Unused in the Qt configuration
static void fromBytesToWord(UINT64 *word, const UINT8 *bytes)
{
unsigned int i;
## -445,7 +445,7 ## static void KeccakAbsorb(unsigned char *state, const unsigned char *data, unsign
#endif
}
-#if 0 // Unused in the Qt configuration
+#if 1 // Unused in the Qt configuration
static void fromWordToBytes(UINT8 *bytes, const UINT64 word)
{
unsigned int i;
Include/type/usage fixes
The uname() function is activated via a CPP construct on Solaris
and is declared in that header:
--- a/qtbase/src/corelib/io/qfileselector.cpp
+++ b/qtbase/src/corelib/io/qfileselector.cpp
## -51,6 +51,8 ##
#include <QtCore/QLocale>
#include <QtCore/QDebug>
+#include <sys/utsname.h>
+
QT_BEGIN_NAMESPACE
//Environment variable to allow tooling full control of file selectors
Under Solaris parent is unused in that code-path and the code gets compiled with -Werror ...
--- a/qtbase/src/corelib/io/qfilesystemwatcher.cpp
+++ b/qtbase/src/corelib/io/qfilesystemwatcher.cpp
## -77,6 +77,7 ## QFileSystemWatcherEngine *QFileSystemWatcherPrivate::createNativeEngine(QObject
#elif defined(Q_OS_FREEBSD) || defined(Q_OS_MAC)
return QKqueueFileSystemWatcherEngine::create(parent);
#else
+ (void)parent;
return 0;
#endif
}
Under Solaris uid_t has an 'unexpected' sign (-> Werror). Casting it to ssize_t should be a portable and safe choice:
--- a/qtbase/src/corelib/io/qstandardpaths_unix.cpp
+++ b/qtbase/src/corelib/io/qstandardpaths_unix.cpp
## -132,7 +132,7 ## QString QStandardPaths::writableLocation(StandardLocation type)
}
// "The directory MUST be owned by the user"
QFileInfo fileInfo(xdgRuntimeDir);
- if (fileInfo.ownerId() != myUid) {
+ if (fileInfo.ownerId() != ssize_t(myUid)) {
qWarning("QStandardPaths: wrong ownership on runtime directory %s, %d instead of %d", qPrintable(xdgRuntimeDir),
fileInfo.ownerId(), myUid);
return QString();
Similar issue with threading code (Werror because of sign-mismatch in pointer cast). Casting to size_t should be a portable safe choice:
--- a/qtbase/src/corelib/thread/qthread_unix.cpp
+++ b/qtbase/src/corelib/thread/qthread_unix.cpp
## -231,7 +231,7 ## QThreadData *QThreadData::current()
}
data->deref();
data->isAdopted = true;
- data->threadId = (Qt::HANDLE)pthread_self();
+ data->threadId = (Qt::HANDLE)((size_t)pthread_self());
if (!QCoreApplicationPrivate::theMainThread)
QCoreApplicationPrivate::theMainThread = data->thread;
}
## -314,7 +314,7 ## void *QThreadPrivate::start(void *arg)
thr->d_func()->setPriority(QThread::Priority(thr->d_func()->priority & ~ThreadPriorityResetFlag));
}
- data->threadId = (Qt::HANDLE)pthread_self();
+ data->threadId = (Qt::HANDLE)((size_t)pthread_self());
set_thread_data(data);
data->ref();
## -393,7 +393,7 ## void QThreadPrivate::finish(void *arg)
Qt::HANDLE QThread::currentThreadId() Q_DECL_NOTHROW
{
// requires a C cast here otherwise we run into trouble on AIX
- return (Qt::HANDLE)pthread_self();
+ return (Qt::HANDLE)((size_t)pthread_self());
}
#if defined(QT_LINUXBASE) && !defined(_SC_NPROCESSORS_ONLN)
The struct in_addr has a struct as first attribute on Solaris, thus gives a warning with GCC when initializing with {0} - thus, yields an error during Qt-compile:
--- a/qtbase/src/network/socket/qnativesocketengine_unix.cpp
+++ b/qtbase/src/network/socket/qnativesocketengine_unix.cpp
## -63,6 +63,7 ##
#endif
#include <netinet/tcp.h>
+#include <string.h>
QT_BEGIN_NAMESPACE
## -737,7 +738,8 ## QNetworkInterface QNativeSocketEnginePrivate::nativeMulticastInterface() const
return QNetworkInterface::interfaceFromIndex(v);
}
- struct in_addr v = { 0 };
+ struct in_addr v;
+ memset(&v, 0, sizeof(struct in_addr));
QT_SOCKOPTLEN_T sizeofv = sizeof(v);
if (::getsockopt(socketDescriptor, IPPROTO_IP, IP_MULTICAST_IF, &v, &sizeofv) == -1)
return QNetworkInterface();
The header comment of X11/Xutil.h lists X11/Xutil.h as dependency, and indeed, without that include some declarations are missing under Solaris.
--- a/qtbase/src/plugins/platforms/xcb/qxcbmime.cpp
+++ b/qtbase/src/plugins/platforms/xcb/qxcbmime.cpp
## -46,6 +46,7 ##
#include <QtCore/QBuffer>
#include <qdebug.h>
+#include <X11/Xlib.h>
#include <X11/Xutil.h>
#undef XCB_ATOM_STRING
The X11/extensions/XIproto.h is not C++-safe under Solaris. That means it contains struct members names class. Fortunately, the header does not seem to be used in that code.
--- a/qtbase/src/plugins/platforms/xcb/qxcbxsettings.cpp
+++ b/qtbase/src/plugins/platforms/xcb/qxcbxsettings.cpp
## -43,7 +43,7 ##
#include <QtCore/QByteArray>
-#include <X11/extensions/XIproto.h>
+//#include <X11/extensions/XIproto.h>
QT_BEGIN_NAMESPACE
/* Implementation of http://standards.freedesktop.org/xsettings-spec/xsettings-0.5.html */
The pow() function has some overloads as specified in the C++ standard which introduce ambiguities under Solaris. Fixing the types like this should be portable and safe:
--- a/qtdeclarative/src/qml/jsruntime/qv4globalobject.cpp
+++ b/qtdeclarative/src/qml/jsruntime/qv4globalobject.cpp
## -534,7 +534,7 ## ReturnedValue GlobalFunctions::method_parseInt(CallContext *ctx)
}
if (overflow) {
- double result = (double) v_overflow * pow(R, overflow_digit_count);
+ double result = (double) v_overflow * pow(double(R), int(overflow_digit_count));
result += v;
return Encode(sign * result);
} else {
Under Solaris, alloca needs another header:
--- a/qtdeclarative/src/qml/jsruntime/qv4stringobject.cpp
+++ b/qtdeclarative/src/qml/jsruntime/qv4stringobject.cpp
## -73,6 +73,11 ##
# include <windows.h>
#endif
+
+#if OS(SOLARIS)
+#include <alloca.h>
+#endif
+
using namespace QV4;
DEFINE_MANAGED_VTABLE(StringObject);
Fix deep mkdir
Qt does a 'deep' mkdir() (e.g. something like mkdir -p for e.g. creating a directory hierarchy, e.g. ~/.config/company/product. The Qt 5.2 algorithm may abort too soon on Solaris if an existing directory is located inside a non-writable NFS mounted parent - because in that case Solaris returns EACCESS instead of EEXIST.
--- a/qtbase/src/corelib/io/qfilesystemengine_unix.cpp
+++ b/qtbase/src/corelib/io/qfilesystemengine_unix.cpp
## -579,6 +579,11 ## bool QFileSystemEngine::createDirectory(const QFileSystemEntry &entry, bool crea
// on the QNet mountpoint returns successfully and reports S_IFDIR.
|| errno == ENOENT
#endif
+#if defined(Q_OS_SOLARIS)
+ // On Solaris 10, mkdir returns EACCESS on a directory which exists
+ // inside an NFS mount ...
+ || errno == EACCES
+#endif
) {
QT_STATBUF st;
if (QT_STAT(chunk.constData(), &st) == 0 && (st.st_mode & S_IFMT) == S_IFDIR)
Temporary files
Solaris also does not have mkdtemp():
--- a/qtbase/src/corelib/io/qtemporarydir.cpp
+++ b/qtbase/src/corelib/io/qtemporarydir.cpp
## -52,7 +52,7 ##
#endif
#include <stdlib.h> // mkdtemp
-#if defined(Q_OS_QNX) || defined(Q_OS_WIN) || defined(Q_OS_ANDROID)
+#if defined(Q_OS_QNX) || defined(Q_OS_WIN) || defined(Q_OS_ANDROID) || defined(Q_OS_SOLARIS)
#include <private/qfilesystemengine_p.h>
#endif
## -96,7 +96,7 ## static QString defaultTemplateName()
static char *q_mkdtemp(char *templateName)
{
-#if defined(Q_OS_QNX ) || defined(Q_OS_WIN) || defined(Q_OS_ANDROID)
+#if defined(Q_OS_QNX ) || defined(Q_OS_WIN) || defined(Q_OS_ANDROID) || defined(Q_OS_SOLARIS)
static const char letters[] = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
const size_t length = strlen(templateName);
Pthreads
Solaris does not have pthread_get_stacksize_np (the _np suffix stands for non-portable).
Solaris has another function for getting stack-address/size values. My attempt:
--- a/qtdeclarative/src/qml/jsruntime/qv4engine.cpp
+++ b/qtdeclarative/src/qml/jsruntime/qv4engine.cpp
## -73,6 +73,11 ##
#include "qv4isel_moth_p.h"
#if USE(PTHREADS)
+
+#if OS(SOLARIS)
+#include <thread.h>
+#endif
+
# include <pthread.h>
#endif
## -103,6 +108,11 ## quintptr getStackLimit()
} else
size = pthread_get_stacksize_np(thread_self);
stackLimit -= size;
+# elif OS(SOLARIS)
+ stack_t ss;
+ int r = thr_stksegment(&ss);
+ (void)r;
+ stackLimit = reinterpret_cast<quintptr>(ss.ss_sp);
# else
void* stackBottom = 0;
pthread_attr_t attr;
--- a/qtdeclarative/src/qml/jsruntime/qv4mm.cpp
+++ b/qtdeclarative/src/qml/jsruntime/qv4mm.cpp
## -67,6 +67,11 ##
#include <sys/storage.h> // __tls()
#endif
+#if OS(SOLARIS)
+#include <thread.h>
+#include <pthread.h>
+#endif
+
QT_BEGIN_NAMESPACE
using namespace QV4;
## -218,6 +223,11 ## MemoryManager::MemoryManager()
# if OS(DARWIN)
void *st = pthread_get_stackaddr_np(pthread_self());
m_d->stackTop = static_cast<quintptr *>(st);
+# elif OS(SOLARIS)
+ stack_t ss;
+ int r = thr_stksegment(&ss);
+ (void)r;
+ m_d->stackTop = static_cast<quintptr *>(ss.ss_sp) + ss.ss_size/sizeof(quintptr);
# else
void* stackBottom = 0;
pthread_attr_t attr;
I recommend a careful review of that code because my Qt-code does not use that Qt-module, thus, I did not test it much.
XKB extension
Qt 5 seems to heavily rely on the XKB extension. It seems that you can't build Qt 5 without XKB support. It comes bundled with xkbcommon.
First, make sure that it finds the right XKB database. Otherwise keyboard input does not work at all in your Qt programs!
Solaris does not have the default value /usr/share/X11/xkb. It has instead:
/usr/X11/lib/X11/xkb
/usr/openwin/lib/X11/xkb
But I havn't had luck with those - xkbcommon simply could not find any components with those.
I ended up with copying /usr/share/X11/xkb from a cygwin distribution to a custom path and configuring that as XKB database.
Whatever XKB you choose you have to configure it:
--- a/qtbase/src/3rdparty/xkbcommon.pri
+++ b/qtbase/src/3rdparty/xkbcommon.pri
## -1,7 +1,12 ##
QMAKE_CFLAGS += -std=gnu99 -w
INCLUDEPATH += $$PWD/xkbcommon $$PWD/xkbcommon/src $$PWD/xkbcommon/src/xkbcomp
+solaris-g++-64 {
+DEFINES += DFLT_XKB_CONFIG_ROOT='\\"/MY/XKB/CHOICE\\"'
+} else {
DEFINES += DFLT_XKB_CONFIG_ROOT='\\"/usr/share/X11/xkb\\"'
+}
### RMLVO names can be overwritten with environmental variables (See libxkbcommon documentation)
DEFINES += DEFAULT_XKB_RULES='\\"evdev\\"'
For testing it also make sense to check for NULL values in error message parameters:
--- a/qtbase/src/3rdparty/xkbcommon/src/xkbcomp/xkbcomp.c
+++ b/qtbase/src/3rdparty/xkbcommon/src/xkbcomp/xkbcomp.c
## -68,8 +68,11 ## text_v1_keymap_new_from_names(struct xkb_keymap *keymap,
log_err(keymap->ctx,
"Couldn't look up rules '%s', model '%s', layout '%s', "
"variant '%s', options '%s'\n",
- rmlvo->rules, rmlvo->model, rmlvo->layout, rmlvo->variant,
- rmlvo->options);
+ rmlvo->rules, rmlvo->model,
+ rmlvo->layout ? rmlvo->layout : "(NULL)",
+ rmlvo->variant ? rmlvo->variant : "(NULL)",
+ rmlvo->options ? rmlvo->options : "(NULL)"
+ );
return false;
}
There is also the possibility that your XServer does not even support the XKB extension. Again, I don't know if Qt 5 can be configured with disabled-XKB-support under X.
You can check your X-server like this:
xprop -root | grep xkb
Or call a random xkb-program, e.g.:
xkbvleds
Such call should not result in an error like:
Fatal Error: Server doesn't support a compatible XKB
In case your XServer does not have XKB - Qt programs are likely to segfault. Qt does not seem to really check for XKB support. It does not seem to have a fallback mechanism when XKB is not usable.
Examples
Some examples fail because of module quick not being found:
--- a/qtconnectivity/examples/bluetooth/scanner/scanner.pro
+++ b/qtconnectivity/examples/bluetooth/scanner/scanner.pro
## -1,4 +1,4 ##
-QT = core bluetooth quick
+QT = core bluetooth # quick
SOURCES += qmlscanner.cpp
TARGET = qml_scanner
diff --git a/qtconnectivity/examples/nfc/poster/poster.pro b/qtconnectivity/examples/nfc/poster/poster.pro
index d108b2a..d0d0659 100644
--- a/qtconnectivity/examples/nfc/poster/poster.pro
+++ b/qtconnectivity/examples/nfc/poster/poster.pro
## -1,4 +1,4 ##
-QT += qml quick network nfc widgets
+QT += qml network nfc widgets # quick
SOURCES += \
qmlposter.cpp
They are also built without.
make install
A gmake install surprisingly triggers the compilation of several modules not yet compiled. Thus it make sense to execute it in parallel:
$ gmake -j16 install
(assuming that your system has a sufficient number of cores)
QtHelp
The bundled QtHelp module is not build/installed with the main compile/install steps.
To fix that:
cd qttools
PATH=$MY_PREFIX/bin:$PATH qmake
gmake
gmake install
Open issues
when using a remote Cygwin-X connection some colors are weird - e.g. the standard widget-gray is some light-light-blue - any ideas where to start to look for that?
QtSVG is successfully built but displaying a small SVG (e.g. inside a QLabel) hangs the dialog - a truss -u : shows function calls inside libm/QtWidget - perhaps the system is just way too slow and/or some code-path is not optimized on Solaris/in combination with a X-forwarding over ssh
a Qt-Program prints on startup: Qt Warning: Could not find a location of the system's Compose files. Consider setting the QTCOMPOSE environment variable. - no idea what feature this is about
Conclusion
With those adjustments 'normal' Qt programs (without QtSvg) compile
and run fine under Solaris 10.

Categories