You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2001/01/10 19:47:38 UTC
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
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.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by rb...@covalent.net.
> > Can I suggest a possible solution for 1, and agree 100% with 2? The
> > possible solution, is to use two variables, LIBTOOL_LIBS, and
> > NON_LIBTOOL_LIBS. These names are probably wrong, call they what you want
> > to.
> >
> > The idea is that if you use LIBTOOL, you have to add the libraries in
> > LIBTOOL_LIBS, if not you have to use NON_LIBTOOL_LIBS. If you don't use
> > libtool, you basically have to add the NON_LIBTOOL_LIBS to APR_LIBS.
> >
> > Does that make sense?
>
> Somewhat... but it does mean that we'd be looking down into .libs for the
> libraries to put into NON_LIBTOOL_LIBS. Not sure what I think about that
> one... (reaching into .libs is the basic question: do we or don't we?)
I agree that is painful, but I didn't realize there was an option when not
using libtool. I thought you had to look at the .libs stuff in that case.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by rb...@covalent.net.
> > Somewhat... but it does mean that we'd be looking down into .libs for the
> > libraries to put into NON_LIBTOOL_LIBS. Not sure what I think about that
> > one... (reaching into .libs is the basic question: do we or don't we?)
>
> Am I correct in assuming that the point of those variables is
> to export a list of libraries which are build by APR and
> which basically form the APR library?
Basically.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by Sascha Schumann <sa...@schumann.cx>.
[Note: My connectivity is quite limited currently.. ]
> Somewhat... but it does mean that we'd be looking down into .libs for the
> libraries to put into NON_LIBTOOL_LIBS. Not sure what I think about that
> one... (reaching into .libs is the basic question: do we or don't we?)
Am I correct in assuming that the point of those variables is
to export a list of libraries which are build by APR and
which basically form the APR library?
Or are those variables supposed to additionally contain
external dependencies (i.e. on system libraries) for the APR
library?
- Sascha
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 10, 2001 at 09:22:30PM -0800, rbb@covalent.net wrote:
>
> > It works for me.
> >
> > I only have two mild concerns:
> >
> > 1) APR's use of .la files when the user doesn't use libtool (noted above)
> > 2) APRVARS.in using variables not in the APR namespace. See apr-util's
> > export_vars.sh.in for what I think is the Right Way (and how it is used
> > in Apache's configure.in). By using unprotected names in APRVARS, we
> > might "stomp" on the user's vars.
> >
> > I've got no immediate answer for (1), and (2) is just something that has
> > been in mind for a while. I'll get around to it at some point, probably
> > after JimJag's flag revision stuff.
>
> Can I suggest a possible solution for 1, and agree 100% with 2? The
> possible solution, is to use two variables, LIBTOOL_LIBS, and
> NON_LIBTOOL_LIBS. These names are probably wrong, call they what you want
> to.
>
> The idea is that if you use LIBTOOL, you have to add the libraries in
> LIBTOOL_LIBS, if not you have to use NON_LIBTOOL_LIBS. If you don't use
> libtool, you basically have to add the NON_LIBTOOL_LIBS to APR_LIBS.
>
> Does that make sense?
Somewhat... but it does mean that we'd be looking down into .libs for the
libraries to put into NON_LIBTOOL_LIBS. Not sure what I think about that
one... (reaching into .libs is the basic question: do we or don't we?)
Sascha may have an idea here.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by rb...@covalent.net.
> > Can I suggest a possible solution for 1, and agree 100% with 2? The
> > possible solution, is to use two variables, LIBTOOL_LIBS, and
> > NON_LIBTOOL_LIBS. These names are probably wrong, call they what you want
> > to.
>
> I guess I'm naive in wishing that an APR user using libtool could
> specify a single .la file to get APR and an APR user not using libtool
> could specify a single .a file to get APR?
>
> Why do we need a list of libraries?
Because libtool is a PITA. If you read the libtool manual, it basically
says that static libraries are an old outdated way of doing things, so
libtool implements everything as a shared library, even on platforms that
don't really support shared libraries.
What this means for us, is that they don't try to link the two libraries,
APR and MM into a single library, they would rather just use two separate
libraries. Originally, I added a hack to pull the .o files from the MM
directory, and we just used those to create our libtool library. As soon
as we went to actually using libtool for APR, that hack became incorrect,
and we either needed to change the hack, or rip it out and start over.
I made APR report to Apache which libtool libraries it is using, because
that is the "libtool" way of doing things. I think a part of our problem
with libtool is that we try to fight the way libtool wants things
done. If libtool is designed to use shared libraries, then it is likely
to work best if we do that.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> Can I suggest a possible solution for 1, and agree 100% with 2? The
> possible solution, is to use two variables, LIBTOOL_LIBS, and
> NON_LIBTOOL_LIBS. These names are probably wrong, call they what you want
> to.
I guess I'm naive in wishing that an APR user using libtool could
specify a single .la file to get APR and an APR user not using libtool
could specify a single .a file to get APR?
Why do we need a list of libraries?
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by rb...@covalent.net.
> It works for me.
>
> I only have two mild concerns:
>
> 1) APR's use of .la files when the user doesn't use libtool (noted above)
> 2) APRVARS.in using variables not in the APR namespace. See apr-util's
> export_vars.sh.in for what I think is the Right Way (and how it is used
> in Apache's configure.in). By using unprotected names in APRVARS, we
> might "stomp" on the user's vars.
>
> I've got no immediate answer for (1), and (2) is just something that has
> been in mind for a while. I'll get around to it at some point, probably
> after JimJag's flag revision stuff.
Can I suggest a possible solution for 1, and agree 100% with 2? The
possible solution, is to use two variables, LIBTOOL_LIBS, and
NON_LIBTOOL_LIBS. These names are probably wrong, call they what you want
to.
The idea is that if you use LIBTOOL, you have to add the libraries in
LIBTOOL_LIBS, if not you have to use NON_LIBTOOL_LIBS. If you don't use
libtool, you basically have to add the NON_LIBTOOL_LIBS to APR_LIBS.
Does that make sense?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 10, 2001 at 07:13:36PM -0800, rbb@covalent.net wrote:
>...
> > 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.
>
> Okay, I'm confused, and I've been gone for about a day and a half, so I'm
> going to ask. Forgive me. :-)
>
> Greg, I thought you said that the solution I added was wrong.
Not that I recall. There was a solution that Jeff posted from Allen which I
thought was wrong.
Your export of the LIBTOOL_LIBS is fine. It is always possible that we'll
have more in the future.
The one issue about exporting libtool libraries is when the user of APR
doesn't use libtool. That hasn't come up yet, but it certainly will. For
that case, we would need the user to install APR first (thus installing the
.a and/or .so files), so the user can link against whatever file.
[ note that your exposure of libmm.la isn't the cause: once we libtool'd
APR, then we already have the issue since we build libapr.la ]
> Or, did
> you mean that the stop-gap you used was wrong, and mine was right?
I whacked something in there, but didn't get a chance to fully test it. When
I compiled/linked Apache later in the day, I saw the mm_ link errors and
knew my quick conversion was wrong. By then, you and Jeff were already on
it, and you checked in a valid solution.
> I did
> what I needed to get it working, but I am perfectly open to new solutions.
It works for me.
I only have two mild concerns:
1) APR's use of .la files when the user doesn't use libtool (noted above)
2) APRVARS.in using variables not in the APR namespace. See apr-util's
export_vars.sh.in for what I think is the Right Way (and how it is used
in Apache's configure.in). By using unprotected names in APRVARS, we
might "stomp" on the user's vars.
I've got no immediate answer for (1), and (2) is just something that has
been in mind for a while. I'll get around to it at some point, probably
after JimJag's flag revision stuff.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by "Victor J. Orlikowski" <v....@gte.net>.
Nope, Greg didn't like my patch :)
'cause I simply did more monkeying around to get things working.
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
vjo@raleigh.ibm.com
vjo@us.ibm.com
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by rb...@covalent.net.
> > > > --- 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.
Okay, I'm confused, and I've been gone for about a day and a half, so I'm
going to ask. Forgive me. :-)
Greg, I thought you said that the solution I added was wrong. Or, did
you mean that the stop-gap you used was wrong, and mine was right? I did
what I needed to get it working, but I am perfectly open to new solutions.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 10, 2001 at 02:52:05PM -0500, Jeff Trawick wrote:
> Jeff Trawick <tr...@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/
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
Posted by Jeff Trawick <tr...@bellsouth.net>.
Jeff Trawick <tr...@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.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...