apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Date Wed, 10 Jan 2001 23:49:28 GMT
On Wed, Jan 10, 2001 at 02:52:05PM -0500, Jeff Trawick wrote:
> Jeff Trawick <trawickj@bellsouth.net> writes:
> 
> > gstein@apache.org writes:
> > 
> > > gstein      01/01/09 03:06:29
> > > 
> > >   Libtool-ize APR.
> > >   Index: Makefile.in
> > >   ===================================================================
> > >   RCS file: /home/cvs/apr/shmem/unix/Makefile.in,v
> > >   retrieving revision 1.14
> > >   retrieving revision 1.15
> > >   diff -u -u -r1.14 -r1.15
> > >   --- Makefile.in	2000/11/15 11:50:07	1.14
> > >   +++ Makefile.in	2001/01/09 11:06:15	1.15
> > ...
> > >   +	cp $(MM_OBJS) .
> > 
> > Isn't this copying the wrong (or not enough) files?  It currently
> > copies just the .lo (timestamp) files.  Maybe it should copy the .o
> > files too. 
> > 
> > Later, libtool thinks these are the real files (I guess) and when
> > building .libs/libapr.a it ends up creating the symbolic links (the
> > ones that don't work with libtool 1.3.3) and putting these timestamp
> > files in the archive.
> > 
> > mm_malloc/mm_free/etc. are not in .libs/libapr.a.  They are
> > referenced, of course.
> 
> I just verified that if shmem/unix/Makefile copies mm/*.lo *and*
> mm/*.o then .libs/libapr.a has mm_malloc() et al in it.
> 
> As an added bonus, this avoids the dependency on libtool 1.3.4.

I'm just going to punt that stuff. Ryan made a change to allow us to tell
apps to include libmm.la, so that should be fine. That will also keep us
from poking around with the MM files, making assumptions about .lo
organization, etc ... much cleaner.

The whole copy thing used to be in there, but was an artifact of the old
system. I think we can clear it out.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message