lazarus @2.0.6: ./../ppaslink.sh: line 9: /opt/local/bin/ld: Argument list too long

[kencu (Ken)]

Reported upstream <​https://forum.lazarus.freepascal.org/index.php/topic,48572.0.html> as well.

Linking large fpc projects, such as when building and installing Lazarus, is generating link errors on several different versions of macOS (10.7, 10.13 noted so far) with several different versions of the linker (ld64), due to "Argument list too long."

For example, this build of lazarus on 10.7.5 using ld64-450:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_lazarus/lazarus/work/lazarus/ide/main.pp(239,39) Hint: (5024) Parameter "Sender" not used
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_lazarus/lazarus/work/lazarus/ide/main.pp(240,40) Hint: (5024) Parameter "Sender" not used
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_lazarus/lazarus/work/lazarus/ide/main.pp(423,35) Hint: (5024) Parameter "Sender" not used
(9001) Assembling (pipe) ../units/x86_64-darwin/cocoa/main.s
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_lazarus/lazarus/work/lazarus/ide/lazarus.pp(75,5) Hint: (5023) Unit "FPCUnitTestRunner" not used in Lazarus
(9001) Assembling (pipe) ../units/x86_64-darwin/cocoa/lazarus.s
(9022) Compiling resource ../units/x86_64-darwin/cocoa/lazarus.or
(9015) Linking ../lazarus
./../ppaslink.sh: line 9: /opt/local/bin/ld: Argument list too long
An error occurred while linking 
lazarus.pp(167) Error: (9013) Error while linking
lazarus.pp(167) Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted
make[2]: *** [lazarus] Error 1

It can be overcome by by choosing a build directory with a shorter pathname, on the same system, with the same toolchain.

/opt/local/var/macports/build/_opt_macports-ports_devel_lazarus/lazarus/work/lazarus/ide/main.pp(239,39) Hint: (5024) Parameter "Sender" not used
/opt/local/var/macports/build/_opt_macports-ports_devel_lazarus/lazarus/work/lazarus/ide/main.pp(240,40) Hint: (5024) Parameter "Sender" not used
/opt/local/var/macports/build/_opt_macports-ports_devel_lazarus/lazarus/work/lazarus/ide/main.pp(423,35) Hint: (5024) Parameter "Sender" not used
(9001) Assembling (pipe) ../units/x86_64-darwin/cocoa/main.s
/opt/local/var/macports/build/_opt_macports-ports_devel_lazarus/lazarus/work/lazarus/ide/lazarus.pp(75,5) Hint: (5023) Unit "FPCUnitTestRunner" not used in Lazarus
(9001) Assembling (pipe) ../units/x86_64-darwin/cocoa/lazarus.s
(9022) Compiling resource ../units/x86_64-darwin/cocoa/lazarus.or
(9015) Linking ../lazarus
(1008) 293660 lines compiled, 205.4 sec
(1021) 30 warning(s) issued
(1022) 3082 hint(s) issued
(1023) 1 note(s) issued
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_macports-ports_devel_lazarus/lazarus/work/lazarus/ide'

The file link.res that generates the error is indeed quite large, with most of the objects having full pathnames. It is cat ed onto the link line by the ppaslink.sh script. I think it is simply exceeding the ARG_MAX of the system.

$ ls -la ../link.res
-rw-r--r--  1 macports  admin  243910 18 Feb 19:22 ../link.res

Many larger projects (Mozilla, etc) have come up against this same issue over the years. The solution seems to be to pass the objects as a filelist to the linker using -filelist .

Unfortunately it appears that the existing link.res file cannot simply be used to do that, as it contains other linker commands such as -arch and other library references that my reading says Apple's ld64 does not allow in the filelist files.

I'm not sure if the link.res file can use shorter relative pathnames for at least some objects, or if we can configure it to do so somehow. Or how, exactly, the logic that makes link.res could be altered in some fashion to have it separate the linker commands and the object references into separate files, and then use the linker's -filelist feature.

MacPorts could be altered in some fashion to use a shorter path to it's build directory, and this would probably help a bit, but that is not so simple to accomplish, and sooner or later fpc / lazarus would run up against this ARG_MAX issue again it seems.

[kencu (Ken)]

Another option to consider would be to build a smaller initial version of lazarus with less objects, and then let people compile packages in later on if desired (using their much shorter user build path in ~/.lazarus which would be unlikely to show this error).

I'm not a fan of that idea, as it differs from the release version of lazarus, but it is probably the absolutely easiest thing to do on an immediate basis.

The target for that build would be "all" rather than "bigide".

[kencu (Ken)]

There is a fix in fpc trunk that is meant to fix this issue -- will see about how that works.

[kamischi (Karl-Michael Schindler)]

I had a quick look at the fix of fpc in svn commit 43485. For me, it seems isolated enough, that one could apply it as a fix to fpc 3.0.2 and test, whether the issue with lazarus is fixed then. This would avoid the need to test with current trunk of fpc and offer a stable solution until the next release of fpc, presumably 3.2. If this is successful, we should also request that the fix is applied to the 3.2-fixes branch, from which the next release will be created.

[kencu (Ken)]

fixed by fpc/lazarus update