Peter N Lewis wrote:
Peter Norton wrote: The issue (as I understand it for us) is two fold, the fact the no dead code stripping is done means that any code in any imported statically linked library is included with nothing removed, and then the size of the various libraries including the gpc runtime library.
The linker *can* strip dead code (as I understand it) per section, not per function. However, each section is referenced, because it contains the unit's initialization code (even if the initialization code does nothing). The nett result is that no dead code is stripped at all.
Although space is "cheap" these days, it is a pain since it limits what you can break down as small self contained utilities since each one is large.
I fully agree it's a pain.
I imagine the Windows version has the same issues.
I'm not sure if dead code stripping is something that the linker does on some platforms and not others, or whether it is on the agenda for improving. It's probably not really a GPC issue at all, but more a gcc backend linker issue.
Partly it is a gpc issue. Try to compile hello.c, also see http://www.gnu-pascal.de/crystal/gpc/en/mail7764.html.
Prof A Olowofoyeku (The African Chief) wrote:
I have discussed this with Frank sometime in the recent past, and IIRC, the sum of the discussion was that the most straightforward solution (other than doing things the gcc way) would be to find a way of separating each routine, on compilation, into its own object file. There seem to be some mechanisms within the compiler and binutils to assist in doing this - the switches: "-fdata-sections" and "-ffunction- sections" passed on to the compiler, and then objcopy with the switch "--only-section".
Unfortunately, not all platforms support --function-sections, e.g. Mac OS X doesn't.
Regards,
Adriaan van Os