In the apache module examples in /fpc/packages/httpd22/examples/ all of them has a

"Free Pascal only supports exporting variables on Windows" note there
and something like
{$ifdef WINDOWS}
exports
  test_module name 'test_module';
{$endif}

With Apache 2.2.8 and 2.2.9 (the two I can test) on Linux the apache modules compiled with fpc/lazarus all give the "Can't locate API module structure" error when trying to load them at apache startup.

I noticed that if I remove the ifdef above and leave the exports there it compiles and apache actually loads the module (doesn't work though for me yet when trying to do a request). At least there is no error message when apache starts up.

Is the "exports" now supported in Linux or it's a glitch that apache loads the modules with the exports in them?

Thanks,

AB

ABorka wrote

Is the "exports" now supported in Linux or it's a glitch that apache loads the modules with the exports in them?

It is now supported, as long as the "exports" name is the same as the original variable's name.

Jonas

Thanks, Jonas.

Any suggestion why apache 2.2.8 does not want to load the FPC compiled apache modules (ex: mod_hello.pp in packages/httpd2/examples) on Linux?

.
.snip
.
{$define Apache2_2}
uses SysUtils, httpd {$ifndef Apache1_3}, apr{$endif};

var
  test_module: module; public name 'test_module';
{*******************************************************************
*  Free Pascal only supports exporting variables on Windows
*******************************************************************}
{$ifdef WINDOWS}
exports
  test_module name 'test_module';
{$endif}
.
.snip
.
begin
   default_module_ptr := @test_module;
   FillChar(default_module_ptr^, SizeOf(default_module_ptr^), 0);
     STANDARD20_MODULE_STUFF(test_module);
     with test_module do
     begin
       name := MODULE_NAME;
       register_hooks := @RegisterHooks;
     end;
end.

does not work ("Can't locate API module structure"). The length of module_struct (module = module_struct) is correct compared to the C compiled working apache modules.
Did these example programs work before fpc supported "exports test_module"?

Jonas Maebe wrote

On 28 Sep 2008, at 10:15, ABorka wrote: > Is the "exports" now supported in Linux or it's a glitch that apache

loads the modules with the exports in them?

It is now supported, as long as the "exports" name is the same as the

original variable's name.

ABorka wrote

Any suggestion why apache 2.2.8 does not want to load the FPC compiled apache modules (ex: mod_hello.pp in packages/httpd2/examples) on Linux?

Some time ago I suggested for you to test older apache versions. I
still suggest that. Also try Apache 2.0. If older versions work, then
we should start looking for what changed. If not even that works then
look for something more basic.

It works under Windows with apache 2.2.9 which is even newer version, but not on Linux with apache 2.2.8 . Is it still needed to be checked on older Apache versions?

ABorka wrote

It works under Windows with apache 2.2.9 which is even newer version, but not on Linux with apache 2.2.8 . Is it still needed to be checked on older Apache versions?

Yes, it's a linux specific problem. You need to compare versions running in Linux.

OK, I'll see what can I do to get some older apache into a Linux install to test it.

Did some more tests meanwhile, if the ap_hook_handler is executed below, all the modules loaded after this one in the apache2.conf, are stop working (always returning an empty page). If it is commented out, they are OK.
So something is probably wrong with the Defaulthandler function declaration on Linux - or something - that breaks the module chain after the fpc compiled module. Also, the Defaulthandler is not called (not even the first instruction is executed in it ever).

function DefaultHandler(r: PRequest_Rec): Integer; cdecl;
...snip...
procedure RegisterHooks(p: Papr_pool_t); cdecl;
begin
   ap_hook_handler(@DefaultHandler, nil, nil, APR_HOOK_MIDDLE);
end;

The module_struct declaration is OK theoretically because the Registerhooks procedure is called after the module is loaded by apache.

wow, I just downloaded the source code of apache 2.2.9 and I can't even find ap_hook_handler! o.O I think they removed the function.

I just looked at the apache 2.2 fpc headers, and the version info is missing. I somehow forgot to write in which apache version the translation was based.

based on the huge difference between our headers and the c headers that I see, I think that the entire fpc apache 2.2 headers need to be reviewed.

But I am really confused. How could apache 2.2 change so much? Maybe it was still experimental when I did the initial translation?

And what substitutes ap_hook_handler?

My only short term solution for you would be: Use apache 2.0

The longer solution is: the apache 2.2 headers need a full review and update.

Doing the C header to Pascal conversion is very easy, but a large manual work. I followed some guidelines which should be kept. The c headers are converted manually and things should be the same places as in the c headers, unless impossible because pascal requires them to be in the same type statement or something similar. The version upon which the conversion was last checked needs to be written

:)

The C example still works with ap_hook_handler, maybe they made it a macro or something?

I believe the translation was for apache 2.2.3 header files, based on the ap_mmn.inc included in fpc/packages/httpd22
In the comments there we can see

* 20051115.2 (2.2.2) added inreslist member to proxy_conn_rec (minor)
* 20051115.3 (2.2.3) Added server_scheme member to server_rec (minor) }
as last entry. The same file for apache 2.2.9 continues with more entries to

