Останні повідомлення форума : Bug tracker

[Qt+Wayland] Loss combobox items after empty one

roman — Sat, 14 Feb 2026 10:20:12 +0200

OpenSCADA: [Work 1.0-r3xxx, LTS 0.9.8] > UI.{QTCfg,Vision}
Linux: Debian 12 64
Qt: 5.15.8
Resume: An environmental bug of the Qt in working on Wayland with representing empty items in the combobox list, which was reproduced on two devices.
Workaround: Only use XOrg now.

[Qt] Crashing at insertion empty buffer to Text Areas

roman — Sat, 14 Feb 2026 10:01:55 +0200

OpenSCADA: [Work 1.0-r3xxx, LTS 0.9.7] > UI.{QTCfg,Vision}
Linux: Debian 12 64
Qt: 6.4.2
Resume: An environmental bug of the Qt in working with the copy-past buffer in Text Areas
Workaround: The bug fixed in Qt 6.4 of bigger minors, but the broken version is frozen already in Debian 12, so there we build OpenSCADA there with Qt5 still.

[Sockets] Wrong holding the socket handler

roman — Sat, 14 Feb 2026 09:37:48 +0200

The problem has not reproduced more up to 14.02.2026.

FormEl table ceil color

roman — Sat, 11 Oct 2025 21:54:56 +0300

"walhi" wrote:

JAVASCRIPT

src/moduls/ui/Vision/vis_shapes.cpp
-- tit->setData(Qt::BackgroundRole, QColor(wVl.c_str()));
++ tit->setData(Qt::BackgroundRole, getColor(wVl.c_str()));
 
-- tit->setData(Qt::ForegroundRole, QColor(wVl.c_str()));
++ tit->setData(Qt::ForegroundRole, getColor(wVl.c_str()));

Yes, I have added of using the standard OpenSCADA function getColor() for transparency here.

"walhi" wrote:

This doesn't solve the problem of identical display both on the web and locally, but it's better than before. Bonus: experience building from source.

And for that I have adapted UI.WebVision for parsing alfa value from OpenSCADA format and placing it to "rgba(red, green, blue, alpha)" in case of hex colors, due to named colors are needed of conversion to hex.

FormEl table ceil color

walhi — Thu, 09 Oct 2025 23:34:00 +0300

"roman" wrote:

And that is obvious for different visualizers, which smoothing is not a bug fixing also but it is a feature appending.

As it turns out, the source code contains a function that solves the problem with displaying on the Qt, but it was not used in the code that populates the table cells.

JAVASCRIPT

QColor OSCADA_QT::getColor( const string &val )

JAVASCRIPT

src/moduls/ui/Vision/vis_shapes.cpp
-- tit->setData(Qt::BackgroundRole, QColor(wVl.c_str()));
++ tit->setData(Qt::BackgroundRole, getColor(wVl.c_str()));
 
-- tit->setData(Qt::ForegroundRole, QColor(wVl.c_str()));
++ tit->setData(Qt::ForegroundRole, getColor(wVl.c_str()));

This doesn't solve the problem of identical display both on the web and locally, but it's better than before. Bonus: experience building from source.

FormEl table ceil color

roman — Thu, 09 Oct 2025 19:05:24 +0300

"walhi" wrote:

"roman" wrote:

Just see the source code of the related visualizer before open bugs

The forum section description states that this section should be used to report errors and inaccuracies in the documentation. Since I couldn't find a description of this specific feature in the documentation, the original purpose of this post was to supplement the documentation. But as it turns out, this is more like a problem.

Firstly, OpenSCADA documentation cannot trace all specific of the visualization frameworks and changes in their structures!
Secondary, that is not about errors in the documentation and for such its improvements created independent forum!

"walhi" wrote:

"roman" wrote:

OK, and where there about bugs?

However, as it later turned out, the interfaces in WebVision and QtVision look different, something I only discovered now. I am attaching another screenshot showing the difference in display. The first example showed the working user interface on Qt.

