I get an error message when building a project after updating from SVN to get the sources that build fine on another RPi4 identical in configuration.

"Fatal: Cannot find LazSerial used by RemoteIO. Check if package LazSerialPort is in the dependencies."

The LazSerial dependency has been *removed*, that was the whole point of this excercise.
There is no longer any mention in the source files of lazserial and I have removed the dependencies for LazSerial in the project inspector.

Where can Lazarus have stored this bogus information?

In Project inspector are only 3 items:
Files
SerialTest.lpr
formmain.pas
Required packages:
LCL

I have even searched the files in the project for LazSerial and it only finds the word in comments....

Further debugging leads to the following:

1) I deleted the lib dir below the project so that Lazarus will recompile everything.

2) Now Lazarus succeeds in building the application! So there must have been some artifact left in the old lib dir from earlier tests.

3) But when I run it, it disappears when I use the Open Comm button, which is opening the serial port for communications!

4) So I stepped through the code below the button and reached this after the serial commands actually completed successfully: This is where the read thread is created and started:

  if Assigned(FOnRxData) then
  begin
    FReadThread := TComPortReadThread.Create(true); //<= Exception
    FReadThread.Owner := Self;
    FReadThread.MustDie := false;
    FReadThread.ReadPacketSize := FReadPacketSize;
    FReadThread.ReadTimeout := (FReadThread.ReadPacketSize * 10000)
div FBaudRate + 1;
    FReadThread.FreeOnTerminate := false;
    FReadThread.Start;
  end;

The error message that pops up on the first line in the block is this:

|------------------------------------------------------------| | Debugger exception notification | |------------------------------------------------------------| | Project SerialTest raised exception class 'RunError(232)'. | | At address 6B | |------------------------------------------------------------|

Note that the thread type is declared like this:

TComPortReadThread=class(TThread)

So it is using TThread, which AFAIK is a general type of class and not from LazSerial.

So the TThread creation is now throwing an exception whereas with the LazSerial in the dependencies it did not..

STRANGE "SOLUTION", BUT WHY?
----------------------------
So even though I am not really using *anything* in LazSerial I added LazSerialPort back to the dependencies and rebuilt the application. Now the thread creation does no longer show any such exception! And the application runs properly.

But I REALLY do not want to specify LazSerialPort as a dependency when it is the point of my work to *remove* LazSerial and Synapse from the project.

What is going on and how can I find where it really goes astray? And what can LazSerial bring into this?

Further to this mystery:
If I remove LazSerialPort from the dependencies and instead put SdpoSerialLaz there instead it also solves the problem:
- Program builds fine
- Program does not crash when the read thread is created.

But remove this so the only dependency is LCL then the program builds but crashes when the read thread is created after the serial port has been opened.

Bo Berglund wrote

On Tue, 01 Sep 2020 22:46:55 +0200, Bo Berglund via fpc-pascal wrote:

Hi,

Well, I believe that this supposed mystery may be resolved easily. ;-) First of all - have you tried to find out what does the displayed error number (232) mean? Quick searching reveals that runtime error 232 may signalize that you try to use threads without having a thread manager included in your application. Under Linux/Unix, you can add a thread manager by adding unit cthreads to the uses section of your program. That also provides explanation of your "mystery" - the other dependencies tried by you included this unit by themselves and thus you didn't need to do so in your program.

Hope this helps

Tomas

Yes it does!
Thank you so very much!!!!
I can finally go to bed now....

This is how it looks like in the dpr file:

program SerialTest;
{$mode objfpc}{$H+}
uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}

I usually always take out the extra ifdef for UseCThreads so it looks like this:

uses
  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}

But it was forgotten in this test application....

Strange because I have read that cthreads must be first in uses in the lpr program files in order to make threads work.
How could it work if I add the dependencies, then it would come later or maybe earlier???

Anyway now working.
THanks again!

On 2020-09-02 00:21, Bo Berglund via fpc-pascal wrote:

.
.

Strange because I have read that cthreads must be first in uses in the lpr program files in order to make threads work. How could it work if I add the dependencies, then it would come later or maybe earlier???

The real requirement is that the thread manager needs to be initialized before any threading features are used. If any of the used units uses threading features in its initialization, then such a unit should have cthreads in its own uses section (then this requirement is obviously fulfilled), or cthreads must be listed before that unit in the uses section of your program (and having cthreads as the first unit makes this requirement fulfilled as well).

Tomas

OK, so I made a test by commenting out cthreads in the lpr file and instead adding it as the first uses in my fpserialport unit, but that made things even worse...
In this case the application itself would not appear when I started it from its desktop icon. After trying to see what caused this I started it from the terminal instead and then I got this:

$ ./SerialTest
Threading has been used before cthreads was initialized. Make cthreads one of the first units in your uses clause. Runtime error 211 at $003958A0
$003958A0
$B64FF718

So a different kind of error than the one I had earlier and this indicates that it really has to be the very first uses in the application dpr file. Which is what I believed.

Maybe if one has a thread enabled package specified in the project dependencies, that package's use of cthreads precedes even the lpr uses clause and therefore the requirement is fulfilled?

Both LazSerial and SdpoSerialLaz uses a read thread, which to me look identical in their respective source code.
So my read thread is based on theirs with some minor modifications only...

Op 02-09-2020 om 00:21 schreef Bo Berglund via fpc-pascal:

It's an old message, but maybe I can shine some light onto the issue. A Lazarus package can add a define. So by adding a dependency on the LazSerial package, the UseCThreads define is added to your project.

That is why adding a dependency solved the problem. And apperently LazSerial also uses the cthreads unit. When that happens, and the unit is not also the first used unit, you do not get rhe runtime-error 232, but 211.

Regards,

Joost.