[comp.sources.wanted] convert .o modules to archives with entry per function

bigm@batserver.cs.uq.oz (Michael Pilling) (08/22/89)

I am writing some library modules, but unfortunately the brain damaged unix linker
links in ALL the library even if you only use one function. This very annoying if
some of the libraries are large.

It seems the only way to create a random library (ranlib) is to write every function
as a separate .c file, compile these to .o's and then archive them.
This would be a pain.

I'm after a utility for apollos or suns (preferably machine independent) that
takes a .o file containing multiple functions
and creates from it a .o file for each function in the original
so that each of the resulting files contain only one function and can then be
archived

Can anyone help or correct my ignorance about how to construct libraries.

Michael Pilling,
Computer Science Department,
University of Queensland,	
St Lucia, 4067	Australia.		

clyde@hitech.ht.oz (Clyde Smith-Stubbs) (08/23/89)

From article <1359@batserver.cs.uq.oz>, by bigm@batserver.cs.uq.oz (Michael Pilling):
> I am writing some library modules, but unfortunately the brain damaged unix linker
> links in ALL the library even if you only use one function. This very annoying if
> some of the libraries are large.
> 
> It seems the only way to create a random library (ranlib) is to write every function
> as a separate .c file, compile these to .o's and then archive them.
> This would be a pain.

I don't really regard this as a pain. Putting each logically independent
module in a separate .c file is the way that everybody else does it.
Use make(1) to make it painless.

> I'm after a utility for apollos or suns (preferably machine independent) that
> takes a .o file containing multiple functions
> and creates from it a .o file for each function in the original
> so that each of the resulting files contain only one function and can then be
> archived

While I hesitate to label anything as impossible or 'too hard' I would regard
such a utility as certainly difficult. It would in fact be impossible to
split up every possible module. If you had data items in a module referenced
from more than one function the utility would have to be smart enough not
to split those functions.

My advice is: learn about make and use it. Setting up a Makefile for a
large library takes a little time to begin with, but maintenance is minimal.

A minimal example of such a Makefile follows: (this has been gutted, so
don't gripe about inconsistncies)

SRCS	= c68.i memcpy.c memset.c memcmp.c abs.c atoi.c \
	  calloc.c ctype.c atol.c strstr.c

OBJS	= memcpy.o memset.o memcmp.o abs.o atoi.o \
	  calloc.o ctype.o atol.o strstr.o

68libc.lib:	$(OBJS)
		-rm -f 68libc.lib
		$(LIBR) r 68libc.lib $(OBJS)

-- 
Clyde Smith-Stubbs
HI-TECH Software, P.O. Box 103, ALDERLEY, QLD, 4051, AUSTRALIA.
INTERNET:	clyde@hitech.ht.oz.au		PHONE:	+61 7 300 5011
UUCP:		uunet!hitech.ht.oz.au!clyde	FAX:	+61 7 300 5246