And that is obvious for different visualizers, which smoothing is not a bug fixing also but it is a feature appending.

Your example just show the difference in the extending hex color on Qt and Web, that is the format is not standard in whole and even in Web appeared newly.

FormEl table ceil color

walhi — Thu, 09 Oct 2025 18:51:02 +0300

"roman" wrote:

Just see the source code of the related visualizer before open bugs

"roman" wrote:

OK, and where there about bugs?

FormEl table ceil color

roman — Thu, 09 Oct 2025 18:09:23 +0300

"walhi" wrote:

"roman" wrote:

And that is not a bug!!!

I am attaching an example of a table where this appears and a screenshot.

OK, and where there about bugs?

That is only the WebBrowser behavior at transmission the color in hex, which OpenSCADA treats in noway!

Just see the source code of the related visualizer before open bugs — http://oscada.org/svn/trunk/OpenSCADA/src/moduls/ui/WebVision/WebVisionVCA.js

FormEl table ceil color

walhi — Thu, 09 Oct 2025 16:08:36 +0300

"roman" wrote:

And that is not a bug!!!

I am attaching an example of a table where this appears and a screenshot.

HTML

"
ЦветЗначение
_red-127
_red
_#FF0000-255, непрозрачный красный RGB-A
_#FF0000FF, непрозрачный красный RGBA
_#FFFF0000, непрозрачный красный ARGB
_#FF000040, прозрачный красный RGBA
_#40FF0000, прозрачный красный ARGB

FormEl table ceil color

roman — Thu, 09 Oct 2025 14:48:06 +0300

"walhi" wrote:

Hello. I've discovered that widgets like FormEl Table have a non-standard implementation of cell color support.

See in the ElFigure primitive due to that is a standard for all primitives!

And that is not a bug!!!

FormEl table ceil color

walhi — Thu, 09 Oct 2025 14:33:15 +0300

Hello. I've discovered that widgets like FormEl Table have a non-standard implementation of cell color support. Experiments have shown that the color specification standard adopted in OpenSCADA (the RGB HEX value plus a separate alpha channel in DEC) is not recognized, and the standard HTML is parsed incorrectly. Instead of the RGBA ordering, the ARGB ordering is used, but I couldn't find any mention of this in the documentation.

Big syslog

walhi — Mon, 29 Sep 2025 16:35:27 +0300

"roman" wrote:

You may have installed and running in the background the service configurations from openscada-server or openscada-plc with different message levels!

No. One station is running. I'm checking it with tail -f /var/log/syslog, and the messages disappear if I uncheck all the boxes in the configurator "to stderr", "to stdout", and "to syslog". There's no response at the change message level". I found the problem. Level 0 was set in the PLC diagnostics. I was sure that the level set in the workstation settings took precedence over the one specified for the PLC. The only remaining issue was redirecting stdout/stder to syslog, which only occurred on one project and one operating system.

Big syslog

roman — Mon, 29 Sep 2025 15:52:20 +0300

"walhi" wrote:

And the log size in whole is dependent only from your project, who generates extra messages!!!

The problem is that the syslog add-on is disabled and the message level is set to 1, but in fact, messages with a level of 0 are logged. And this only occurs on Ubuntu.

Then that is not syslog in whole but a replacement from systemd which writes stdout or stderr of the service programs.

In any way, OpenSCADA writes messages corresponding to the pointed level, what you can see from the sources — http://oscada.org/svn/trunk/OpenSCADA/src/tmess.cpp

You may have installed and running in the background the service configurations from openscada-server or openscada-plc with different message levels!

Big syslog

walhi — Mon, 29 Sep 2025 13:28:21 +0300

And the log size in whole is dependent only from your project, who generates extra messages!!!

The problem is that the syslog add-on is disabled and the message level is set to 1, but in fact, messages with a level of 0 are logged. And this only occurs on Ubuntu.

