You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/04/05 17:10:35 UTC
[PATCH] possible solution for a RANLIB make problem
When no ranlib is found, the autoconf-provided check for ranlib which
APR uses sets RANLIB to a colon.
Certain make utilities get confused when they see stuff like
RANLIB=:
in a makefile.
The following patch changes APR to use a special no-colon check for
ranlib. When there is no ranlib, it sets RANLIB to true.
Any better solutions?
Thanks,
Jeff
Index: aclocal.m4
===================================================================
RCS file: /cvs/apache/apache-2.0/src/lib/apr/aclocal.m4,v
retrieving revision 1.10
diff -u -r1.10 aclocal.m4
--- aclocal.m4 2000/01/16 20:00:49 1.10
+++ aclocal.m4 2000/04/05 15:09:20
@@ -188,4 +188,14 @@
fi
])
+dnl
+dnl check for ranlib, but unlike the autoconf check, set RANLIB
+dnl to "true" instead of ":" if there is no ranlib command;
+dnl otherwise, our makefiles have to check what RANLIB is set
+dnl to
+dnl
+
+AC_DEFUN(AC_PROG_RANLIB_NC,
+[AC_CHECK_PROG(RANLIB, ranlib, ranlib, true)])
+
sinclude(threads.m4)
Index: configure.in
===================================================================
RCS file: /cvs/apache/apache-2.0/src/lib/apr/configure.in,v
retrieving revision 1.64
diff -u -r1.64 configure.in
--- configure.in 2000/04/04 03:55:25 1.64
+++ configure.in 2000/04/05 15:09:20
@@ -26,7 +26,7 @@
dnl # Checks for programs.
AC_PROG_CC
-AC_PROG_RANLIB
+AC_PROG_RANLIB_NC
AC_PROG_MAKE_SET
AC_CHECK_PROG(RM, rm, rm)
AC_CHECK_PROG(AR, ar, ar)
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] possible solution for a RANLIB make problem
Posted by Tony Finch <do...@dotat.at>.
Manoj Kasichainula <ma...@io.com> wrote:
>Tony Finch wrote:
>> Manoj Kasichainula <ma...@io.com> wrote:
>> >
>> >Is there any difference between using true and ":"?
>>
>> `:` is always a builtin; `true` is (almost?) never a builtin.
>
>Right, but how does that affect anything functionally?
I don't think it does at all.
Historical explanation: AFAICT (entirely from guessing what things
were like 20 years before I started using unix) : was originally the
comment command because at that time # was the delete character.
If I'm wrong please correct me!
Tony.
--
f.a.n.finch fanf@demon.net dot@dotat.at
371 quarter-ton bumpercar
Re: [PATCH] possible solution for a RANLIB make problem
Posted by Jeff Trawick <tr...@bellsouth.net>.
> Manoj Kasichainula <ma...@io.com> wrote:
> >
> >Is there any difference between using true and ":"?
>
> `:` is always a builtin; `true` is (almost?) never a builtin.
>
> Tony.
(oops) That is a great point. Hopefully you folks all have ranlib and
so I didn't slow you down any?
I'm still interested in better solutions, but I'm not interested yet
in one that requires gmake to be used on OS/390.
Sorry!
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] possible solution for a RANLIB make problem
Posted by Manoj Kasichainula <ma...@io.com>.
On Fri, Apr 07, 2000 at 02:11:14PM +0100, Tony Finch wrote:
> Manoj Kasichainula <ma...@io.com> wrote:
> >
> >Is there any difference between using true and ":"?
>
> `:` is always a builtin; `true` is (almost?) never a builtin.
Right, but how does that affect anything functionally? Yeah, I guess
it would be nice not to do all the extra execs, but I wouldn't think
there would be many of those.
Re: [PATCH] possible solution for a RANLIB make problem
Posted by Tony Finch <do...@dotat.at>.
Manoj Kasichainula <ma...@io.com> wrote:
>
>Is there any difference between using true and ":"?
`:` is always a builtin; `true` is (almost?) never a builtin.
Tony.
--
f.a.n.finch fanf@demon.net dot@dotat.at
430 moldering mementos of merriment
Re: [PATCH] possible solution for a RANLIB make problem
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Apr 06, 2000 at 11:31:18PM -0400, Jeff Trawick wrote:
> I was going to be sadistic and actually do some sort of test of mmap()
> features that we use, under the impression that there was some reason
> for the elaborite mmap() test that autoconf provides.
- Macro: AC_FUNC_MMAP
If the `mmap' function exists and works correctly, define
`HAVE_MMAP'. Only checks private fixed mapping of already-mapped
memory.
I think they're trying to leave themselved hedging room to add more
stuff to this check (which is reasonable), but they aren't checking
for more than the fixed mapping stuff.
Sanity check: If this is going into APR, is it ever allowes for APR to
use the private fixed mapping functionality? If so, then even if
Apache doesn't use it, APR's check should check for it.
I'm guessing APR doesn't even allow private fixed mapping, but I
don't have time to check right now.
> If you think
> that simply checking for mmap() presence is sufficient then its
> o.k. with me, but something more elaborite would be a little safer and
> keep me out of new-httpd for a while.
But we like you!
Re: [PATCH] possible solution for a RANLIB make problem
Posted by rb...@apache.org.
> > I assume it's just removing "AC_FUNC_MMAP" and adding mmap to the
> > AC_CHECK_FUNCS list?
>
> I was going to be sadistic and actually do some sort of test of mmap()
> features that we use, under the impression that there was some reason
> for the elaborite mmap() test that autoconf provides. If you think
> that simply checking for mmap() presence is sufficient then its
> o.k. with me, but something more elaborite would be a little safer and
> keep me out of new-httpd for a while.
I suggest before doing anything with this, that the autoconf info pages
are looked into. I have noticed that in most places where autoconf does
more than what looks strictly needed, the info pages tell you why they did
what they did.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] possible solution for a RANLIB make problem
Posted by Jeff Trawick <tr...@bellsouth.net>.
> Is there any difference between using true and ":"? The only one I can
> think of is that true --help generates output on Linux boxes, while :
> --help doesn't.
It makes sense to me (learning more about shell command language even
as I type).
>
> > My favorite test that fails on OS/390 is a supposed check for ANSI
> > header files. The test requires that only lower case letters occupy
> > 'a' through 'z' in the code page.
>
> Well, I have no clue why the EBCDIC guys did this, do you? :)
There is probably an interesting untrue story about this, but I don't
know it :( I would guess that it has to do with properties of
a mechanical card punch design, which is where it started out.
> > Another one is the autoconf-provided test for mmap() which APR uses.
> > The test requires that mmap() be willing to fix arbitrary storage in
> > order to say that you have mmap(). APR doesn't use that flag, XOpen
> > doesn't require that flag to be supported, but APR won't use mmap() on
> > such a system (yet; unfortunate patch to come later).
>
> I assume it's just removing "AC_FUNC_MMAP" and adding mmap to the
> AC_CHECK_FUNCS list?
I was going to be sadistic and actually do some sort of test of mmap()
features that we use, under the impression that there was some reason
for the elaborite mmap() test that autoconf provides. If you think
that simply checking for mmap() presence is sufficient then its
o.k. with me, but something more elaborite would be a little safer and
keep me out of new-httpd for a while.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] possible solution for a RANLIB make problem
Posted by Manoj Kasichainula <ma...@io.com>.
On Wed, Apr 05, 2000 at 01:39:22PM -0400, Jeff Trawick wrote:
> > Somebody should probably be sending these issues to the autoconf team,
> > so that we can stop worrying about them.
>
> I thought about that. At first, I thought that defaulting to a colon
> was a bug, but it seems very intentional.
Is there any difference between using true and ":"? The only one I can
think of is that true --help generates output on Linux boxes, while :
--help doesn't.
> My favorite test that fails on OS/390 is a supposed check for ANSI
> header files. The test requires that only lower case letters occupy
> 'a' through 'z' in the code page.
Well, I have no clue why the EBCDIC guys did this, do you? :)
> Another one is the autoconf-provided test for mmap() which APR uses.
> The test requires that mmap() be willing to fix arbitrary storage in
> order to say that you have mmap(). APR doesn't use that flag, XOpen
> doesn't require that flag to be supported, but APR won't use mmap() on
> such a system (yet; unfortunate patch to come later).
I assume it's just removing "AC_FUNC_MMAP" and adding mmap to the
AC_CHECK_FUNCS list?
Re: [PATCH] possible solution for a RANLIB make problem
Posted by Jeff Trawick <tr...@bellsouth.net>.
> > Certain make utilities get confused when they see stuff like
> >
> > RANLIB=:
> >
> > in a makefile.
>
> Which ones, out of curiousity?
OS/390, for one. Mortice Kern provided the make utility originally,
and Mortice Kern has been doing that on other systems for years. I
sort of doubt that they rewrote it from scratch for OS/390 just to
introduce little quirks like this. I have no idea whether or not
Mortice Kern make is used somewhere else where Apache might be built.
> Somebody should probably be sending these issues to the autoconf team,
> so that we can stop worrying about them.
I thought about that. At first, I thought that defaulting to a colon
was a bug, but it seems very intentional. I don't know what I'd tell
them, other than "I think your choice of default isn't cool and I
want you to break all the autoconf scripts folks have written over the
years that do stuff with RANLIB so that my stuff works without
changes." I can only imagine what the response would be. Somehow the
pissing contests here seem more tame.
My favorite test that fails on OS/390 is a supposed check for ANSI
header files. The test requires that only lower case letters occupy
'a' through 'z' in the code page. Without a tweak, configure says we
don't have ANSI header files.
Another one is the autoconf-provided test for mmap() which APR uses.
The test requires that mmap() be willing to fix arbitrary storage in
order to say that you have mmap(). APR doesn't use that flag, XOpen
doesn't require that flag to be supported, but APR won't use mmap() on
such a system (yet; unfortunate patch to come later).
Have fun,
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] possible solution for a RANLIB make problem
Posted by Manoj Kasichainula <ma...@io.com>.
On Wed, Apr 05, 2000 at 11:10:35AM -0400, Jeff Trawick wrote:
> When no ranlib is found, the autoconf-provided check for ranlib which
> APR uses sets RANLIB to a colon.
>
> Certain make utilities get confused when they see stuff like
>
> RANLIB=:
>
> in a makefile.
Which ones, out of curiousity?
Somebody should probably be sending these issues to the autoconf team,
so that we can stop worrying about them.
+1