Angelo.Fumagalli@alcatel.it wrote:
to solve this internal error we passed to the last gpc version (gpc version 20050331, based on gcc-3.4.3) but unfortunately we got another unexpected problem related to "global" procedures names that have been changed respect the gpc 20041218. In fact the gpc 20050331 change the internal name of "global" procedures adding a variable prefix as, for examÚple, "_p_Mx_modulename_Sy_procedurename" instead the original "procedurename". For us this change loads big problem because, our pascal modules come from VAX/VMS and are structured to be exported as object library containing thousand of modules and some environment modules to be used as interface by application pascal modules. We have a lot of applicatons and the related pascal modules cannot use internal library modules as interface because don't know them but know only some (2 or 3) "library interface modules". So, porting our pascal modules under gpc the choise was to maintaining the original modules structures in terms of files, so we create the related gpc modules containing the proper interface to resolve the references to the library procedures, types and variables. The work around, to avoid gpc compilation errors, was to write procedure declarations using the "external name" extension, for example:
unit lbbe, interface procedure ios_txt_open (var f: text); external name 'Ios_txt_open'; procedure ios_txt_close (var f: text); external name 'Ios_txt_close'; /* other hundred and hundred of procedure declarations */
end.
Using gpc20050331 this approch don't work any more.
Relying on the default linker names was never reliable. The change you mention was *necessary* to implement qualified identifiers. This has been discussed here rather often. The reliable way to use linker names (if you can't use proper units or modules, which would be much simpler, for whatever reasons) is to declare the linker names where the routines are declared:
procedure ios_txt_open (var f: text); attribute (name = 'Ios_txt_open'); begin ... end;
Note, the respective changes were made in gpc-20030323, so there really was enough time for a "soft migration". Now, unfortunately, you might be forced to rush through it ...
The question is, there is a gpc option in order to disable this name building method
As I wrote above, it's not possible since identical identifiers in different modules would conflict on the linker level then.
or could you describe us this procedure name building algoritm?
We could, but I think we better didn't. ;-) Changing to the new names means just waiting for the next accident to happen. Declaring linker names or using proper units/modules will solve the problem once and forever, even if the default linker names will change again.
Frank