From:	"John M. Aldrich" <fighteer AT cs DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Libs and dissassembly (fighteer)
Date:	Wed, 22 Jan 1997 19:32:23 -0800
Organization:	Two pounds of chaos and a pinch of salt
Lines:	65
Message-ID:	<32E6DBC7.2EA1@cs.com>
References:	<m0vmvsW-000FzQC AT ican DOT net>
Reply-To:	fighteer AT cs DOT com
NNTP-Posting-Host:	ppp102.cs.com
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

embalmer AT deathsdoor DOT com wrote:
> 
>   When compiling a lib by using ar is there a way that I could have the
> previously compiled lib with the same name overwritten regardless of it's
> content?

When 'ar' is used to modify an already existing library, its behavior
depends on the flags you pass it.  Using the 'r' flag (as in "ar rvs
...") tells it to _Replace_ any existing copies of the object files
specified on the command line.  So as long as the library doesn't
contain anything other than what you put in it, you are effectively
deleting and rebuilding it every time.

If you really do want to delete it first, just put a "rm libmylib.a" in
the makefile/batch/script you use to create the library before the call
to 'ar'.  Here's a sample makefile entry:

libmylib.a : $(LIB_OBJECTS)
	rm -f $@
	ar rcvs $@ $^

> Also can gcc compile libs?

No; that's what 'ar' is for.  :)  But all 'ar' does is pack gcc-compiled
object files into libraries, so it's not much more than an extension to
gcc.

> And finally I wanted to ask why is it
> that you said that it is not a good idea to use a lib by mentioning it as
> one of the gcc input files (i.e gcc file1.c file2.a ...), what's wrong with
> that anyway?

It limits the linker to looking only in the current directory for the
library.  On most systems, libraries can be scattered over lots of
different directories, but as long as they are in the library path known
to 'ld', they can be located simply by using '-l'.  Think how much more
of a pain it would be to have to do this:

 gcc -o prog.exe file1.o file2.o c:/djgpp/lib/libc.a

What if the djgpp progs are somewhere else?  You could try
"$(DJDIR)/lib/libc.a", but what if your program is being built on a Unix
box?

As far as "homemade" libraries are concerned, using a '-L' directive and
then the standard link command allows flexibility in designing your
directory structures.  Being able to specify libraries and the path to
those libraries separately makes for much more intuitive and easy to
read makefiles in large projects.  For small projects it isn't as
important, but you should always try to maintain good habits no matter
how trivial your programs are.

l8r

-- 
John M. Aldrich <fighteer AT cs DOT com>                      

* Anything that happens, happens.
* Anything that, in happening, causes something else to happen,
  causes something else to happen.
* Anything that, in happening, causes itself to happen again, happens
  again.
* It doesn't necessarily do it in chronological order, though.
 
                                       --- Douglas Adams

- Raw text -