Unused code in linked program (Mac OS)

[440bx]

p/s: Oh, you are using Windows. MinGW compiled binary is notoriously known as big and bloated on Windows, you should have compare with MSVC or Pelles C compiled binary to be fair 

The same program compiled with MSVC is roughly twice as large as the FPC version.  In addition to that, it requires msvcrtxxx.dll, IOW, it is not even a standalone executable.

[PascalDragon]

Linker is shipped by the platform itself. How to fix?

Ask platform maintainers. File a bug with their systems.

 

The fault should be yours, for generating incompatible or faulty ld script or do not adapt to platform specific parameters but not the other way around. Run man ld on these different platforms and you will see how different it is in the way how it work and the parameters it use. Just because it's named binutils or the binary name is ld and being used/available across many system doesn't mean it's all the same binutils/ld on Linux. They're not using the plain binutils, they patched it, forked it... they added their own customization... Your problem is you're so Linux centric so you bring all of this linuxism expectation to other platform 

I think we are a bit disrepect other system other than the main ones (Win, Lin and Mac). If it's Mac will you ask Apple to patch their linker to allow fpc to work correctly or you have to patch fpc to be work correctly with Apple's linker and adapt yourself to Apple's way, too? Just because Mac is a popular one so we have to support it, to follow it and other system is less popular so we think we should force them to patch their own only to allow our software to work correctly? It will not happen. fpc is not that important, gcc is another story, though. No one will answer to your bug report at all, they already have so many of them openning, so many important problems to care about 

It is not our task to fix broken platform tools. Same happens on the "major" platforms by the way. Some versions ago there was a bug in binutils (which we use ld and as) from which suddenly resulted in build errors. Guess what: a new version of the binutils fixed it.

Though I agree that one should at least investigate what is going wrong when compiling on OpenIndiana.

[trev]

I'm on OpenIndiana and DFBSD and would confirm it's has no effect 
The only way to reduce binary size is run strip --strip-all binaryfile 

It also has no effect on macOS, presumably because the man page for ld(1) states:

-s          Completely strip the output, including removing the symbol table.  This
               file format variant is no longer supported.  This option is obsolete.

and the man page for strip(1) states:

      If  the  file  does  not  use  the dynamic  link  editor,  the effect of strip without
      any options is the same as using the -s option of ld(1).

So the solution, at least for macOS, is to use strip(1) to strip because the linker ld(1) no longer does at least in macOS 10.14 [subsequent research found the option was not working as far back as September 2011 at which point it was outputting a warning "ld: warning: option -s is obsolete and being ignored"].

Any suggestion to "fix the linker" is less than helpful when it is a deliberate design decision by the maintainer of the platform, in this case being Apple. There are many native platform idiosyncrasies that FPC must take into account and this is but one of them.

[guest64953]

p/s: Oh, you are using Windows. MinGW compiled binary is notoriously known as big and bloated on Windows, you should have compare with MSVC or Pelles C compiled binary to be fair 

The same program compiled with MSVC is roughly twice as large as the FPC version.  In addition to that, it requires msvcrtxxx.dll, IOW, it is not even a standalone executable.

I said it a bit unclear. C++ is always bigger than FPC. FPC is something between C and C++. C++ is bloat by design, the more you use template, the bloater it is. Comparing FPC with C++ is unfair.

MinGW produces the biggest/bloatest binary.

MSVC is a bit better because they don't have the MinGW's problem (MinGW is GNU on Windows if you wonder, it's something as a layer to port and compile GNU source code on Windows but not optimized for just Windows like MSVC, which is Windows' native compiler, they are even provide library winpthread to emulate posix thread on Windows, there are many flavor of the compiler, which seh, sjlj or dwarf exception handling, win32 thread or posix thread...), and they also cheat with the redistribute package.

The real one should be Pelles C. Standalone executable with debug info embedded and still lighter than FPC.

But anyway, all of this is meaningless. I said there is a bug with FPC itself causing it to generate big and bloated binary on other platforms other than Windows and Linux. Your posts are fallible, after all 

[guest64953]

It is not our task to fix broken platform tools. Same happens on the "major" platforms by the way. Some versions ago there was a bug in binutils (which we use ld and as) from which suddenly resulted in build errors. Guess what: a new version of the binutils fixed it.

Though I agree that one should at least investigate what is going wrong when compiling on OpenIndiana.

No, man. The platform specific tools are not broken. They're working just fine with other compiler, gcc, g++, gfortran, gnat... but only our FPC has problem. We have to fix our own 

And it's not just on OI. On platforms other than Windows and Linux all suffered: Mac (the OP), OI and DFBSD (me), and many more platforms where fpcupdeluxe up and running, waiting us to uncover 

[guest64953]

I'm on OpenIndiana and DFBSD and would confirm it's has no effect 
The only way to reduce binary size is run strip --strip-all binaryfile 

It also has no effect on macOS, presumably because the man page for ld(1) states:

-s          Completely strip the output, including removing the symbol table.  This
               file format variant is no longer supported.  This option is obsolete.

and the man page for strip(1) states:

      If  the  file  does  not  use  the dynamic  link  editor,  the effect of strip without
      any options is the same as using the -s option of ld(1).

So the solution, at least for macOS, is to use strip(1) to strip because the linker ld(1) no longer does at least in macOS 10.14 [subsequent research found the option was not working as far back as September 2011 at which point it was outputting a warning "ld: warning: option -s is obsolete and being ignored"].

Any suggestion to "fix the linker" is less than helpful when it is a deliberate design decision by the maintainer of the platform, in this case being Apple. There are many native platform idiosyncrasies that FPC must take into account and this is but one of them.

At least there is one people actually understand the problem 

[trev]

I went back through the source code man pages for Xcode on https://opensource.apple.com and found that Xcode 2.5 (early 2005) included the strip option but it was confined to 32 bit software only. By the time of Xcode 3.1 (late 2007), the option was marked as obsolete and no longer supported. So it was at the time of Apple's transitioning to 64 bit that the option was dropped.

[marcov]

The fault should be yours, for generating incompatible or faulty ld script or do not adapt to platform specific parameters but not the other way around. Run man ld on these different platforms and you will see how different it is in the way how it work and the parameters it use. Just because it's named binutils or the binary name is ld and being used/available across many system doesn't mean it's all the same binutils/ld on Linux. They're not using the plain binutils, they patched it, forked it... they added their own customization... Your problem is you're so Linux centric so you bring all of this linuxism expectation to other platform 

It worked fine with binutils before they started LLVMING.  I suspect some files are aliases for the LLVM aliases that are simply not as far as long yet. Or they prefer to keep the functionality in strip.

[trev]

I think you're right about LLVMing. From the 2008 WWDC:

Xcode 3.1 introduces two new compilers for Mac OS X: GCC 4.2 and LLVM-GCC. Learn how the new security and performance improvements in GCC 4.2 can help you produce better applications. Understand the innovations in LLVM-GCC, and find out how you can use it in your own testing and development. Finally, get a preview of future compiler developments.

And you're right again when you say that Apple prefers to keep the functionality in the strip utility.

Do we need to file a bug report for the macOS  FPC linker script?