Pierre Muller wrote:
As stated in my other email, the whole purpose of this patch is not to determine if the source was compiled by GPC, but to get the command 'start' to end up at the right location. This right location is either '_p_M0_main_program' or 'pascal_main_program' (or 'program_Foo' for very old version, that my patch will not support.)
Assuming that the main program is compiled by GPC looking for '_p_M0_main_program' or 'pascal_main_program' should work fine. However, if the main program was compiled by some other compiler the program in principle may still contain such magic symbol -- using it as start location would be wrong.
In the 'demos' subdirectory of gpc tarball one can find files 'gpc_c_pas.pas', 'gpc_c_unit.pas' and 'gpc_c_c.c' -- this is a demo program showing how to make main program in C but use from it Pascal routines. In this example '_p_M0_main_program' is never called and the right location for 'start' command is C main. It is easy to create mixed mode program without fake '_p_M0_main_program', but unfortunately the demo creates fake '_p_M0_main_program'.
Another possibility is program in other language (or compiled by some other Pascal compiler) which happens to contain 'pascal_main_program'. I hope that '_p_M0_main_program' is very unlikely to appear in non-GPC program, but 'pascal_main_program' is a reasonable name so it makes sense to look for confirmation that the program is GPC compiled.
'_p_initialize' indicates presence of GPC runtime (so it really does not help in case of mixed mode programs). I should also mention that there was a report that 'libplot' library also contains '_p_initialize' function...
I also mentioned shared libraries. Now I think that they pose no extra problem -- presumably 'start' command will go to a symbol in main executable and just ignore shared libraries.