* 20051115.2 (2.2.2) added inreslist member to proxy_conn_rec (minor)
* 20051115.3 (2.2.3) Added server_scheme member to server_rec (minor)
* 20051115.4 (2.2.4) Added ap_get_server_banner() and
* ap_get_server_description() (minor)
* 20051115.5 (2.2.5) Added ap_mpm_safe_kill() (minor)
* 20051115.6 (2.2.7) Added retry_set to proxy_worker (minor)
* 20051115.7 (2.2.7) Added conn_rec::clogging_input_filters (minor)
* 20051115.8 (2.2.7) Added flags to proxy_alias (minor)
* 20051115.9 (2.2.7) Add ap_send_interim_response API
* 20051115.10(2.2.7) Added ap_mod_status_reqtail (minor)
* 20051115.11(2.2.7) Add *ftp_directory_charset to proxy_dir_conf
* 20051115.12(2.2.8) Add optional function ap_logio_add_bytes_in() to mog_logio
* 20051115.13(2.2.9) Add disablereuse and disablereuse_set
* to proxy_worker struct (minor)
* 20051115.14(2.2.9) Add ap_proxy_ssl_connection_cleanup and
* add *scpool, *r and need_flush to proxy_conn_rec
* structure
* 20051115.15(2.2.9) Add interpolate_env to proxy_dir_conf and
* introduce proxy_req_conf.
*
*/

So from the
MODULE_MAGIC_NUMBER_MINOR = 3; // 0...n we can see it was 2.2.3 when translated for FPC

for apache 2.2.9, the MODULE_MAGIC_NUMBER_MINOR is 15

But the question is, if they changed it so much how come all this works for Windows then?

ABorka wrote

The C example still works with ap_hook_handler, maybe they made it a macro or something?

No, otherwise it wouldn't link ... a better investigation shows it is still there. It seams I made some mistakes (spotlight also didn't help me). I was looking at some http files which come with Mac OS X and they seam to have nothing to do with the standard apache files ...

Looking at the correct files they didn't change that much ... this moves us back considerably.

Also, then I instead of http_config.h! o.O I
need to sleep ...

And searching to ap_hook_handler obviously shows nothing, because they use their bizarre declaration method in apache.

Ok, I go back to my previous idea. Test it with an older apache (specially good would be 2.2.3).

Hi Felipe,

The problem is only there (checked now on apache 2.2.3 also with the latest svn fpc /11864/ and lazarus /16875/ trunk) if

{$ifdef WINDOWS}//!! not needed
exports test_module name 'test_module1';
{$endif}        //!! not needed

is there. If the ifdef is removed and the exports instruction is there, then apache loads the module without any errors on Linux.

An additional problem for me was that I've used a procedure to write to a log file for debugging purposes. It is working on Windows but on Linux it somehow puts the apache module execution into a black hole after it is called within the defaulthandler function (it is ok if it is called in the initialization section or in the RegisterHooks procedure):

procedure WriteToLogFile(MessageStr:String);
var f: textfile; LogFile:String;
begin
   LogFile := '/HTTPDebugLogFile.log';
   assignfile(f, LogFile);
   if not FileExists(LogFile) then ReWrite(f)
                              else Append(f);
   writeln(f, FormatDateTime('yyyy/mm/dd hh:mm:ss.zzz', Now) + ':' +
MessageStr);
   closefile(f);
end;

If the assignfile is called, it already screws the DefaultHandler execution even if the lines after it are commented out in the procedure. Any suggestion why? I've tried to use streams, same result.

AB

Felipe Monteiro de Carvalho wrote

Ok, I go back to my previous idea. Test it with an older apache (specially good would be 2.2.3).

Well, then FPC changed, and the old way to export variables on unixes doesn't work anymore. Looks like a regression, but it's not a too big problem. We can just change that in the examples and have less ifdefs.

is there. If the ifdef is removed and the exports instruction is there, then apache loads the module without any errors on Linux.

Does it also work (instead of only loading) without the ifdef and without you debuging code?

If the assignfile is called, it already screws the DefaultHandler execution even if the lines after it are commented out in the procedure. Any suggestion why? I've tried to use streams, same result.

wow, this is really strange. I cannot think of a reason why this would happen ... if noone else here has an idea I would ask in a apache mailling list. There may be some reason connected to the internal apache structure.

Previously, all public declarations were automatically exported from libraries under Unix. This was a bug. Now only what appears in the exports section is exported.

Variables can however not be renamed in the exports section under Unix (previously they were not allowed in the exports section at all).

Jonas

I've added this to http://wiki.freepascal.org/User_Changes_2.2.2#Exporting_of_library_variables_and_functions

Jonas

Does it also work (instead of only loading) without the ifdef and without you debuging code?

The mod_hello most basic example works (apache 2.2.3 and 2.2.8). But for now, not any vanilla apache module created with file->new->apache module in Lazarus on Linux works (apache 2.2.8, didn't test on 2.2.3) even with the exports changes. Even with only 1 default action in the web module saying "hello world" when called.

Yes, it is strange. And modules created through Lazarus on Linux have the same problem of returning an empty page no matter what. And there is no debugging log file writing in there. Not sure about stream useage though. We need to fix it in the hello_mod example first - since the little library is so simple - , I think it'll fix the apache modules created with Lazarus too.

There is also the problem of
WaitForThreadTerminate(BeginThread(@__dummythread), 300); never returning for me on Linux apache module library. This fixed the multiple simultaneous calls on windows, but on Linux it does not return. Might not even be needed, but for now cannot test it before the above is fixed. Just commented it out for now on Linux.