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...@attglobal.net> on 2002/06/27 21:48:21 UTC
apr_private.h not being built properly on daedalus (freebsd 4.6) today
The header file defines in apr_private.h are busted and APR won't
build. Here is a glaring example:
/* Define if you have the <string.h> header file. */
/* #undef HAVE_STRING_H */
config.cache seems to have the right value:
ac_cv_header_string_h=${ac_cv_header_string_h='yes'}
[trawick@daedalus apr]$ dir /usr/local/share/autoconf213/autoconf
total 1120
drwxr-xr-x 2 root wheel 512 Jun 26 17:55 .
drwxr-xr-x 3 root wheel 512 Jun 26 17:55 ..
-r--r--r-- 1 root wheel 7920 Jun 26 17:55 acconfig.h
-r--r--r-- 1 root wheel 1411 Jun 26 17:55 acfunctions
-r--r--r-- 1 root wheel 81639 Jun 26 17:55 acgeneral.m4
-r--r--r-- 1 root wheel 701 Jun 26 17:55 acheaders
-r--r--r-- 1 root wheel 526 Jun 26 17:55 acidentifiers
-r--r--r-- 1 root wheel 210 Jun 26 17:55 acmakevars
-r--r--r-- 1 root wheel 4065 Jun 26 17:55 acoldnames.m4
-r--r--r-- 1 root wheel 334 Jun 26 17:55 acprograms
-r--r--r-- 1 root wheel 83792 Jun 26 17:55 acspecific.m4
-r--r--r-- 1 root wheel 1186 Jun 26 17:55 autoconf.m4
-r--r--r-- 1 root wheel 151762 Jun 26 17:55 autoconf.m4f
-r--r--r-- 1 root wheel 2585 Jun 26 17:55 autoheader.m4
-r--r--r-- 1 root wheel 148913 Jun 26 17:55 autoheader.m4f
-r--r--r-- 1 root wheel 26702 Jun 26 17:55 config.guess
-r--r--r-- 1 root wheel 19814 Jun 26 17:55 config.sub
-r-xr-xr-x 1 root wheel 5598 Jun 26 17:55 install-sh
[trawick@daedalus apr]$ date
Thu Jun 27 12:37:55 PDT 2002
[trawick@daedalus apr]$ dir /usr/local/share/autoconf
total 1108
drwxr-xr-x 2 root wheel 512 Dec 23 2000 .
drwxr-xr-x 38 root wheel 1024 Jun 26 17:55 ..
-r--r--r-- 1 root wheel 7841 Nov 16 2000 acconfig.h
-r--r--r-- 1 root wheel 1411 Nov 16 2000 acfunctions
-r--r--r-- 1 root wheel 81308 Nov 16 2000 acgeneral.m4
-r--r--r-- 1 root wheel 701 Nov 16 2000 acheaders
-r--r--r-- 1 root wheel 526 Nov 16 2000 acidentifiers
-r--r--r-- 1 root wheel 210 Nov 16 2000 acmakevars
-r--r--r-- 1 root wheel 4065 Nov 16 2000 acoldnames.m4
-r--r--r-- 1 root wheel 334 Nov 16 2000 acprograms
-r--r--r-- 1 root wheel 83024 Nov 16 2000 acspecific.m4
-r--r--r-- 1 root wheel 1186 Nov 16 2000 autoconf.m4
-r--r--r-- 1 root wheel 151091 Nov 16 2000 autoconf.m4f
-r--r--r-- 1 root wheel 2585 Nov 16 2000 autoheader.m4
-r--r--r-- 1 root wheel 148242 Nov 16 2000 autoheader.m4f
-r--r--r-- 1 root wheel 26702 Nov 16 2000 config.guess
-r--r--r-- 1 root wheel 19814 Nov 16 2000 config.sub
[trawick@daedalus apr]$ autoconf --version
Autoconf version 2.13
I wonder if we're picking up a mismatch of autoconf code...
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Thu, Jun 27, 2002 at 06:53:16PM -0400, Jeff Trawick wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
> > On Thu, Jun 27, 2002 at 06:17:41PM -0400, Jeff Trawick wrote:
> >
> > > talk about PRs coming our way for people upgrading FreeBSD... first,
> > > old builds are suddenly unreliable, and new builds are impossible
> > > without switching to GNU sed!!!!!
> >
> > is this on a fairly recent freebsd -STABLE system? if so, there were
> > some recent changes to sed that were merged from -CURRENT with one
> > critical bugfix not merged. the offending bug has been fixed
> > (according to what i read on the lists, i haven't seen myself), so if
> > you cvsup to a more recent -STABLE and rebuild sed, it might be fixed.
> > if it isn't, then you should send a message about this to the freebsd
> > people, as sed is a damn important thing to have broken.
>
>
> Can you tell from this if we have the latest STABLE?
>
> process.c: "$FreeBSD: src/usr.bin/sed/process.c,v 1.10.2.5 2002/06/26 16:49:28 obrien Exp $";
the latest sed bug fix was MFC'd by dillon in revision 1.10.2.6 of process.c,
so you're a bit out of date.
try grabbing the new version and rebuilding sed.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Posted by Jeff Trawick <tr...@attglobal.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> On Thu, Jun 27, 2002 at 06:17:41PM -0400, Jeff Trawick wrote:
>
> > talk about PRs coming our way for people upgrading FreeBSD... first,
> > old builds are suddenly unreliable, and new builds are impossible
> > without switching to GNU sed!!!!!
>
> is this on a fairly recent freebsd -STABLE system? if so, there were
> some recent changes to sed that were merged from -CURRENT with one
> critical bugfix not merged. the offending bug has been fixed
> (according to what i read on the lists, i haven't seen myself), so if
> you cvsup to a more recent -STABLE and rebuild sed, it might be fixed.
> if it isn't, then you should send a message about this to the freebsd
> people, as sed is a damn important thing to have broken.
Can you tell from this if we have the latest STABLE?
compile.c: "$FreeBSD: src/usr.bin/sed/compile.c,v 1.13.2.6 2002/06/26 16:49:28 obrien Exp $";
main.c: "$FreeBSD: src/usr.bin/sed/main.c,v 1.9.2.5 2002/06/26 16:49:28 obrien Exp $";
misc.c: "$FreeBSD: src/usr.bin/sed/misc.c,v 1.3.2.1 2001/11/29 05:22:44 mikeh Exp $";
process.c: "$FreeBSD: src/usr.bin/sed/process.c,v 1.10.2.5 2002/06/26 16:49:28 obrien Exp $";
extern.h: * $FreeBSD: src/usr.bin/sed/extern.h,v 1.3.6.3 2002/06/26 16:49:28 obrien Exp $
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Thu, Jun 27, 2002 at 06:17:41PM -0400, Jeff Trawick wrote:
> talk about PRs coming our way for people upgrading FreeBSD... first,
> old builds are suddenly unreliable, and new builds are impossible
> without switching to GNU sed!!!!!
is this on a fairly recent freebsd -STABLE system? if so, there were
some recent changes to sed that were merged from -CURRENT with one
critical bugfix not merged. the offending bug has been fixed
(according to what i read on the lists, i haven't seen myself), so if
you cvsup to a more recent -STABLE and rebuild sed, it might be fixed.
if it isn't, then you should send a message about this to the freebsd
people, as sed is a damn important thing to have broken.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> Justin Erenkrantz <je...@apache.org> writes:
>
> > > I tried installing local copies of GNU m4 and autoconf 2.13, but the
> > > problem persists. I even tried specifying /usr/local/bin/bash instead
> > > of /bin/sh in configure. Any other ideas to narrow down what broke
> > > it?
> >
> > By chance, do you have AUTOCONF or AUTOHEADER set as environment
> > variables? You can also set them to explicit paths. It's
> > possible that they are in conflict. -- justin
>
> no, I had played with those earlier but they were definitely unset in
> my last test....
>
> this might be a clue... I killed a configure after it had detected
> headers and I had this in confdefs.h:
>
> #define HAVE_SYS_IPC_h 1
> #define HAVE_SYS_SHM_h 1
> #define HAVE_SYS_FILE_h 1
>
> This error is probably what is breaking IPv6 detection and may be
> breaking the other stuff too.
>
> I probably should have tried GNU sed instead of FreeBSD sed.
I just tried GNU sed and APR builds again!!!!!!!!!!!!!!!!!!!!!!!!!!!!
With that test I had my own builds of GNU m4+sed+autoconf, though I
suspect it is just sed that is related to the problem.
talk about PRs coming our way for people upgrading FreeBSD... first,
old builds are suddenly unreliable, and new builds are impossible
without switching to GNU sed!!!!!
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@apache.org> writes:
> > I tried installing local copies of GNU m4 and autoconf 2.13, but the
> > problem persists. I even tried specifying /usr/local/bin/bash instead
> > of /bin/sh in configure. Any other ideas to narrow down what broke
> > it?
>
> By chance, do you have AUTOCONF or AUTOHEADER set as environment
> variables? You can also set them to explicit paths. It's
> possible that they are in conflict. -- justin
no, I had played with those earlier but they were definitely unset in
my last test....
this might be a clue... I killed a configure after it had detected
headers and I had this in confdefs.h:
#define HAVE_SYS_IPC_h 1
#define HAVE_SYS_SHM_h 1
#define HAVE_SYS_FILE_h 1
This error is probably what is breaking IPv6 detection and may be
breaking the other stuff too.
I probably should have tried GNU sed instead of FreeBSD sed.
(suffering from Chinese food deficit)
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Jun 27, 2002 at 05:29:40PM -0400, Jeff Trawick wrote:
> Jeff Trawick <tr...@attglobal.net> writes:
>
> > The header file defines in apr_private.h are busted and APR won't
> > build. Here is a glaring example:
> >
> > /* Define if you have the <string.h> header file. */
> > /* #undef HAVE_STRING_H */
> >
> > config.cache seems to have the right value:
> >
> > ac_cv_header_string_h=${ac_cv_header_string_h='yes'}
>
> I tried installing local copies of GNU m4 and autoconf 2.13, but the
> problem persists. I even tried specifying /usr/local/bin/bash instead
> of /bin/sh in configure. Any other ideas to narrow down what broke
> it?
By chance, do you have AUTOCONF or AUTOHEADER set as environment
variables? You can also set them to explicit paths. It's
possible that they are in conflict. -- justin
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> The header file defines in apr_private.h are busted and APR won't
> build. Here is a glaring example:
>
> /* Define if you have the <string.h> header file. */
> /* #undef HAVE_STRING_H */
>
> config.cache seems to have the right value:
>
> ac_cv_header_string_h=${ac_cv_header_string_h='yes'}
I tried installing local copies of GNU m4 and autoconf 2.13, but the
problem persists. I even tried specifying /usr/local/bin/bash instead
of /bin/sh in configure. Any other ideas to narrow down what broke
it?
Oh, we aren't finding sockaddr_in6 today either.
Greg has a stashed build tree, and we're going to need to compare old
and new apr.h and apr_private.h to see what else has gone haywire.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: apr_private.h not being built properly on daedalus (freebsd 4.6)
today
Posted by Cliff Woolley <jw...@virginia.edu>.
On 28 Jun 2002, Jeff Trawick wrote:
> The first fun comes during buildconf processing:
>
> $ ./buildconf
> buildconf: checking installation...
> buildconf: autoconf version 2.53 (ok)
> buildconf: libtool version 1.3.4 (ok)
> Copying libtool helper files ...
> Creating include/arch/unix/apr_private.h.in ...
> WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
> WARNING: and `config.h.top', to define templates for `config.h.in'
> WARNING: is deprecated and discouraged.
That's not specific to *BSD. It's just an overly verbose "this is
deprecated" message.
> during configure I get these messages like this when creating each of
> the make files (probably not a fatal condition):
> config.status: creating Makefile
> mv: Makefile: set owner/group (was: 1121/0): Operation not permitted
> make works, so I overreacted about all the messages.
I saw the same in icarus. I have no bloody idea what it's talking about.
This one *is* *BSD specific (maybe even FreeBSD 4.6 specific, not sure).
Anyway, as you discovered, you can safely ignore this message.
--Cliff
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Posted by Jeff Trawick <tr...@attglobal.net>.
"Sander Striker" <st...@apache.org> writes:
> > *slight complication... during this sed trauma, autoconf 2.53 became
> > the default autoconf on daedalus, and it doesn't get along well with
> > APR;
>
> Is that *BSD specific? ac2.53 works fine for me on linux with APR.
perhaps...
The first fun comes during buildconf processing:
$ ./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.53 (ok)
buildconf: libtool version 1.3.4 (ok)
Copying libtool helper files ...
Creating include/arch/unix/apr_private.h.in ...
WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
WARNING: and `config.h.top', to define templates for `config.h.in'
WARNING: is deprecated and discouraged.
WARNING: Using the third argument of `AC_DEFINE' and
WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
WARNING: `acconfig.h':
WARNING: AC_DEFINE([NEED_MAIN], 1,
WARNING: [Define if a function `main' is needed.])
WARNING: More sophisticated templates can also be produced, see the
WARNING: documentation.
autoheader: `include/arch/unix/apr_private.h.in' is created
Creating configure ...
during configure I get these messages like this when creating each of
the make files (probably not a fatal condition):
config.status: creating Makefile
mv: Makefile: set owner/group (was: 1121/0): Operation not permitted
make works, so I overreacted about all the messages.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
RE: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Posted by Sander Striker <st...@apache.org>.
> From: trawick@rdu88-251-253.nc.rr.com
> Sent: 28 June 2002 13:53
> Jeff Trawick <tr...@attglobal.net> writes:
>
> > The header file defines in apr_private.h are busted and APR won't
> > build. Here is a glaring example:
>
> Summary of ths solution:
>
> We picked up a bad sed from 4.6-STABLE, which broke this. We then
> picked up a subsequent fix, and we build again on daedalus*.
>
> *slight complication... during this sed trauma, autoconf 2.53 became
> the default autoconf on daedalus, and it doesn't get along well with
> APR;
Is that *BSD specific? ac2.53 works fine for me on linux with APR.
> I used my own local install of pure GNU autoconf 2.13 to build
> APR
Sander
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> The header file defines in apr_private.h are busted and APR won't
> build. Here is a glaring example:
Summary of ths solution:
We picked up a bad sed from 4.6-STABLE, which broke this. We then
picked up a subsequent fix, and we build again on daedalus*.
*slight complication... during this sed trauma, autoconf 2.53 became
the default autoconf on daedalus, and it doesn't get along well with
APR; I used my own local install of pure GNU autoconf 2.13 to build
APR
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...