Message-Id: <199909301623.TAA08201@ankara.Foo.COM> From: "S. M. Halloran" Organization: User RFC 822- and 1123-compliant To: djgpp AT delorie DOT com Date: Thu, 30 Sep 1999 20:29:18 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Linker trimming unused code/data In-reply-to: <37F33128.C1086E5F@maths.unine.ch> X-mailer: Pegasus Mail for Win32 (v3.12) Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 30 Sep 99, Gautier was found to have commented thusly: > Is there a way to make ld trim unused code/data ? > It _seems_ not to do such deletions... > Is there an alternative linker ? The object file (*.o), whether archived in a library (*.a) or existing by itself, is the smallest, indivisible element the linker can deal with. That means if you have function definitions (or instances of classes?) taking up large footprints in terms of byte size, you probably need to organize your source files better, placing many function definitions/globals in a few large source files into new source files. I haven't read any books on how to organize code, manage (big) projects, and design well-written applications of moderate to huge size, but there is probably a general feeling that each source module should contain as a rule only one public (extern) function definition, with all other function definitions inside the module declared private (static) and being used either to support each other and/or the public function. That way if you get the compiler saying "this function declared static but is unused", that function definition probably belongs in a separate source file as a "helper" or as the source file's public function or should be deleted. There are people who like to pile it all into one source file, even if it's a 150,000 - 200,000 lines of source code, and then there are people who go the other extreme and put only one function per file, perhaps trying to win some competition for getting the smallest executable footprint with maximal coding "power". The well-done project is probably somewhere in between. Mitch Halloran Research (Bio)chemist Duzen Laboratories Group Ankara TURKEY