Discussion:
[Lazarus] Built console app on Linux, but won't run on another Linux machine
Bo Berglund via Lazarus
2018-10-27 10:25:04 UTC
Permalink
Using Lazarus 1.8.4 and FPC 3.0.4 64 bit on Ubuntu 18.04 64 bit.
Project built and runs fine on dev system.

Now copied executable to an Ubuntu Server 16.04 64 bit and tried to
run it. But here I get an immediate error:

./LicMgr: error while loading shared libraries: libgdk-x11-2.0.so.0:
cannot open shared object file: No such file or directory

In my code there is no such request so it must be something built into
the executable when compiled on Ubuntu 18.04, but how can I fix this?

The dev machine has a GUI interface (otherwise Lazarus would not work)
but the program itself is purely non-gui, it is just a Pascal program
and it does not even send output to the console, just handles files
and networking. Still the name libgdk-x11-2.0 suggests that it has
something to do with X...

Any ideas how I can remove dependencies of whatever libgdk-x11-2.0
means?

The Ubuntu Server 16.04 is meant to be the home of this utility...
--
Bo Berglund
Developer in Sweden

--
Mattias Gaertner via Lazarus
2018-10-27 10:43:02 UTC
Permalink
On Sat, 27 Oct 2018 12:25:04 +0200
Post by Bo Berglund via Lazarus
Using Lazarus 1.8.4 and FPC 3.0.4 64 bit on Ubuntu 18.04 64 bit.
Project built and runs fine on dev system.
Now copied executable to an Ubuntu Server 16.04 64 bit and tried to
cannot open shared object file: No such file or directory
In my code there is no such request so it must be something built into
the executable when compiled on Ubuntu 18.04, but how can I fix this?
Either install libgtk2.0-0 or remove the dependency.
Post by Bo Berglund via Lazarus
The dev machine has a GUI interface (otherwise Lazarus would not work)
but the program itself is purely non-gui, it is just a Pascal program
and it does not even send output to the console, just handles files
and networking. Still the name libgdk-x11-2.0 suggests that it has
something to do with X...
Maybe your project uses the LCL either directly or indirectly. See
Project Inspector.
If yes, remove it or set it to lclwidgettype "nogui".
Post by Bo Berglund via Lazarus
Any ideas how I can remove dependencies of whatever libgdk-x11-2.0
means?
The Ubuntu Server 16.04 is meant to be the home of this utility...
Mattias
--
Bo Berglund via Lazarus
2018-10-27 11:03:32 UTC
Permalink
On Sat, 27 Oct 2018 12:43:02 +0200, Mattias Gaertner via Lazarus
Post by Mattias Gaertner via Lazarus
Either install libgtk2.0-0 or remove the dependency.
I don't know how to "remove dependency"
When I work in Ubuntu 18.04 I am using the Xfce desktop, but the
programI am building has no GUI components whatsoever, so why should
there be any dependency towards X11?
Post by Mattias Gaertner via Lazarus
Post by Bo Berglund via Lazarus
The dev machine has a GUI interface (otherwise Lazarus would not work)
but the program itself is purely non-gui, it is just a Pascal program
and it does not even send output to the console, just handles files
and networking. Still the name libgdk-x11-2.0 suggests that it has
something to do with X...
Maybe your project uses the LCL either directly or indirectly. See
Project Inspector.
If yes, remove it or set it to lclwidgettype "nogui".
I had LCL there as Required package, but I removed it.
When I build the project the resulting binary is exactly the same
size, so there could not be anythingadded or deleted to the program...

The only external I can think of is needed is OpenSSH since my Indy10
external mail connection uses encrypted communication. But tah would
not be related to X11, right?
And I have not used any directive for it (other than what mau be
hidden inside Indy10).
--
Bo Berglund
Developer in Sweden

