Hi, I would like to know if anyone has compiled Lazarus in a headless machine.

I ask this because I want to compile it on a FreeBsd server without X, and it is stopping with the "/usr/bin/ld: cannot find -lgdk_pixbuf-2.0".

You could try with the nogui widgetset.

But I'm not sure that this is very useful :-)

Michael.

It compiled with gmake LCL_PLATFORM=nogui

And it is useful to me, I just want to compile web apps in this server.

In that case, you can just build 'lazbuild' and compile them on the command-line.

make lazbuild

should do it.

Michael.

Leonardo M. Ram? wrote

It compiled with gmake LCL_PLATFORM=nogui And it is useful to me, I just want to compile web apps in this server.

In this case compile the app on a system with a GUI, look at the '<projectname>.compiled' file. Copy the compiler parameters out into a script and use that on the server. I'm been doing this for years on our headless server.

Alternatively, you can create a fpmake.pp for your project (more work, but same result as the first option).

Thanks to both, Graeme and Michael.

Leonardo M. Ram? wrote

Hi, I would like to know if anyone has compiled Lazarus in a headless machine.

I did a lot of research on that behalf (additional issue for me: it would not be an X86 machine).

Some results:

Latest results and most important result: It does not make much sense to search for a solution in user software, as nowadays any decent machine has enough resources to allow for a widget set (QT or GTK) and an X server, that can be accesses remotely via VNC or NX.

So here are the options i found (decreasing viability)

A) remotely access a local X server: VNC or (supposedly better) NX you locally need a widget set (QT or GTK) unless you use the FPGUI widget type) and an X server

B) access a remote X server (remote Linux: Standard, remote Windows: there are some free X-Servers)
you locally need a widget set (QT or GTK) unless you use the FPGUI widget type). The user software can only run if a remote X server is accessible. It needs to be started vis telnet or SSH

C) create a HTTP based remote GUI (see several threads here. Some keyword are "EXTJS", "EXTPASCAL", "FAST-CGI"
A problem here is that there is no Widget set without a GUI binding that allows for "normal" event driven Object.-Pascal programming with TTimers and inter.-Thread-Messages. using MSE instead of Lazarus might help on that behalf.

D) create a propriety remote GUI by using your own communication objects instead of the normal GUI Objects. A Lazarus program on the remote PC would provide the appropriate graphical implementation. A problem here is that there is no Widget set without a GUI binding that allows for "normal" event driven Object.-Pascal programming with TTimers and inter.-Thread-Messages. using MSE instead of Lazarus might help on that behalf. MSE (and myself) dis some first steps to create a "Widget Type" that contains those

E) drop the graphics and do a TCL-TK alike "TUI" program that can be accessed via Telnet or SSH.
Again Lazarus does not have a Widget Type for this. Using the IDE provided by FPC might help.

F) do a command line tool that can be accessed via Telnet or SSH Here no event driven programming is possible.

-Michael

This tool exists and is installed with Lazarus: lazbuild.

It's all you need if you just need to compile. You don't need a GUI to be able to just compile a program.

All the rest are complicated ways of trying to do something you're not supposed to do in the first place: develop on a production machine.

As I understood it, Leonardo just needs a tool to compile a lazarus project on a server. Not develop or debug. So lazbuild is the tool to use.

Michael.

Op 2010-11-03 13:20, Michael Schnell het geskryf:

So here are the options i found (decreasing viability)

As Michael said, the original poster simply wanted to compiler a GUI project on a remote server. That is easy (scripts, lazbuild, SSH etc). Running GUI apps on a remote headless linux server is possible too. Google Fake X11 Server (I can't remember the exact name), but I used it for about two years to run tiOPF's unit tests while cleaning up the core tiOPF code until it was 100% GUI free.

widget type). The user software can only run if a remote X server is accessible. It needs to be started vis telnet or SSH

I have many times used SSH to connect to our remote 64-bit Linux server, loaded my own GUI ide which displays on my system (not server), compile and run the GUI app. Now I have my own 64-bit machine, so don't need to do this any more. Running GUI apps remotely using Linux is simple:

ssh -X

Then simply run the GUI app. Output will appear on your local desktop.

A problem here is that there is no Widget set without a GUI binding that allows for "normal" event driven Object.-Pascal programming with TTimers and inter.-Thread-Messages.

Give me another month or two to complete the Linux FrameBuffer backend to fpGUI, then this will be possible too. :)

F) do a command line tool that can be accessed via Telnet or SSH

For the original poster, this was enough to compile his application.

Regards,
- Graeme -

That does sound great. Please let me know when I can test this.

-Michael

I usually work over VNC since most machines here are headless. I've seen a few problems which I think are down to things like dpi mismatch but in general it works well.

I've not done this very much since gtk v2 became preferred since Lazarus (and a few other programs) had performance issues for a while. I've seen recent problems with KDE v4 on a headless system which seems to assume that the remote X server (i.e. the "X terminal" running on the computer in front of me) has extensions and colour depth which might not be available on older systems.

Michael Schnell wrote

E) drop the graphics and do a TCL-TK alike "TUI" program that can be accessed via Telnet or SSH. Again Lazarus does not have a Widget Type for this. Using the IDE provided by FPC might help.

Why use an ugly TCL TUI, if the most perfect TUI library is included with FPC?

That will only work if ssh and sshd are configured correctly. I don't know about Ubuntu, but at least in ArchLinux one has to allow remote X access and some other things. (I'm not at my Linux computer currently, so I can't look it up...)

Regards,
Sven

Graeme Geldenhuys wrote

Give me another month or two to complete the Linux FrameBuffer backend to fpGUI, then this will be possible too. :)

Some months ago, I did some research on VNC. I was able to install the free VNC server software on an embedded Linux target (non PC) in a way that an array of bytes in the memory could be accessed by a standard VNC client running on a PC (e.g. Windows).

If this would be combined with your work, this would result in an excellent solution for headless embedded devices. #

-Michael

Marco van de Voort wrote

Why use an ugly TCL TUI, if the most perfect TUI library is included with FPC?

TCL is more well-known than Free Vision, so I called it "TCL-alike". But I did speak of the Turbo Pascal TUI.

-Michael

Op 2010-11-04 10:19, Sven Barth het geskryf:

You don't need to set X remote permissions (like in the olden days) and no need to export the DISPLAY environment variable. SSH handles everything for you and all traffic is going through the SSH protocol and port. As long as the remote server runs a SSH daemon so you can connect to it, it will work. Well at least so it has for the last couple of years on our Linux servers.

Regards,
- Graeme -

Then you've never set up an ArchLinux system ^^

Cause I make that mistake every time I set up my server (and forgot to backup the sshd_config file)...

Regards,
Sven

Op 2010-11-04 12:06, Sven Barth het geskryf:

Then you've never set up an ArchLinux system ^^

Very true, I have never seen or used ArchLinux. We have standardised on Ubuntu desktops and servers. In the latter case, 'ssh -X' works out of the box.

Regards,
- Graeme -

Graeme Geldenhuys wrote

You don't need to set X remote permissions

Man ssh says:

-X Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file.

X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database)
can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.

For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh -Y option and the ForwardX11Trusted
directive in ssh_config(5) for more information.

-x Disables X11 forwarding.

-Y Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.