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...

Either install libgtk2.0-0 or remove the dependency.

Maybe your project uses the LCL either directly or indirectly. See Project Inspector.
If yes, remove it or set it to lclwidgettype "nogui".

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

Mattias Gaertner wrote

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?

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

PM Bo Berglund wrote

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

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....

IMHO, that's the wrong approach.

You have to remove the dependency, somehow, not fulfill it.

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?

That is the problem, I don't know how to remove a dependency like this...

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

Bo Berglund wrote

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!

[...] (LicMgr:19450): Gtk-WARNING **: cannot open display: 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

PM Bo Berglund wrote

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.

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

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 wrote

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:
https://mseide-msegui.sourceforge.io/pics/mseunitdep.png

Martin

Bo Berglund via Lazarus schrieb am Sa., 27.
Okt. 2018, 14:31:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181027/a44b11c4/attachment.html>

Bo Berglund via Lazarus schrieb am Sa., 27.
Okt. 2018, 13:58:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181027/6ae74586/attachment-0001.html>

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.

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

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.

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...

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"

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....

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

Don't know how...

PM Bo Berglund wrote

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.

Indeed!
It is not only for the IDE integration. There are units with GUI that need LCL.

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.

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

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.

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 via Lazarus schrieb am So., 28.
Okt. 2018, 00:44:

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181028/0e7e9741/attachment.html>

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

I don't know either how to find it, but installing "missing" libraries on the server will not help, rather the contrary.

AM Sven Barth wrote

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.

NoGUI is a hack.
You should uninstall Indy from the IDE when you have its units directly in your project. I thought it was obvious but maybe not. Lazarus IDE gets confused when you have units from a registered package in your project.

Martin Schreiber and others, the GTK2 dependency comes from LCL. There is no question of it.
I just don't understand why it is so hard for Bo to remove it. Such a simple thing to do!
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?

Bo, please report a bug for Indy project. They should divide their package into two.

Juha

Juha Manninen wrote

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?
https://mseide-msegui.sourceforge.io/pics/indypath.png

Martin

Sven Barth wrote

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.

To be fair:

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

Michael.

Michael Van Canneyt via Lazarus schrieb am
So., 28. Okt. 2018, 11:41:

Indeed. And in another mail I had written as well that Mattias had suggested that already.

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20181028/62e474dd/attachment.html>

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.

Juha Manninen wrote

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....

As Juha writes, using NoGUI is a hack. You should find out which units pull in LCL and remove them. Different ways how to find out which units are affected already have been described in this thread, please read again.

Martin