--
Sven Barth via Lazarus
2018-10-27 11:39:12 UTC
Permalink
Post by Bo Berglund via Lazarus
Post by Mattias Gaertner via Lazarus
Post by Bo Berglund via Lazarus
The dev machine has a GUI interface (otherwise Lazarus would not work)
but the program itself is purely non-gui, it is just a Pascal program
and it does not even send output to the console, just handles files
and networking. Still the name libgdk-x11-2.0 suggests that it has
something to do with X...
Maybe your project uses the LCL either directly or indirectly. See
Project Inspector.
If yes, remove it or set it to lclwidgettype "nogui".
I had LCL there as Required package, but I removed it.
When I build the project the resulting binary is exactly the same
size, so there could not be anythingadded or deleted to the program...
The only external I can think of is needed is OpenSSH since my Indy10
external mail connection uses encrypted communication. But tah would
not be related to X11, right?
And I have not used any directive for it (other than what mau be
hidden inside Indy10).
Binaries usually have aligned sections so removing or adding just a
small bit (like the dependency on gdk in your case introduced by the
LCL) does not necessarily mean a change in size.

You could also try "objdump -x /path/to/your/binary" and look at was is
listed as NEEDED in the Dynamic Section. You'd then need to find out
what dependencies you don't want to have and then figure out which units
led to their inclusion. Maybe it's just a stray unit that pulls in some
GUI dependencies.

Regards,
Sven

Regards,
Sven
--
Bo Berglund via Lazarus
2018-10-27 11:58:16 UTC
Permalink
On Sat, 27 Oct 2018 13:39:12 +0200, Sven Barth via Lazarus
Post by Sven Barth via Lazarus
Binaries usually have aligned sections so removing or adding just a
small bit (like the dependency on gdk in your case introduced by the
LCL) does not necessarily mean a change in size.
You could also try "objdump -x /path/to/your/binary" and look at was is
listed as NEEDED in the Dynamic Section. You'd then need to find out
what dependencies you don't want to have and then figure out which units
led to their inclusion. Maybe it's just a stray unit that pulls in some
GUI dependencies.
I tried to upgrade, dist-upgrade the server to remove the logon
greeting about available updates then rebooted.
No difference.

Then I tried by installing xfce4 desktop, thinking that this would
deposit the X11 stuff into the system. But it did not solve the
problem even though the start error message now changed to:

(LicMgr:19268): Gtk-WARNING **: cannot open display:

So clearly there was a problem somewhere here concerning X11 and it is
gone, but replaced with this display stuff...

I *really* need to get this program running without any GUI references
since it is supposed to be run by cron every 10 minutes to process
website generated request emails...
And the server itself is never accessed except via the command line
over the network. I am currently some 8400 km away from the physical
location of the server....
--
Bo Berglund
Developer in Sweden

--
Carlos E. R. via Lazarus
2018-10-27 12:03:16 UTC
Permalink
Post by Bo Berglund via Lazarus
I tried to upgrade, dist-upgrade the server to remove the logon
greeting about available updates then rebooted.
No difference.
Then I tried by installing xfce4 desktop, thinking that this would
deposit the X11 stuff into the system. But it did not solve the
IMHO, that's the wrong approach.

You have to remove the dependency, somehow, not fulfill it.
--
Cheers / Saludos,

Carlos E. R.
(from 42.3 x86_64 "Malachite" at Telcontar)
Bo Berglund via Lazarus
2018-10-27 12:32:38 UTC
Permalink
On Sat, 27 Oct 2018 14:03:16 +0200, "Carlos E. R. via Lazarus"
Post by Carlos E. R. via Lazarus
Post by Bo Berglund via Lazarus
I tried to upgrade, dist-upgrade the server to remove the logon
greeting about available updates then rebooted.
No difference.
Then I tried by installing xfce4 desktop, thinking that this would
deposit the X11 stuff into the system. But it did not solve the
IMHO, that's the wrong approach.
You have to remove the dependency, somehow, not fulfill it.
That is the problem, I don't know how to remove a dependency like
this...
--
Bo Berglund
Developer in Sweden

--
Alexey via Lazarus
2018-10-27 12:46:34 UTC
Permalink
I have an idea. Make an error in some gtk2 widget set unit. Build. Then you ll see which part of the app requires gtk2 code.
Alexey
--
Martin Schreiber via Lazarus
2018-10-27 15:23:58 UTC
Permalink
Post by Bo Berglund via Lazarus
That is the problem, I don't know how to remove a dependency like
this...
Another option:
- Compile the project with -vu, copy the message to a file.
- Analise the file with the MSEunitdep tool from here:
https://gitlab.com/mseide-msegui/mseide-msegui/tree/master/tools/unitdep
- Setup 'Start Unit' and 'Dest- Unit' in order to check the dependency path,
see the screenshot:
Loading Image...

Martin
--
Carlos E. R. via Lazarus
2018-10-28 07:04:16 UTC
Permalink
Post by Bo Berglund via Lazarus
On Sat, 27 Oct 2018 14:03:16 +0200, "Carlos E. R. via Lazarus"
Post by Carlos E. R. via Lazarus
Post by Bo Berglund via Lazarus
I tried to upgrade, dist-upgrade the server to remove the logon
greeting about available updates then rebooted.
No difference.
Then I tried by installing xfce4 desktop, thinking that this would
deposit the X11 stuff into the system. But it did not solve the
IMHO, that's the wrong approach.
You have to remove the dependency, somehow, not fulfill it.
That is the problem, I don't know how to remove a dependency like
this...
I don't know either how to find it, but installing "missing" libraries
on the server will not help, rather the contrary.
--
Cheers / Saludos,

