In the process of cross-compiling from Win64 to Solaris, I came across a situation where the compiler created a damaged program file. Conducted research on the problem. Since my English proficiency is not very good, but I asked the AI to formulate a bug report in English:

Subject: Potential filename truncation in Linker Script generation (t_sunos, t_linux, t_bsd)

Description:
While cross-compiling from Win64 to Oracle Solaris, I discovered that the generated linker command line contains corrupted paths. Specifically, the -Map file path is truncated to exactly 40 characters (or less, appearing as 8.3-like truncation in some cases), leading to collisions where the Map file and the Output binary have the same name, resulting in a corrupted executable.

Root Cause:
The issue lies in several linker modules where command-line fragments are stored in fixed-length strings (e.g., string[40], string[60]). When the project is located in a deep directory structure (common in Windows environments), the path plus the linker flag exceeds this limit and is silently truncated.

Affected files and variables:
compiler/systems/t_sunos.pas:
StripStr, StaticStr, RedirectStr are declared as string[40]. DynLinkStr is declared as string[60].
compiler/systems/t_linux.pas:
StripStr, StaticStr, GCSectionsStr are declared as string[40]. compiler/systems/t_bsd.pas:
StripStr, StaticStr, GCSectionsStr are declared as string[63]. DynLinkStr is declared as string[60].

Steps to reproduce:
Create a project in a deep directory (e.g., path length > 35 chars). Enable Map file generation (-Xm).
Cross-compile for Solaris/Linux/BSD.
Observe the linker call via -vt: the -Map argument will be truncated.

Suggested Fix:
Replace fixed-length string declarations (string[N]) with TCmdStr in the MakeExecutable and MakeSharedLibrary methods of the affected units.

P.S. My path for output binary was
"D:\Work\CFW_RTL\DevHelpers\H1_Stack". Not so long, but already give problem.