JAVASCRIPT

Big syslog

roman — Wed, 24 Sep 2025 17:22:11 +0300

"walhi" wrote:

Hello. I've encountered a very large syslog on a machine running Ubuntu 24.04. Syslog output was disabled. Message level 0 (debug). I have syslog level 1 (Information) selected and enabled output to archive, stdout, and stderr. This behavior was present in build 3018 and the latest 3045, but only on Ubuntu. I'm not sure if this is a bug, so I apologize in advance if I haven't figured out how the logging works.

OpenSCADA doesn't write in the syslog at no setting such option — http://oscada.org/wiki/Special:MyLanguage/Documents/Program_manual#Config

And the log size in whole is dependent only from your project, who generates extra messages!!!

Big syslog

walhi — Wed, 24 Sep 2025 16:44:31 +0300

Hello. I've encountered a very large syslog on a machine running Ubuntu 24.04. Syslog output was disabled. Message level 0 (debug). I have syslog level 1 (Information) selected and enabled output to archive, stdout, and stderr. This behavior was present in build 3018 and the latest 3045, but only on Ubuntu. I'm not sure if this is a bug, so I apologize in advance if I haven't figured out how the logging works.

The context menu elements in the configurator are disabled.

roman — Wed, 23 Jul 2025 15:03:25 +0300

That is about the permissions to the Function node, which were lost during moving the DAQ subsystem under ACL!

And I have fixed that right now.

The context menu elements in the configurator are disabled.

walhi — Wed, 23 Jul 2025 12:06:03 +0300

In the DAQ/JavaLikeCalc/Library section, it is impossible to copy or delete library functions through the configurator interface. However, this can be easily done through an XML request from JavaLikeCalc. When connecting the current version to an older one, these manipulations are available on the remote station.

utf8

arccis — Thu, 17 Apr 2025 13:08:34 +0300

it was an elegant function until Arkadii decided to draw smileys in scada. :)

utf8

roman — Thu, 17 Apr 2025 12:37:58 +0300

"arccis" wrote:

old and new functions will fail U+800 and U+10000 tests. length is now determined correctly, but the first byte is different. gpt chat refers to RFC 3629 limits.

And that is corresponding with https://en.wikipedia.org/wiki/UTF-8 , which is referring to RFC 3629, so you fix the article! :)

Due to in two and three bytes that well be:

JAVASCRIPT

U+800:                100000    000000    — Last code for two bytes is U+07FF
                  11? 100000 10 000000
U+10000:     10000    000000    000000    — Last code for three bytes is U+FFFF
        111? 10000 10 000000 10 000000

"arccis" wrote:

... and offers code without a loop.

And it offers to the biomass be stupid!? :)

utf8

arccis — Thu, 17 Apr 2025 11:20:31 +0300

old and new functions will fail U+800 and U+10000 tests. length is now determined correctly, but the first byte is different. gpt chat refers to RFC 3629 limits. and offers code without a loop.

JAVASCRIPT

string setUTF8(int32_t symb) {
    string rez;
    if (symb < 0x80)
        rez += (char)symb;
    else if (symb < 0x800) {
        rez += (char)(0xC0 | (symb >> 6));
        rez += (char)(0x80 | (symb & 0x3F));
    } else if (symb < 0x10000) {
        rez += (char)(0xE0 | (symb >> 12));
        rez += (char)(0x80 | ((symb >> 6) & 0x3F));
        rez += (char)(0x80 | (symb & 0x3F));
    } else if (symb < 0x110000) {
        rez += (char)(0xF0 | (symb >> 18));
        rez += (char)(0x80 | ((symb >> 12) & 0x3F));
        rez += (char)(0x80 | ((symb >> 6) & 0x3F));
        rez += (char)(0x80 | (symb & 0x3F));
    }
    return rez;
}

also the chat said that 6 bytes is not allowed by RFC 3629. and is considered unsafe, but code here:

