Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Jeff Trawick [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
RE: apr_private.h not being built properly on daedalus (freebsd 4.6) today
From: [EMAIL PROTECTED] Sent: 28 June 2002 13:53 Jeff Trawick [EMAIL PROTECTED] 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
Sander Striker [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
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
Jeff Trawick [EMAIL PROTECTED] 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 | [EMAIL PROTECTED]
Born in Roswell... married an alien...
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Justin Erenkrantz [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
Jeff Trawick [EMAIL PROTECTED] writes: Justin Erenkrantz [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
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 rooneyRemember, any design flaw you're [EMAIL PROTECTED] 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
Garrett Rooney [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: apr_private.h not being built properly on daedalus (freebsd 4.6) today
On Thu, Jun 27, 2002 at 06:53:16PM -0400, Jeff Trawick wrote: Garrett Rooney [EMAIL PROTECTED] 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 rooneyRemember, any design flaw you're [EMAIL PROTECTED] sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski
