I am trying to find the cause of a linker error when building my application on Linux.
While doing this I looked in the project file projname.lpi and found this strange entry:

<?xml version="1.0" encoding="UTF-8"?>
<CONFIG>
<ProjectOptions>
<Version Value="11"/>
<PathDelim Value="\"/>

Why is the path delimiter defined inside the project information file? And what are th consequences when moving the sources (via SVN) between Windows and Linux? Obviously this setting would be fals in one platform...

Seems like something that should be handled by FPC itself depending on the platform it runs on.

My project builds fine now on Linux but refuses to link successfully, could this be the reason?

It has started a series of messages about WSMenu items again for some unknown reason during linking.

wsmenus.pp(263,1) Error: undefined reference to `WSRegisterMenu'

I am not using wsmenus...

It is a non-GUI application intended to run as a Linux service... And the last time I had this problem pop up it was traced to LazSerial and/or SdpoSerial, which pull in a lot of GUI stuff. But these packages have been removed from the project.
I am now using a serial component based on the built-in serial unit so there should be no GUI dependencies.

Bo Berglund via fpc-pascal schrieb am
So., 27. Sep. 2020, 18:12:

It's for the other paths that are used in the project file.

Seems like something that should be handled by FPC itself depending on the platform it runs on.

FPC itself only handles the paths of the host platform (which means "/" on *nix and "/" as well as "\" on Windows).

Yes, you are, even if it is indirectly. Otherwise the compiler or linker wouldn't complain about it.

Regards,
Sven

It would be very good if the linker could be told to show a message saying from where the call to the missing identifiers came.

Now it just prints a long list of undefined references to WSxxx identifiers, without showing where the call that brought up wsmenus.pp came from. Like:
wsmenus.pp(263,1) Error: undefined reference to `WSRegisterPopupMenu'

Why is it there?

As it is now I have inspected all project units to see if there is any un-needed uses clause that might bring in GUI components.

The sources are rather big and many and they were originally created as part o´f a regular Windows program intrfacing the hardware. So there are a number of GUI items embedded, which I have hunted down and ifdef-ed out.
There are about 20 units comprising some 30-35000 lines of code. :(

I have used a conditional "GUI_MODE" to enable/block all uses of GUI calls like Message boxes and the like. Also to replace Application.ProcessMessages with Sleep() so I can condition away Forms in the uses clause on the GUI_MODE identifier (which is not set).

While doing this I found a number of calls to ShowMessage and similar dialogs. Now I have exhausted my list of units and it still happens. I even enabled the option LCLWidgetType:=nogui, but to no avail...

The only required packages for my application now are: LCLBase and indylaz. And if I remove LCLBase it still compiles OK but also still fails the link step.

In Delphi I believe it was possible to use for example Forms in a command line application so that Application.ProcessMessages could be called. But it seems not so with FPC/Lazarus.

Bo Berglund wrote

The only required packages for my application now are: LCLBase and indylaz. And if I remove LCLBase it still compiles OK but also still fails the link step.

I finally got it to compile!
What I did was to add Interfaces to the project file uses clause. Then it completed the build and link.
So in order to check up, I next unchecked the nogui widgetset setting and rebuilt the application.
Turns out that this seems to have no effect (visibly at least) so I am leaving it unset from now.

The application so built could be started and it responds like it is supposed to when using the client app to talk to it.

Seems like the Interfaces unit was the key...

Except, the application without nogui would not start when called from an SSH shell on the machine (like using PuTTY from Windows to start it).
It immediately crashes with a little text messafe referencing the GUI part.

But if I enable nogui and rebuild the application, then it will run both started from an SSH terminal and from a terminal in the GUI environment.

So Interfaces was needed to get rid of the wsmenus linking errors and nogui to make it run in all types of terminal.
Both necessary.

The linker *does* point you as good as possible at the location of the call, namely unit wsmenus.pp at line 263 which does contain a call to "WSRegisterPopupMenu". It *can't* do any better, because it does not know from where the surrounding "RegisterPopupMenu" is called (okay, not quite true: the linker knows *all* references to "RegisterPopupMenu", but do you really want to be flooded by a list of functions that in turn might need a list of functions each that they're called from and so on?)

Though admittably this specific case is even more complex, cause WSRegisterPopupMenu is declared as "external" and the "public" symbol is provided elsewhere, thus you won't get the compile error that a unit is missing.

I have used a conditional "GUI_MODE" to enable/block all uses of GUI calls like Message boxes and the like. Also to replace Application.ProcessMessages with Sleep() so I can condition away Forms in the uses clause on the GUI_MODE identifier (which is not set).

Your own units are not the only ones in your project. Indy is notorious for requiring GUI code if you pick the wrong units.

In Delphi I believe it was possible to use for example Forms in a command line application so that Application.ProcessMessages could be called. But it seems not so with FPC/Lazarus.

Lazarus is not Delphi. In Delphi this worked, because on Windows the GUI libraries are always available and Windows doesn't care if you use UI code in a "console" binary. On other systems (especially Linux and BSD) this might not be the case however, thus linking against e.g. GTK or Qt (which the LCL does depending on the widgetset) would just lead to "library not found" errors at the point you'd start the application. And trust me, on a headless system you don't *want* to install a complete X11 or Wayland stack just to get your program working. That is why the NOGUI widgetset was introduced. To give units that require GUI access (like some parts of Indy) the chance to work in CLI applications. Though of course it's even better to get rid of such dependencies, but Indy is big and thus one probably needs to adjust/rewrite quite some of their units to make sure that there are no unnecessary GUI dependencies...

Regards,
Sven

I think this rewrite of Indy has already happened quite some time ago: Indy works without GUI in Delphi as well. I use it in server applications on headless servers.

Michael.