JAVASCRIPT

std::string encodeUTF8_6Byte(uint32_t symb) {
    std::string result;
 
    if (symb < 0x80) {
        result += (char)symb;
    } else if (symb < 0x800) {
        result += (char)(0xC0 | (symb >> 6));
        result += (char)(0x80 | (symb & 0x3F));
    } else if (symb < 0x10000) {
        result += (char)(0xE0 | (symb >> 12));
        result += (char)(0x80 | ((symb >> 6) & 0x3F));
        result += (char)(0x80 | (symb & 0x3F));
    } else if (symb < 0x200000) {
        result += (char)(0xF0 | (symb >> 18));
        result += (char)(0x80 | ((symb >> 12) & 0x3F));
        result += (char)(0x80 | ((symb >> 6) & 0x3F));
        result += (char)(0x80 | (symb & 0x3F));
    } else if (symb < 0x4000000) {
        result += (char)(0xF8 | (symb >> 24));
        result += (char)(0x80 | ((symb >> 18) & 0x3F));
        result += (char)(0x80 | ((symb >> 12) & 0x3F));
        result += (char)(0x80 | ((symb >> 6) & 0x3F));
        result += (char)(0x80 | (symb & 0x3F));
    } else if (symb <= 0x7FFFFFFF) {
        result += (char)(0xFC | (symb >> 30));
        result += (char)(0x80 | ((symb >> 24) & 0x3F));
        result += (char)(0x80 | ((symb >> 18) & 0x3F));
        result += (char)(0x80 | ((symb >> 12) & 0x3F));
        result += (char)(0x80 | ((symb >> 6) & 0x3F));
        result += (char)(0x80 | (symb & 0x3F));
    } else {
        // Invalid range
        result = "?";
    }
 
    return result;
}

utf8

roman — Thu, 17 Apr 2025 09:09:26 +0300

"arccis" wrote:

2) but 0xD83D actually can't be converted directly. it is part of a surrogate pair (U+D800 through U+DFFF picture1) and you need to use the following code and apply the formula to them

Yes, I see, that is a real problem and I have not struck in that since have not used such codes.
But that is easily fixed for the same code:

JAVASCRIPT

string TMess::setUTF8( uint32_t symb )
{
    string rez;
    if(symb < 0x80) rez += (char)symb;
    else for(int iCh = 5, iSt = -1; iCh >= 0; iCh--) {
        if(iSt < iCh && (symb>>((iCh-1)*6+(7-iCh)))) iSt = iCh;
        if(iCh == iSt) rez += (char)((0xFF<<(7-iCh))|(symb>>(iCh*6)));
        else if(iCh < iSt) rez += (char)(0x80|(0x3F&(symb>>(iCh*6))));
    }
 
    return rez;
}

So, now I have:
U+1F600 = F09F9880
U+1FA00 = F09FA880
U+D83D = EDA0BD

utf8

arccis — Thu, 17 Apr 2025 01:24:22 +0300

1) on the test 0xD83D indeed both functions (TMess::setUTF8() and setUTF8_new(symb) ) work the same.
2) but 0xD83D actually can't be converted directly. it is part of a surrogate pair (U+D800 through U+DFFF picture1) and you need to use the following code and apply the formula to them

JAVASCRIPT

code1 = 0xD83D;
code2 = 0xDE00;
codePoint = 0x10000 + ((code1 - 0xD800) << 10) + (code2 - 0xDC00);

after that code codePoint == U+1F600. it is smile. pic2. setUTF8_new - correct, SYS.strFromCharUTF - wrong.
3) I compared the functions and they differ U+800...U+FFF, U+10000...> . Another example is U+1FA00 pic3.
4) function charCodeAt(0,"UTF-8"); is correct in 0...10FFF

JAVASCRIPT

output1 = setUTF8_new(codePoint);
codePoint1 = output1.charCodeAt(0,"UTF-8");

I used this code for tests

JAVASCRIPT