Carlos E. R.
(from 42.3 x86_64 "Malachite" at Telcontar)
Sven Barth via Lazarus
2018-10-27 15:56:15 UTC
Permalink
Post by Bo Berglund via Lazarus
On Sat, 27 Oct 2018 13:39:12 +0200, Sven Barth via Lazarus
Post by Sven Barth via Lazarus
Binaries usually have aligned sections so removing or adding just a
small bit (like the dependency on gdk in your case introduced by the
LCL) does not necessarily mean a change in size.
You could also try "objdump -x /path/to/your/binary" and look at was is
listed as NEEDED in the Dynamic Section. You'd then need to find out
what dependencies you don't want to have and then figure out which units
led to their inclusion. Maybe it's just a stray unit that pulls in some
GUI dependencies.
I tried to upgrade, dist-upgrade the server to remove the logon
greeting about available updates then rebooted.
No difference.
Then I tried by installing xfce4 desktop, thinking that this would
deposit the X11 stuff into the system. But it did not solve the
So clearly there was a problem somewhere here concerning X11 and it is
gone, but replaced with this display stuff...
I *really* need to get this program running without any GUI references
since it is supposed to be run by cron every 10 minutes to process
website generated request emails...
And the server itself is never accessed except via the command line
over the network. I am currently some 8400 km away from the physical
location of the server....
As others already wrote you should not try to fulfill twee dependency on t
he server, but to remove it from your binary. For this you need to find out
what unit pulls in that dependency and get rid of that. You can maybe use
the Unit Dependencies window for that (see
http://wiki.freepascal.org/IDE_Window:_Unit_dependencies ).

Alternatively you could try to switch the LCLWidgetType to NoGUI as had
already been suggested by Mattias as well and try whether that is
sufficient.

Regards,
Sven
Juha Manninen via Lazarus
2018-10-27 11:57:39 UTC
Permalink
On Sat, Oct 27, 2018 at 2:03 PM Bo Berglund via Lazarus
Post by Bo Berglund via Lazarus
I had LCL there as Required package, but I removed it.
So you know how to remove a dependency!
How did the LCL dependency come there if you created a console program?

Juha
--
Bo Berglund via Lazarus
2018-10-27 12:31:31 UTC
Permalink
On Sat, 27 Oct 2018 14:57:39 +0300, Juha Manninen via Lazarus
Post by Juha Manninen via Lazarus
On Sat, Oct 27, 2018 at 2:03 PM Bo Berglund via Lazarus
Post by Bo Berglund via Lazarus
I had LCL there as Required package, but I removed it.
So you know how to remove a dependency!
How did the LCL dependency come there if you created a console program?
I ported an existing Delphi console program to Lazarus using its
conversion function. It was a test to get around a problem running the
original program on a new Windows 2016 Server machine...

After conversion it complained about directive {$APPTYPE CONSOLE}
being unrecognized so I had to IFNDEF FPC that line so it is only
visible in Delphi (which I rarely use these days)...
I assume that the converter brought in LCL, but I have removed it
today, did not make a difference.

Is there a way to tell Lazarus a program is meant to be a console
(command line) type program without GUI connections?
Or should I start over and create a new console program in Lazarus and
then bring in the units I have used for certain functions and also
change the main dpr file into a normal unit?
--
Bo Berglund
Developer in Sweden

--
Bo Berglund via Lazarus
2018-10-27 13:35:05 UTC
Permalink
On Sat, 27 Oct 2018 14:31:31 +0200, Bo Berglund via Lazarus
Post by Bo Berglund via Lazarus
Or should I start over and create a new console program in Lazarus and
then bring in the units I have used for certain functions and also
change the main dpr file into a normal unit?
I did this and created a new "Program", which was labeled in Lazarus
as a Free Pascal command line program.

Then I added my units from the other project and converted the dpr
file into a pas unit by moving away the final begin-code-end proram
section to the newly created program's source file.
Had to fix sections etc in the old dpr file so it now is a proper
unit.
But once done it built OK and worked as expected in Ubuntu 18.04.
The stripped size of this program as about 10 Mb whereas the earlier
version was only some 7 Mb...

But when I copied it over into the Ubuntu 16.04 server it again
displayed the GTK error...

(LicMgr:19450): Gtk-WARNING **: cannot open display:

It should not need a display!
--
Bo Berglund
Developer in Sweden

--
Mattias Gaertner via Lazarus
2018-10-27 14:06:07 UTC
Permalink
On Sat, 27 Oct 2018 15:35:05 +0200
Post by Bo Berglund via Lazarus
[...]
It should not need a display!
Then remove the gtk dependency.
Check Compiler options / Show Options / Inherited Parameters if you
are using the LCL.

If yes then use the Project Inspector, double click on the required
packages to see their dependencies. Or use Package / Package graph to
see the dependencies.

If no, then some unit uses the gtk2 directly. Use "View / Unit
Dependencies" to find out which one.

Mattias
--
Bo Berglund via Lazarus
2018-10-27 16:20:14 UTC
Permalink
On Sat, 27 Oct 2018 16:06:07 +0200, Mattias Gaertner via Lazarus
Post by Mattias Gaertner via Lazarus
On Sat, 27 Oct 2018 15:35:05 +0200
Post by Bo Berglund via Lazarus
[...]
It should not need a display!
Then remove the gtk dependency.
Check Compiler options / Show Options / Inherited Parameters if you
are using the LCL.
Well, I took LCL out of the project and it still has these problems.
Right now the Project Inspector only shows a single Required Package
and this is "indylaz"
Post by Mattias Gaertner via Lazarus
If yes then use the Project Inspector, double click on the required
packages to see their dependencies. Or use Package / Package graph to
see the dependencies.
This amazingly shows:
LCL
IDEIntf
FCL (>=1.0)
But I think these are for the Lazarus IDE integration of the visual
components and I am not using any forms or such so there is no use for
this.
Now I am at a loss as to how I can use Indy without bringing in
IndyLaz, just the required files. On Windows it is simple, I just set
the search path in Delpi to the location of the three Indy10 source
directories and I am done. Not so simple in Lazarus until I saw I
could install indylaz. Has worked fine for GUI applications so far....
Post by Mattias Gaertner via Lazarus
If no, then some unit uses the gtk2 directly. Use "View / Unit
Dependencies" to find out which one.
Don't know how...
--
Bo Berglund
Developer in Sweden

--
Juha Manninen via Lazarus
2018-10-27 17:06:54 UTC
Permalink
On Sat, Oct 27, 2018 at 7:11 PM Bo Berglund via Lazarus
Post by Bo Berglund via Lazarus
In the converted Delphi project I started with a .dpr file that
contained all active code except for two units to read Ini files mor
easily and to create Unix style hashed passwords. When it
was done it still used the dpr file as the main program source.
I don't understand you. The converter creates a .lpr file for sure.


On Sat, Oct 27, 2018 at 7:20 PM Bo Berglund via Lazarus
Post by Bo Berglund via Lazarus
Post by Mattias Gaertner via Lazarus
If yes then use the Project Inspector, double click on the required
packages to see their dependencies. Or use Package / Package graph to
see the dependencies.
LCL
IDEIntf
FCL (>=1.0)
But I think these are for the Lazarus IDE integration of the visual components
and I am not using any forms or such so there is no use for this.
Indeed!
It is not only for the IDE integration. There are units with GUI that need LCL.
Post by Bo Berglund via Lazarus
Now I am at a loss as to how I can use Indy without bringing in
IndyLaz, just the required files. On Windows it is simple, I just set
the search path in Delpi to the location of the three Indy10 source
directories and I am done.
You mean in Delphi it is simple.(?)
But no, actually the global search path in Delphi can be considered a
bug but they cannot remove it for backward compatibility.
It pollutes the namespace also for projects that do not need a
specific library/package.
Post by Bo Berglund via Lazarus
Not so simple in Lazarus until I saw I could install indylaz.
Has worked fine for GUI applications so far....
Yes, Indy apparently suits best for GUI apps.
You can of course set the search path of your Lazarus project to point
to Indy source directories.
That is not recommended normally but this is a special case.
If Indy Lazarus port was well designed, it would separate the GUI and
non-GUI parts to their own packages.

Juha
--
Bo Berglund via Lazarus
2018-10-27 22:44:17 UTC
Permalink
On Sat, 27 Oct 2018 20:06:54 +0300, Juha Manninen via Lazarus
Post by Juha Manninen via Lazarus
On Sat, Oct 27, 2018 at 7:11 PM Bo Berglund via Lazarus
Post by Bo Berglund via Lazarus
In the converted Delphi project I started with a .dpr file that
contained all active code except for two units to read Ini files mor
easily and to create Unix style hashed passwords. When it
was done it still used the dpr file as the main program source.
I don't understand you. The converter creates a .lpr file for sure.
On Sat, Oct 27, 2018 at 7:20 PM Bo Berglund via Lazarus
Post by Bo Berglund via Lazarus
Post by Mattias Gaertner via Lazarus
If yes then use the Project Inspector, double click on the required
packages to see their dependencies. Or use Package / Package graph to
see the dependencies.
LCL
IDEIntf
FCL (>=1.0)
But I think these are for the Lazarus IDE integration of the visual components
and I am not using any forms or such so there is no use for this.
Indeed!
It is not only for the IDE integration. There are units with GUI that need LCL.
Post by Bo Berglund via Lazarus
Now I am at a loss as to how I can use Indy without bringing in
IndyLaz, just the required files. On Windows it is simple, I just set
the search path in Delpi to the location of the three Indy10 source
directories and I am done.
You mean in Delphi it is simple.(?)
But no, actually the global search path in Delphi can be considered a
bug but they cannot remove it for backward compatibility.
It pollutes the namespace also for projects that do not need a
specific library/package.
I am talking about Delphi's project options where search path can be
entered, which are just valid for the project itself.
One can use environment variables here too to simplify the entries in
the list.
Post by Juha Manninen via Lazarus
Post by Bo Berglund via Lazarus
Not so simple in Lazarus until I saw I could install indylaz.
Has worked fine for GUI applications so far....
Yes, Indy apparently suits best for GUI apps.
You can of course set the search path of your Lazarus project to point
to Indy source directories.
That is not recommended normally but this is a special case.
If Indy Lazarus port was well designed, it would separate the GUI and
non-GUI parts to their own packages.
I found the location of the indylaz package files in:
~/.lazarus1.8.4/onlinepackagemanager/packages/Indy10/
Here are the 3 dirs I need, Core, Protocols and System.

So I adding these into the Compiler/Path/OtherUnitFiles setting in
Project Options lusing the selector button
../../../.lazarus1.8.4/onlinepackagemanager/packages/Indy10/Core
../../../.lazarus1.8.4/onlinepackagemanager/packages/Indy10/System
../../../.lazarus1.8.4/onlinepackagemanager/packages/Indy10/Protocols

And I also removed the indylaz package from the project dependencies.

But when I tried to build the project it complained that it could not
find Interfaces, so I remembered that this is supplied by LCL, so I
tried adding LCL back to the project required packages.
Then the project built OK.

But when I moved the (now skinnier executable) to the Ubuntu 18.04
machine I got the same warning once more:

(LicMgr:3198): Gtk-WARNING **: cannot open display:

So this did not cut it either...

Now I also found that I can test this easier, I just have to log out
of my development machine and stay at the login screen.
Then using PuTTY to connect to it and navigate to the project and
start the program from the command line throws the exact same error
message and the program won't run.

So it seems like someone (or maybe even me) must be logged on to the
machine console in order for it to execute this command line
program...
Being logged on to a TightVNC session does not count...


Soooo strange!
--
Bo Berglund
Developer in Sweden

--
Sven Barth via Lazarus
2018-10-27 22:49:50 UTC
Permalink
Post by Bo Berglund via Lazarus
Post by Juha Manninen via Lazarus
Post by Bo Berglund via Lazarus
Not so simple in Lazarus until I saw I could install indylaz.
Has worked fine for GUI applications so far....
Yes, Indy apparently suits best for GUI apps.
You can of course set the search path of your Lazarus project to point
to Indy source directories.
That is not recommended normally but this is a special case.
If Indy Lazarus port was well designed, it would separate the GUI and
non-GUI parts to their own packages.
~/.lazarus1.8.4/onlinepackagemanager/packages/Indy10/
Here are the 3 dirs I need, Core, Protocols and System.
So I adding these into the Compiler/Path/OtherUnitFiles setting in
Project Options lusing the selector button
../../../.lazarus1.8.4/onlinepackagemanager/packages/Indy10/Core
../../../.lazarus1.8.4/onlinepackagemanager/packages/Indy10/System
../../../.lazarus1.8.4/onlinepackagemanager/packages/Indy10/Protocols
And I also removed the indylaz package from the project dependencies.
But when I tried to build the project it complained that it could not
find Interfaces, so I remembered that this is supplied by LCL, so I
tried adding LCL back to the project required packages.
Then the project built OK.
That something is pulling in unit Interfaces is proof that something tries
to use GUI units. So either find out what unit that is (it could either be
one of yours or maybe an Indy one) or try to set the LCLWidgetType to NoGUI.

Regards,
Sven
Juha Manninen via Lazarus
2018-10-28 07:24:40 UTC
Permalink
This post might be inappropriate. Click to display it.
Martin Schreiber via Lazarus
2018-10-28 09:10:52 UTC
Permalink
Post by Juha Manninen via Lazarus
I personally would just copy the needed indy units into my project
subdirectory and add them to the project. If any of those units
require LCL, the project will not compile. Simple, ha?
Or add the Indy *.ppu directory as a -Fu parameter without using Indy
packages?
Loading Image...

Martin
--
Bo Berglund via Lazarus
2018-10-28 16:25:45 UTC
Permalink
On Sun, 28 Oct 2018 09:24:40 +0200, Juha Manninen via Lazarus
Post by Juha Manninen via Lazarus
I personally would just copy the needed indy units into my project
subdirectory and add them to the project. If any of those units
require LCL, the project will not compile. Simple, ha?
Well, years ago I tried that with Delphi, but it turned out that the
units needed expanded from the first one since they are interdependent
so in the end I used environment variables to direct the Delphi
compiler to the correct Indy10 dirs where all files were collected.
Different IDE paradigm of course....
--
Bo Berglund
Developer in Sweden

--
Martin Schreiber via Lazarus
2018-10-29 07:00:03 UTC
Permalink
This post might be inappropriate. Click to display it.
Bo Berglund via Lazarus
2018-10-28 09:47:40 UTC
Permalink
On Sun, 28 Oct 2018 00:49:50 +0200, Sven Barth via Lazarus
Post by Sven Barth via Lazarus
That something is pulling in unit Interfaces is proof that something tries
to use GUI units. So either find out what unit that is (it could either be
one of yours or maybe an Indy one) or try to set the LCLWidgetType to NoGUI.
SVEN, THANK YOU VERY MUCH!!!
-----------------------------
This was a project option I did not know about before and then not how
to set it.
But after a bit of google use I found the way:

- open Project/ProjectOptions/CompilerOptions/AdditionsAndOverrides

- In this dialogue there is a dropdown above the listbox named:
Set "LCLWidgetType" drop it down and find the entry
"Value nogui"
and select it

- OK to the main window and select Run/Build

This will rebuild the indylaz package and then the main application,
which now starts OK also with noone logged on to the main window.

It still needs the Interfaces entry under uses, though!
But if I comment it out then it is not discovered until linking the
application....

I always thought that options like these could be set in similar ways
as the {$mode objfpc}{$H+} in the main project file.
Maybe it is also possible? If so what is the correct syntax?
I would like to have it visible in the source if ever possible.
--
Bo Berglund
Developer in Sweden

--
Michael Van Canneyt via Lazarus
2018-10-28 10:41:51 UTC
Permalink
Post by Bo Berglund via Lazarus
On Sun, 28 Oct 2018 00:49:50 +0200, Sven Barth via Lazarus
Post by Sven Barth via Lazarus
That something is pulling in unit Interfaces is proof that something tries
to use GUI units. So either find out what unit that is (it could either be
one of yours or maybe an Indy one) or try to set the LCLWidgetType to NoGUI.
SVEN, THANK YOU VERY MUCH!!!
-----------------------------
This was a project option I did not know about before and then not how
to set it.
To be fair:

Mattias suggested this already earlier in the thread than Sven. It was one
of the first replies.

Michael.
--
Sven Barth via Lazarus
2018-10-28 11:39:50 UTC
Permalink
Post by Sven Barth via Lazarus
Post by Bo Berglund via Lazarus
On Sun, 28 Oct 2018 00:49:50 +0200, Sven Barth via Lazarus
Post by Sven Barth via Lazarus
That something is pulling in unit Interfaces is proof that something
tries
Post by Bo Berglund via Lazarus
Post by Sven Barth via Lazarus
to use GUI units. So either find out what unit that is (it could either
be
Post by Bo Berglund via Lazarus
Post by Sven Barth via Lazarus
one of yours or maybe an Indy one) or try to set the LCLWidgetType to
NoGUI.
Post by Bo Berglund via Lazarus
SVEN, THANK YOU VERY MUCH!!!
-----------------------------
This was a project option I did not know about before and then not how
to set it.
Mattias suggested this already earlier in the thread than Sven. It was one
of the first replies.
Indeed. And in another mail I had written as well that Mattias had
suggested that already.

Regards,
Sven
Bo Berglund via Lazarus
2018-10-28 16:22:50 UTC
Permalink
On Sun, 28 Oct 2018 11:41:51 +0100 (CET), Michael Van Canneyt via
Post by Michael Van Canneyt via Lazarus
Post by Bo Berglund via Lazarus
On Sun, 28 Oct 2018 00:49:50 +0200, Sven Barth via Lazarus
Post by Sven Barth via Lazarus
That something is pulling in unit Interfaces is proof that something tries
to use GUI units. So either find out what unit that is (it could either be
one of yours or maybe an Indy one) or try to set the LCLWidgetType to NoGUI.
SVEN, THANK YOU VERY MUCH!!!
-----------------------------
This was a project option I did not know about before and then not how
to set it.
Mattias suggested this already earlier in the thread than Sven. It was one
of the first replies.
You are right! But at the time I was trailing in another direction and
I also did not know how to acctually effect it....
Thanks to Mattias also, of course!

I have been using Lazarus/FPC for a few years on RaspberryPi units and
there I have also programmed utilities that run as command line
programs and I had no problem with these. So I was stunned by this
happening and really suspected something else entirely....
Of course these utilities were used on the RPi itself. But I was
always connecting to the RPi using TightVNC or later RealVNC.
I have never really had a monitor attached to any of my RPi units.
--
Bo Berglund
Developer in Sweden

--
Martin Schreiber via Lazarus
2018-10-28 06:46:34 UTC
Permalink
Post by Bo Berglund via Lazarus
But when I tried to build the project it complained that it could not
find Interfaces, so I remembered that this is supplied by LCL, so I
tried adding LCL back to the project required packages.
Then the project built OK.
Why don't you do what I suggested in order to find out which unit pulls in the
interfaces and gtk2 dependency?

In order to get the MSEunitdep tool do:
"
git clone https://gitlab.com/mseide-msegui/mseide-msegui.git
cd mseide-msegui
fpc -Fulib/common/* -Fulib/common/kernel/linux tools/unitdep/mseunitdep.pas
"
A work of less than a minute.

Martin
--
Juha Manninen via Lazarus
2018-10-27 15:00:56 UTC
Permalink
On Sat, Oct 27, 2018 at 4:35 PM Bo Berglund via Lazarus
Had to fix sections etc in the old dpr file so it now is a proper unit.
You have a .lpr file in the Lazarus project, right? Not .dpr?
But once done it built OK and worked as expected in Ubuntu 18.04.
The stripped size of this program as about 10 Mb whereas the earlier
version was only some 7 Mb...
With LCL it was 7 Mb and without LCL 10 Mb. Strange.
There is no unit called LicMgr in FPC or Lazarus sources. Is it part
of your project?

BTW, the Delphi converter is buggy if it adds LCL dependency for a
console program. It should not.
If you send me a test program then I can have a look.

Juha
--
Bo Berglund via Lazarus
2018-10-27 16:11:46 UTC
Permalink
On Sat, 27 Oct 2018 18:00:56 +0300, Juha Manninen via Lazarus
Post by Juha Manninen via Lazarus
On Sat, Oct 27, 2018 at 4:35 PM Bo Berglund via Lazarus
Had to fix sections etc in the old dpr file so it now is a proper unit.
You have a .lpr file in the Lazarus project, right? Not .dpr?
In the converted Delphi project I started with a .dpr file that
contained all active code except for two units to read Ini files mor
easily and to create Unix style hashed passwords.
When it was done it still used the dpr file as the main program
source.
Post by Juha Manninen via Lazarus
But once done it built OK and worked as expected in Ubuntu 18.04.
The stripped size of this program as about 10 Mb whereas the earlier
version was only some 7 Mb...
With LCL it was 7 Mb and without LCL 10 Mb. Strange.
There is no unit called LicMgr in FPC or Lazarus sources. Is it part
of your project?
My program is called LicMgr because it ie meant to create and send
demo licenses to people asking on our website.
For this it needs to:
- Read incoming email (Indy 10)
- Parse the messages for validity
- If valid:
- Create a new login entry on the server, so it needs to:
- Read the password file from the server using FTP (Indy10)
- Add the new entry to the end
- Make sure there is not already a duplicate
- Upload the modified password file (Indy10)
- Compose an email to the customer with a link and login
- Send the email (Indy10)
- Log all activity including saving who is getting logins
Post by Juha Manninen via Lazarus
BTW, the Delphi converter is buggy if it adds LCL dependency for a
console program. It should not.
Well, I created a new project from scratch and added in my units,
still the same problem.
Post by Juha Manninen via Lazarus
If you send me a test program then I can have a look.
I will try to make one from scratch and see what happens.
If still the same then I might take you up on that...
--
Bo Berglund
Developer in Sweden

--
Sven Barth via Lazarus
2018-10-27 15:46:22 UTC
Permalink
Post by Bo Berglund via Lazarus
After conversion it complained about directive {$APPTYPE CONSOLE}
being unrecognized so I had to IFNDEF FPC that line so it is only
visible in Delphi (which I rarely use these days)...
It's only a warning, not an error. The $AppType directive is only handled
on targets that have a distinction
for binary types (e.g. Windows which has GUI and Console or Classic Mac OS
which has Tool). Unix-like systems like Linux do not differ between console
and GUI programs in that way and thus the directive is ignored(!) there.

Regards,
Sven
Loading...