Recent

Author Topic: Unused code in linked program (Mac OS)  (Read 1327 times)

440bx

  • Hero Member
  • *****
  • Posts: 1922
Re: Unused code in linked program (Mac OS)
« Reply #15 on: December 13, 2019, 06:12:53 am »
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  :P
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.


FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

PascalDragon

  • Hero Member
  • *****
  • Posts: 1921
  • Compiler Developer
Re: Unused code in linked program (Mac OS)
« Reply #16 on: December 13, 2019, 09:20:09 am »
Linker is shipped by the platform itself. How to fix?

Ask platform maintainers. File a bug with their systems.

 ;D

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  ;D

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  8-)
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

  • Hero Member
  • *****
  • Posts: 814
  • Former Delphi 1-7 and 10.2 User
Re: Unused code in linked program (Mac OS)
« Reply #17 on: December 13, 2019, 12:43:14 pm »
I'm on OpenIndiana and DFBSD and would confirm it's has no effect  8-)
The only way to reduce binary size is run strip --strip-all binaryfile  8)

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

Quote
-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:

Quote
      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.
o Lazarus v2.1.0 r63598, FPC v3.3.1 r45778, macOS 10.14.6 (with sup update), Xcode 11.3.1
o Lazarus v2.1.0 r61574, FPC v3.3.1 r42318, FreeBSD 12.1 amd64 (Parallels VM)
o FPC 3.0.4, FreeBSD 12-STABLE r361007 amd64
o Lazarus v2.1.0 r61574, FPC v3.0.4, Ubuntu 18.04 (Parallels VM)

guest64953

  • Guest
Re: Unused code in linked program (Mac OS)
« Reply #18 on: December 14, 2019, 05:22:16 pm »
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  :P
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  ;D

guest64953

  • Guest
Re: Unused code in linked program (Mac OS)
« Reply #19 on: December 14, 2019, 05:26:28 pm »
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  ;D

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

  • Guest
Re: Unused code in linked program (Mac OS)
« Reply #20 on: December 14, 2019, 05:27:55 pm »
I'm on OpenIndiana and DFBSD and would confirm it's has no effect  8-)
The only way to reduce binary size is run strip --strip-all binaryfile  8)

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

Quote
-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:

Quote
      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

  • Hero Member
  • *****
  • Posts: 814
  • Former Delphi 1-7 and 10.2 User
Re: Unused code in linked program (Mac OS)
« Reply #21 on: December 17, 2019, 12:47:20 am »
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.
o Lazarus v2.1.0 r63598, FPC v3.3.1 r45778, macOS 10.14.6 (with sup update), Xcode 11.3.1
o Lazarus v2.1.0 r61574, FPC v3.3.1 r42318, FreeBSD 12.1 amd64 (Parallels VM)
o FPC 3.0.4, FreeBSD 12-STABLE r361007 amd64
o Lazarus v2.1.0 r61574, FPC v3.0.4, Ubuntu 18.04 (Parallels VM)

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8553
  • FPC developer.
Re: Unused code in linked program (Mac OS)
« Reply #22 on: December 17, 2019, 12:26:18 pm »

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  ;D

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

  • Hero Member
  • *****
  • Posts: 814
  • Former Delphi 1-7 and 10.2 User
Re: Unused code in linked program (Mac OS)
« Reply #23 on: December 17, 2019, 12:42:20 pm »
I think you're right about LLVMing. From the 2008 WWDC:

Quote
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?
o Lazarus v2.1.0 r63598, FPC v3.3.1 r45778, macOS 10.14.6 (with sup update), Xcode 11.3.1
o Lazarus v2.1.0 r61574, FPC v3.3.1 r42318, FreeBSD 12.1 amd64 (Parallels VM)
o FPC 3.0.4, FreeBSD 12-STABLE r361007 amd64
o Lazarus v2.1.0 r61574, FPC v3.0.4, Ubuntu 18.04 (Parallels VM)

 

TinyPortal © 2005-2018