function setUTF8_new(symb){ 
	   if (symb <= 0x7F) {
        return SYS.strFromCharCode(symb);
    } else if (symb <= 0x7FF) {
        return SYS.strFromCharCode(
            0xC0 | (symb >> 6),
            0x80 | (symb & 0x3F)
        );
    } else if (symb <= 0xFFFF) {
        return SYS.strFromCharCode(
            0xE0 | (symb >> 12),
            0x80 | ((symb >> 6) & 0x3F),
            0x80 | (symb & 0x3F)
        );
    } else if (symb <= 0x10FFFF) {
        return SYS.strFromCharCode(
            0xF0 | (symb >> 18),              	// first 3 bits
            0x80 | ((symb >> 12) & 0x3F),			// next 6 bits
            0x80 | ((symb >> 6) & 0x3F),			// next 6 bits
            0x80 | (symb & 0x3F)							// last 6 bits
        );
    } 
}
 
// test for surrogate pairs
 
code1 = 0xD83D;
code2 = 0xDE00;
codePoint = 0x10000 + ((code1 - 0xD800) << 10) + (code2 - 0xDC00);
codePoint = 0x1FA00;
codePoint = 0x800;
 
 
//output1 = setUTF8(codePoint);
output1 = SYS.strFromCharUTF(codePoint);
output2 = setUTF8_new(codePoint);
 
 
 
 
// test in loop
/*
for(codePoint = 0x0; codePoint <= 0x10FFFF; codePoint++) {
 
 if (codePoint >= 0xD800 && codePoint <= 0xDFFF)
            continue; // surrogate pairs
 
	//output1 = setUTF8(codePoint);
	output1 = SYS.strFromCharUTF(codePoint);
	output2 = setUTF8_new(codePoint);
 
	if (output1 != output2) //break;
		console +=  "U+" + codePoint.toString(16) + "\n";	
}
*/
// test  passed charCodeAt(0,"UTF-8");
/*for(codePoint = 0x0; codePoint <= 0x10FFFF; codePoint++) {
 
 if (codePoint >= 0xD800 && codePoint <= 0xDFFF)
            continue; // surrogate pairs
 
	output1 = setUTF8_new(codePoint);
	codePoint1 = output1.charCodeAt(0,"UTF-8"); 
 
	if (codePoint != codePoint1) break;	
}
*/
 
codePointHex = "U+" + codePoint.toString(16) + " bin:[" + codePoint.toString(2) + "]";
 
 
 
ArInt1s = "len=" + output1.length + "; ";
ArInt1s += " hex:[";
for(i = 0; i < output1.length; i++){ 
	ArInt1s += "0x" + output1.charCodeAt(i).toString(16) + ",";
}	
 
ArInt1s += "]; dec:[";
for(i = 0; i < output1.length; i++){ 
	ArInt1s += output1.charCodeAt(i).toString(10) + ",";
}					
ArInt1s += "]; bin:[";
for(i = 0; i < output1.length; i++){ 
	ArInt1s +=   output1.charCodeAt(i).toString(2,8) + ",";
}	
 
ArInt1s += "]";
 
ArInt2s = "len=" + output2.length + "; ";
ArInt2s += "hex:[";
 
for(i = 0; i < output2.length; i++){ 
	ArInt2s += "0x" + output2.charCodeAt(i).toString(16) + ",";
}	
 
ArInt2s += "]; dec:[";
for(i = 0; i < output2.length; i++){ 
	ArInt2s += output2.charCodeAt(i).toString(10) + ",";
}	
ArInt2s += "]; bin:[";
for(i = 0; i < output2.length; i++){ 
	ArInt2s +=   output2.charCodeAt(i).toString(2,8) + ",";
}	
 
ArInt2s += "]";
 
 
if (output1 == output2){
	ArInt2s = "equal";
}

utf8

roman — Wed, 16 Apr 2025 11:27:27 +0300

"arccis" wrote:

