You are not logged in.
Pages: 1
Hello friends,
I'm trying to run a Mormot service on my old Centos 6.2 server but for some reason the Response is never returned.
wget http://127.0.0.1:8989 output
HTTP request sent, awaiting response.
Port 8989 is opened.
I tested with a simple lazarus TFPWebModule project using same port and the server response as expected.
So it's not really a problem with the port / firewall.
Finally, I created a simple server using only SynCrtSock unit and the response also never returns.
FHttpServer := THttpServer.Create('8989', @OnStart, @OnStop, 'root' );
FHttpServer.OnRequest := @OnHttpServerRequest;
...
function TServer.OnHttpServerRequest(Ctxt: THttpServerRequest): cardinal;
begin
writeln('OnRequest');
end;
procedure TServer.OnStart(Sender: TThread);
begin
writeln('OnStart');
end;
OnStart are called, but never OnHttpServerRequest.
I also tested on ubuntu and this is OK, performs perfectly.
It should be something specific with Centos. Has anyone had a similar problem?
Last edited by macfly (2019-06-06 15:09:59)
Offline
I suspect it's something with this older version.
Unfortunately I can not upgrade this server.
Offline
Can you install Lazarus on your Centos and debug?
Delphi XE4 Pro on Windows 7 64bit.
Lazarus trunk built with fpcupdelux on Windows with cross-compile for Linux 64bit.
Offline
No, this server is in production running some sites.
I will try to create a VM with the same version to test and debug locally.
As a temporary fix, I'm thinking of using a Lazarus http server, and this server would act as a standalone client-server, bypassing the mormot httpserver.
Last edited by macfly (2019-06-06 13:16:13)
Offline
Well, I managed to find the problem.
As this is an old OS, it has glibc 2.12.
However, applications compiled with FPC require at least glibc 2.14.
Since I can not upgrade to glibc 2.14 on this server, I have installed this version to run in parallel.
But even so there is some incompatibility and even loading 2.14 the httpserver does not respond.
I did not imagine that even if application does not depend on glibc, if that version 2.14 was loaded in session the error still occurs. This made it difficult to evaluate the test results.
In short:
To resolve, I removed what was causing the glibc dependency aka "SynSQLite3Static". Rebooted the server and now it's ok.
The saddest thing is that I was not going to use static linking. I just put this unit to test on windows and forgot to use a conditional to not include in linux.
Sorry to bother with a problem not related to the framework.
Last edited by macfly (2019-06-06 16:23:10)
Offline
Interesting.
Which endpoint makes a dependency in glibc 2.14 in SynSQLite3Static?
I would like to get rid of it if possible - unless it would mean use an old/unmaintained gcc compiler...
We currently use the FpcUpDeluxe gcc cross-compiler (6.3.0) to compile our own patched sqlite3.c amalgation file.
Offline
I could not see this because I can not install FPC on this server to debug.
But something that caught my attention a while ago, when I was having linkage problems using static linked in linux, is this:
{$ifdef CPU64}
{$L static/x86_64-linux\sqlite3.o}
{$ifdef FPC_CROSSCOMPILING}
{$linklib static/x86_64-linux\gcc.a}
{$endif}
const _PREFIX = '';
{$else}
Note that this is pointing to static/x86_64-linux\gcc.a
However, this "gcc.a" file does not exist.
The file in the "\static\x86_64-linux" folder is "libgcc.a"
Could the compiler be using its own version of gcc.a with dependency on 2.14?
Or is it really not necessary?
Offline
Pages: 1