I tested my library and decided to add decoding and encoding of surrogate pairs like \uD83D\uDE00. It turned out that the SYS.strFromCharUTF function does not work correctly on 3-byte and 4-byte characters. I found the TMess::setUTF8 function in the code, ported it to JavaLikeCalc. I checked it on the entire range (0x0... 0x10FFFF) that it works the same as c++. Then I implemented another function and compared the results.

And what a problem with encoding in three bytes say for 0xD83D, where TMess::setUTF8() returns — 0xEDA0BD. And that is corresponded to https://en.wikipedia.org/wiki/UTF-8 and is written as:

JAVASCRIPT

0xD83D:	       1101    100000    111101
0xEDA0BD: 1110 1101 10 100000 10 111101

"arccis" wrote:

PS As I understand it, utf8 can be no more than 4 bytes. 6 bytes is an outdated option (before 2003) and is not recommended.

When you don't use such U-Codes, you will not get 6 bytes.

utf8

arccis — Tue, 15 Apr 2025 23:01:17 +0300

I tested my library and decided to add decoding and encoding of surrogate pairs like \uD83D\uDE00. It turned out that the SYS.strFromCharUTF function does not work correctly on 3-byte and 4-byte characters. I found the TMess::setUTF8 function in the code, ported it to JavaLikeCalc. I checked it on the entire range (0x0... 0x10FFFF) that it works the same as c++. Then I implemented another function and compared the results.

JAVASCRIPT

function setUTF8(symb){ //this function work like strFromCharUTF in 0...10FFF
	rez = "";
	if(symb < 0x80)
		rez = SYS.strFromCharCode(symb);
  else for( iCh = 5, iSt = -1; iCh >= 0; iCh--) {
		if(iSt < iCh && (symb>>(iCh*6))) iSt = iCh;
		if(iCh == iSt) rez += SYS.strFromCharCode((0xFF<<(7-iCh))|(symb>>(iCh*6)));
		else if(iCh < iSt) rez += SYS.strFromCharCode(0x80|(0x3F&(symb>>(iCh*6))));
    }
 
	return rez;
}
 
 
function setUTF8_new(symb){ 
	   if (symb <= 0x7F) {
        return SYS.strFromCharCode(symb);
    } else if (symb <= 0x7FF) {
        return SYS.strFromCharCode(
            0xC0 | (symb >> 6),
            0x80 | (symb & 0x3F)
        );
    } else if (symb <= 0xFFFF) {
        return SYS.strFromCharCode(
            0xE0 | (symb >> 12),
            0x80 | ((symb >> 6) & 0x3F),
            0x80 | (symb & 0x3F)
        );
    } else if (symb <= 0x10FFFF) {
        return SYS.strFromCharCode(
            0xF0 | (symb >> 18),              	// first 3 bits
            0x80 | ((symb >> 12) & 0x3F),			// next 6 bits
            0x80 | ((symb >> 6) & 0x3F),			// next 6 bits
            0x80 | (symb & 0x3F)							// last 6 bits
        );
    } 
}
 
// test for surrogate pairs
/*
code1 = 0xD83D;
code2 = 0xDE00;
codePoint = 0x10000 + ((code1 - 0xD800) << 10) + (code2 - 0xDC00);
output1 = setUTF8(codePoint);
//output2 = SYS.strFromCharUTF(codePoint);
output2 = setUTF8_new(codePoint);
*/
 
 
// test in loop
for(codePoint = 0x0; codePoint <= 0x10FFFF; codePoint++) {
 
 if (codePoint >= 0xD800 && codePoint <= 0xDFFF)
            continue; // surrogate pairs
 
	//output1 = setUTF8(codePoint);
	output1 = SYS.strFromCharUTF(codePoint);
	output2 = setUTF8_new(codePoint);
 
	if (output1 != output2) break;
 
}
 
 
// test  passed charCodeAt(0,"UTF-8");
/*for(codePoint = 0x0; codePoint <= 0x10FFFF; codePoint++) {
 
 if (codePoint >= 0xD800 && codePoint <= 0xDFFF)
            continue; // surrogate pairs
 
	output1 = setUTF8_new(codePoint);
	codePoint1 = output1.charCodeAt(0,"UTF-8"); 
 
	if (codePoint != codePoint1) break;	
}
*/
ArInt1s = "dec:[";
for(i = 0; i < output1.length; i++){ 
	ArInt1s += output1.charCodeAt(i).toString(10) + ",";
}					
	ArInt1s += "]; hex:[";
	for(i = 0; i < output1.length; i++){ 
		ArInt1s += "0x" + output1.charCodeAt(i).toString(16) + ",";
	}	
	ArInt1s += "]";
 
 
ArInt2s = "dec:[";
for(i = 0; i < output2.length; i++){ 
	ArInt2s += output2.charCodeAt(i).toString(10) + ",";
}					
	ArInt2s += "]; hex:[";
	for(i = 0; i < output2.length; i++){ 
		ArInt2s += "0x" + output2.charCodeAt(i).toString(16) + ",";
	}	
	ArInt2s += "]";
 
 
if (output1 == output2){
ArInt2s = "equal";
}

PS As I understand it, utf8 can be no more than 4 bytes. 6 bytes is an outdated option (before 2003) and is not recommended.

F&F LE-03MB CT

roman — Wed, 14 Feb 2024 08:16:09 +0200

"arccis" wrote:

I think there are typos in calculating Powers(kW, kVA). P, P_1, P_2, P_3 and Pr should be divided by 10000, not 100 or 1000.

That is the end user who decided such coefficient correct, not me!

"arccis" wrote:

The protocol in this counter is called M-bus

Yes, I know.

F&F LE-03MB CT

arccis — Tue, 13 Feb 2024 23:18:16 +0200

Hello Roman! I am reading code of template "FF LE-03MB CT" and the datasheet of this counter. I think there are typos in calculating Powers(kW, kVA). P, P_1, P_2, P_3 and Pr should be divided by 10000, not 100 or 1000.
Page of the counter
The protocol in this counter is called M-bus
I do not have this equipment and my opinion is based only on the datasheet.

libintl missed symbols since r2914

dudanov — Thu, 31 Aug 2023 15:10:41 +0300

Yes, the patch works great! Build proceeds without errors.
Looking forward to the next revision with a fix.

Thanks Roman.

libintl missed symbols since r2914

roman — Thu, 31 Aug 2023 14:47:39 +0300

"dudanov" wrote:

In revision 2914, changes were made to the configure.ac. Among the changes is a change in the libintl check. As a result, the build process ends with a linking error finding symbols (-lintl is not passed to the linker).

Yes, I have adapted the building to R6220(MIPS) with no internationalisation in whole but with presence mostly empty libintl.h, so I added the declaration checking of the function bindtextdomain() but I wrong recalled the line "AC_SEARCH_LIBS(libintl_bindtextdomain, [intl])".

Try the included patch now!

libintl missed symbols since r2914

dudanov — Thu, 31 Aug 2023 12:52:12 +0300

Hello.

In revision 2914, changes were made to the configure.ac. Among the changes is a change in the libintl check. As a result, the build process ends with a linking error finding symbols (-lintl is not passed to the linker).

I did not quite understand why and for what purposes the changes were made, otherwise I could have offered an alternative solution.

The log output is below. The C system library is musl.

JAVASCRIPT

/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/openscada/src/.libs/liboscada.so: undefined reference to `libintl_bindtextdomain'
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/openscada/src/.libs/liboscada.so: undefined reference to `libintl_dgettext'
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/openscada/src/.libs/liboscada.so: undefined reference to `libintl_textdomain'
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/openscada/src/.libs/liboscada.so: undefined reference to `_nl_msg_cat_cntr'

Thanks.