Building Subversion 1.2 on OS X 10.4 fails

[Scott Palmer]

I'm trying to build on OS X 10.4

I don't need BDB support and i don't have BDB installed (that I know
of).

It fails to build. Note that I was able to build a few weeks ago,
prior to updating to OS X 10.4

Here's a transcript (excuse the huge dump from ./configure, but I
didn't know what bits were relevant, the whole ./configure thing is a
complete mystery to me):

$ svn info

Path: .
URL: http://svn.collab.net/repos/svn/branches/1.2.x
Repository UUID: 65390229-12b7-0310-b90b-f21a5aa7ec8e
Revision: 14676
Node Kind: directory
Schedule: normal
Last Changed Author: sussman
Last Changed Rev: 14676
Last Changed Date: 2005-05-10 16:13:49 -0400 (Tue, 10 May 2005)
Properties Last Updated: 2005-03-22 13:01:35 -0500 (Tue, 22 Mar 2005)

$ ./autogen.sh

buildcheck: checking installation...
buildcheck: autoconf version 2.59 (ok)
buildcheck: autoheader version 2.59 (ok)
buildcheck: libtool version 1.5 (ok)
buildcheck: local copy of PrintPath does not match APR's copy.
An updated copy of PrintPath may need to be checked in.
Copying libtool helper: /usr/share/aclocal/libtool.m4
Creating build-outputs.mk...
Creating svn_private_config.h.in...
Creating configure...
Creating configuration files for apr.
buildconf: checking installation...
buildconf: python version 2.3.5 (ok)
buildconf: autoconf version 2.59 (ok)
buildconf: libtool version 1.5 (ok)
Copying libtool helper files ...
buildconf: Using libtool.m4 at /usr/share/aclocal/libtool.m4.
Creating include/arch/unix/apr_private.h.in ...
autoheader: WARNING: Using auxiliary files such as `acconfig.h',
`config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for
`config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be
produced, see the
autoheader: WARNING: documentation.
Creating configure ...
Generating 'make' outputs ...
rebuilding rpm spec file
Creating configuration files for apr-util.

Looking for apr source in ../apr
Creating include/private/apu_config.h ...
Creating configure ...
Generating 'make' outputs ...
Invoking xml/expat/buildconf.sh ...
Copying libtool helper files ...
Incorporating /usr/share/aclocal/libtool.m4 into aclocal.m4 ...
Creating config.h.in ...
autoheader: WARNING: Using auxiliary files such as `acconfig.h',
`config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for
`config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be
produced, see the
autoheader: WARNING: documentation.
Creating configure ...
rebuilding rpm spec file

You can run ./configure now.

Running autogen.sh implies you are a maintainer. You may prefer
to run configure in one of the following ways:

./configure --enable-maintainer-mode
./configure --disable-shared
./configure --enable-maintainer-mode --disable-shared

Note: If you wish to run a Subversion HTTP server, you will need
Apache 2.0. See the INSTALL file for details.

$ ./configure

configure: Configuring Subversion 1.2.0
checking build system type... powerpc-apple-darwin8.0.0
checking host system type... powerpc-apple-darwin8.0.0
configure: creating config.nice
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking whether ln -s works... yes
configure: Apache Portable Runtime (APR) library configuration
checking for APR... reconfig
configuring package in apr now
checking build system type... powerpc-apple-darwin8.0.0
checking host system type... powerpc-apple-darwin8.0.0
checking target system type... powerpc-apple-darwin8.0.0
Configuring APR library
Platform: powerpc-apple-darwin8.0.0
checking for working mkdir -p... yes
APR Version: 1.0.1
checking for chosen layout... apr
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
Applying APR hints file rules for powerpc-apple-darwin8.0.0
setting CPPFLAGS to "-DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-
cpp-precomp"
setting apr_posixsem_is_global to "yes"
(Default will be unix)
checking whether make sets $(MAKE)... yes
checking how to run the C preprocessor... gcc -E
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether ln -s works... yes
checking for ranlib... ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking for rm... rm
checking for as... as
checking for cpp... cpp
checking for ar... ar
checking for egrep... grep -E
checking for AIX... no
checking for library containing strerror... none required
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether system uses EBCDIC... no
performing libtool configuration...
checking for a sed that does not truncate output... /usr/bin/sed
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -p
checking how to recognise dependent libraries... pass_all
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 65536
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for objdir... .libs
checking for ar... (cached) ar
checking for ranlib... (cached) ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared
libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking dynamic linker characteristics... darwin8.0.0 dyld
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries... yes
checking for g++ option to produce PIC... -fno-common
checking if g++ PIC flag -fno-common works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking dynamic linker characteristics... darwin8.0.0 dyld
appending configuration tag "F77" to libtool

Check for compiler flags...
checking whether to enable -D_LARGEFILE64_SOURCE... no

Checking for libraries...
checking for library containing gethostbyname... none required
checking for library containing gethostname... none required
checking for library containing socket... none required
checking for library containing crypt... none required
checking for main in -ltruerand... no
checking for library containing modf... none required

Checking for Threads...
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for CFLAGS needed for pthreads... none
checking for LIBS needed for pthreads... -lpthread
setting LIBS to "-lpthread"
checking for pthread.h... (cached) yes
checking whether pthread_getspecific takes two arguments... no
checking whether pthread_attr_getdetachstate takes one argument... no
checking for recursive mutex support... yes
checking for pthread_key_delete... yes
checking for pthread_rwlock_init... yes
checking for pthread_attr_setguardsize... yes
checking for pthread_rwlock_t... no
APR will use threads
checking for readdir in -lc_r... no
checking for gethostbyname in -lc_r... no
checking for gethostbyaddr in -lc_r... no
checking for gethostbyname_r... no
checking for gethostbyaddr_r... no
checking for sigsuspend... yes
checking for sigwait... yes
checking for poll... yes
checking for kqueue... yes
checking for epoll support... no
checking for getpwnam_r... yes
checking for getpwuid_r... yes
checking for getgrnam_r... yes
checking for getgrgid_r... yes

Checking for Shared Memory Support...
checking for library containing shm_open... none required
checking for sys/types.h... (cached) yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking sys/ipc.h usability... yes
checking sys/ipc.h presence... yes
checking for sys/ipc.h... yes
checking sys/mutex.h usability... no
checking sys/mutex.h presence... no
checking for sys/mutex.h... no
checking sys/shm.h usability... yes
checking sys/shm.h presence... yes
checking for sys/shm.h... yes
checking sys/file.h usability... yes
checking sys/file.h presence... yes
checking for sys/file.h... yes
checking kernel/OS.h usability... no
checking kernel/OS.h presence... no
checking for kernel/OS.h... no
checking os2.h usability... no
checking os2.h presence... no
checking for os2.h... no
checking for mmap... yes
checking for munmap... yes
checking for shm_open... yes
checking for shm_unlink... yes
checking for shmget... yes
checking for shmat... yes
checking for shmdt... yes
checking for shmctl... yes
checking for create_area... no
checking for MAP_ANON in sys/mman.h... yes
checking for /dev/zero... yes
checking for mmap that can map /dev/zero... no
decision on anonymous shared memory allocation method... 4.4BSD-style
mmap() via MAP_ANON
decision on namebased memory allocation method... SysV IPC shmget()
checking for alloca... no
checking for calloc... yes
checking for setsid... yes
checking for isinf... yes
checking for isnan... yes
checking for getenv... yes
checking for putenv... yes
checking for setenv... yes
checking for unsetenv... yes
checking for setrlimit... yes
checking for getrlimit... yes
checking for writev... yes
checking for sendfilev in -lsendfile... no
checking for sendfile... no
checking for send_file... no
checking for sendfilev... no
checking for utime... yes
checking for utimes... yes
checking for sigaction... yes
checking whether sys_siglist is declared... yes
checking for fork... yes
checking for inet_addr... yes
checking for inet_network... yes
checking for _getch... no
checking for strerror_r... yes
checking for type of return code from strerror_r... int
checking for mmap... (cached) yes
checking for memmove... yes
checking for getpass... yes
checking for getpassphrase... no
checking for gmtime_r... yes
checking for localtime_r... yes
checking for mkstemp... yes
checking whether sigwait takes one argument... no
checking for inode member of struct dirent... d_fileno
checking for file type member of struct dirent... d_type
checking for ANSI C header files... (cached) yes
checking alloca.h usability... yes
checking alloca.h presence... yes
checking for alloca.h... yes
checking ByteOrder.h usability... no
checking ByteOrder.h presence... no
checking for ByteOrder.h... no
checking conio.h usability... no
checking conio.h presence... no
checking for conio.h... no
checking crypt.h usability... no
checking crypt.h presence... no
checking for crypt.h... no
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking dir.h usability... no
checking dir.h presence... no
checking for dir.h... no
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking dl.h usability... no
checking dl.h presence... no
checking for dl.h... no
checking for dlfcn.h... (cached) yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking mach-o/dyld.h usability... yes
checking mach-o/dyld.h presence... yes
checking for mach-o/dyld.h... yes
checking malloc.h usability... no
checking malloc.h presence... no
checking for malloc.h... no
checking for memory.h... (cached) yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking osreldate.h usability... no
checking osreldate.h presence... no
checking for osreldate.h... no
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking process.h usability... no
checking process.h presence... no
checking for process.h... no
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking semaphore.h usability... yes
checking semaphore.h presence... yes
checking for semaphore.h... yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for strings.h... (cached) yes
checking sysapi.h usability... no
checking sysapi.h presence... no
checking for sysapi.h... no
checking sysgtime.h usability... no
checking sysgtime.h presence... no
checking for sysgtime.h... no
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking tpfeq.h usability... no
checking tpfeq.h presence... no
checking for tpfeq.h... no
checking tpfio.h usability... no
checking tpfio.h presence... no
checking for tpfio.h... no
checking for unistd.h... (cached) yes
checking unix.h usability... no
checking unix.h presence... no
checking for unix.h... no
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking for kernel/OS.h... (cached) no
checking net/errno.h usability... no
checking net/errno.h presence... no
checking for net/errno.h... no
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking netinet/sctp.h usability... no
checking netinet/sctp.h presence... no
checking for netinet/sctp.h... no
checking netinet/sctp_uio.h usability... no
checking netinet/sctp_uio.h presence... no
checking for netinet/sctp_uio.h... no
checking for sys/file.h... (cached) yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking for sys/mman.h... (cached) yes
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/sem.h usability... yes
checking sys/sem.h presence... yes
checking for sys/sem.h... yes
checking sys/sendfile.h usability... no
checking sys/sendfile.h presence... no
checking for sys/sendfile.h... no
checking sys/signal.h usability... yes
checking sys/signal.h presence... yes
checking for sys/signal.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/sockio.h usability... yes
checking sys/sockio.h presence... yes
checking for sys/sockio.h... yes
checking for sys/stat.h... (cached) yes
checking sys/sysctl.h usability... yes
checking sys/sysctl.h presence... yes
checking for sys/sysctl.h... yes
checking sys/syslimits.h usability... yes
checking sys/syslimits.h presence... yes
checking for sys/syslimits.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for sys/types.h... (cached) yes
checking sys/uio.h usability... yes
checking sys/uio.h presence... yes
checking for sys/uio.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking for netinet/tcp.h... yes
checking for h_errno in netdb.h... yes
checking for off_t... yes
checking for pid_t... yes
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking for ssize_t... yes
checking for inline... inline
checking for an ANSI C-conforming const... yes
checking whether setpgrp takes no argument... no
checking for socklen_t... yes
checking for void*... yes
checking size of void*... 4
checking for char... yes
checking size of char... 1
checking for int... yes
checking size of int... 4
checking for long... yes
checking size of long... 4
checking for short... yes
checking size of short... 2
checking for long long... yes
checking size of long long... 8
checking for INT64_C... yes
checking size of ssize_t... 4
checking size of size_t... 4
checking size of off_t... 8
checking which type to use for apr_off_t... off_t
checking size of pid_t... 4
checking whether byte ordering is bigendian... yes
checking for strnicmp... no
checking for strncasecmp... yes
checking for stricmp... no
checking for strcasecmp... yes
checking for strdup... yes
checking for strstr... yes
checking for memchr... yes
checking for strtoll... yes

Checking for DSO...
checking for NSLinkModule... yes

Checking for Processes...
checking for waitpid... yes
checking for Variable Length Arrays... yes
checking struct rlimit... yes

Checking for Locking...
checking for semget... yes
checking for semctl... yes
checking for flock... yes
checking for semaphore.h... (cached) yes
checking OS.h usability... no
checking OS.h presence... no
checking for OS.h... no
checking for sem_close... yes
checking for sem_unlink... yes
checking for sem_post... yes
checking for sem_wait... yes
checking for create_sem... no
checking for working sem_open... yes
checking for union semun in sys/sem.h... yes
checking for LOCK_EX in sys/file.h... yes
checking for F_SETLK in fcntl.h... yes
checking for SEM_UNDO in sys/sem.h... yes
checking for POLLIN in poll.h sys/poll.h... yes
checking for PTHREAD_PROCESS_SHARED in pthread.h... yes
checking for pthread_mutexattr_setpshared... yes
checking for working PROCESS_SHARED locks... no
decision on apr_lock implementation method... SysV IPC semget()
checking if all interprocess locks affect threads... no
checking if POSIX sems affect threads in the same process... yes
checking if SysV sems affect threads in the same process... no
checking if fcntl locks affect threads in the same process... no
checking if flock locks affect threads in the same process... no
checking for entropy source... /dev/random

Checking for Time Support...
checking for tm_gmtoff in struct tm... yes

Checking for Networking support...
checking for in_addr in netinet/in.h... yes
checking if fd == socket on this platform... yes
checking if TCP_NODELAY setting is inherited from listening
sockets... yes
checking if O_NONBLOCK setting is inherited from listening sockets...
yes
checking for TCP_CORK in netinet/tcp.h... no
checking for TCP_NOPUSH in netinet/tcp.h... yes
checking for SO_ACCEPTFILTER in sys/socket.h... no
checking whether SCTP is supported... no
checking for set_h_errno... no

Checking for IPv6 Networking support...
checking for library containing getaddrinfo... none required
checking for library containing gai_strerror... none required
checking for library containing getnameinfo... none required
checking for gai_strerror... yes
checking for working getaddrinfo... yes
checking for negative error codes for getaddrinfo... no
checking for working getnameinfo... yes
checking for sockaddr_in6... yes
checking for sockaddr_storage... yes
checking for working AI_ADDRCONFIG... yes
checking if APR supports IPv6... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking for nl_langinfo... yes

Restore user-defined environment settings...
restoring CPPFLAGS to ""
setting EXTRA_CPPFLAGS to "-DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK
-no-cpp-precomp"
restoring CFLAGS to ""
setting EXTRA_CFLAGS to "-g -O2"
restoring LDFLAGS to ""
setting EXTRA_LDFLAGS to ""
restoring LIBS to ""
setting EXTRA_LIBS to "-lpthread"
restoring INCLUDES to ""
setting EXTRA_INCLUDES to ""

Construct Makefiles and header files.
configure: creating ./config.status
config.status: creating Makefile
config.status: creating test/Makefile
config.status: creating test/internal/Makefile
config.status: creating include/apr.h
config.status: creating build/apr_rules.mk
config.status: creating apr-1-config
config.status: creating apr.pc
config.status: creating include/arch/unix/apr_private.h
config.status: executing default commands
apr configured properly
checking APR version... 1.0.1
configure: Apache Portable Runtime Utility (APRUTIL) library
configuration
checking for APR-util... reconfig
configuring package in apr-util now
checking build system type... powerpc-apple-darwin8.0.0
checking host system type... powerpc-apple-darwin8.0.0
checking target system type... powerpc-apple-darwin8.0.0
checking for a BSD-compatible install... /usr/bin/install -c
checking for working mkdir -p... yes
APR-util Version: 1.0.1
checking for chosen layout... apr-util
Applying apr-util hints file rules for powerpc-apple-darwin8.0.0
checking for APR... yes
setting CC to "gcc"
setting CPP to "gcc -E"
setting CFLAGS to " -g -O2"
setting CPPFLAGS to " -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-
cpp-precomp"
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for ldap support...
checking gdbm.h usability... no
checking gdbm.h presence... no
checking for gdbm.h... no
checking for Berkeley DB 4.2 in the standard places...
checking db42/db.h usability... no
checking db42/db.h presence... no
checking for db42/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb-4.2... no
checking db42/db.h usability... no
checking db42/db.h presence... no
checking for db42/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb42... no
checking db42/db.h usability... no
checking db42/db.h presence... no
checking for db42/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb4... no
checking db42/db.h usability... no
checking db42/db.h presence... no
checking for db42/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb... no
checking for Berkeley DB 4.2 in /usr/local...
checking db42/db.h usability... no
checking db42/db.h presence... no
checking for db42/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb-4.2... no
checking db42/db.h usability... no
checking db42/db.h presence... no
checking for db42/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb42... no
checking db42/db.h usability... no
checking db42/db.h presence... no
checking for db42/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb4... no
checking db42/db.h usability... no
checking db42/db.h presence... no
checking for db42/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb... no
checking for Berkeley DB 4.2 in /usr/local/BerkeleyDB.4.2...
directory not found
checking for Berkeley DB 4.2 in /boot/home/config... directory not found
checking for Berkeley DB 4.1 in the standard places...
checking db41/db.h usability... no
checking db41/db.h presence... no
checking for db41/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb-4.1... no
checking db41/db.h usability... no
checking db41/db.h presence... no
checking for db41/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb41... no
checking db41/db.h usability... no
checking db41/db.h presence... no
checking for db41/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb4... no
checking db41/db.h usability... no
checking db41/db.h presence... no
checking for db41/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb... no
checking for Berkeley DB 4.1 in /usr/local...
checking db41/db.h usability... no
checking db41/db.h presence... no
checking for db41/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb-4.1... no
checking db41/db.h usability... no
checking db41/db.h presence... no
checking for db41/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb41... no
checking db41/db.h usability... no
checking db41/db.h presence... no
checking for db41/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb4... no
checking db41/db.h usability... no
checking db41/db.h presence... no
checking for db41/db.h... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb... no
checking for Berkeley DB 4.1 in /usr/local/BerkeleyDB.4.1...
directory not found
checking for Berkeley DB 4.1 in /boot/home/config... directory not found
checking for Berkeley DB 4.0 in the standard places...
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb-4.0... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb4... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb... no
checking for Berkeley DB 4.0 in /usr/local...
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb-4.0... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb4... no
checking db4/db.h usability... no
checking db4/db.h presence... no
checking for db4/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb... no
checking for Berkeley DB 4.0 in /usr/local/BerkeleyDB.4.0...
directory not found
checking for Berkeley DB 4.0 in /boot/home/config... directory not found
checking for Berkeley DB 3 in the standard places...
checking db3/db.h usability... no
checking db3/db.h presence... no
checking for db3/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb3... no
checking db3/db.h usability... no
checking db3/db.h presence... no
checking for db3/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for -ldb... no
checking for Berkeley DB 2 in the standard places...
checking db2/db.h usability... no
checking db2/db.h presence... no
checking for db2/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for db_open in -ldb2... no
checking db2/db.h usability... no
checking db2/db.h presence... no
checking for db2/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for db_open in -ldb... no
checking for Berkeley DB 1.0.0 in the standard places...
checking db1/db.h usability... no
checking db1/db.h presence... no
checking for db1/db.h... no
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for dbopen in -ldb1... no
checking for Berkeley DB 1 in the standard places...
checking db_185.h usability... no
checking db_185.h presence... no
checking for db_185.h... no
checking for Berkeley DB... not found
checking for default DBM... sdbm (default)
checking for Expat in /usr... no
checking for Expat in /usr/local... no
checking for Expat in xml/expat-cvs... no
checking for Expat in xml/expat... yes
configuring package in xml/expat now
checking build system type... powerpc-apple-darwin8.0.0
checking host system type... powerpc-apple-darwin8.0.0
checking target system type... powerpc-apple-darwin8.0.0
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -p
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 65536
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared
libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking dynamic linker characteristics... darwin8.0.0 dyld
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries... yes
checking for g++ option to produce PIC... -fno-common
checking if g++ PIC flag -fno-common works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking dynamic linker characteristics... darwin8.0.0 dyld
appending configuration tag "F77" to libtool
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ANSI C... (cached) none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for unistd.h... (cached) yes
checking for string.h... (cached) yes
checking whether byte ordering is bigendian... yes
checking for an ANSI C-conforming const... yes
checking for off_t... yes
checking for size_t... yes
checking for working memcmp... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for getpagesize... yes
checking for working mmap... yes
checking for memmove... yes
checking for bcopy... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating lib/Makefile
config.status: creating lib/expat.h
config.status: creating config.h
config.status: config.h is unchanged
xml/expat configured properly
setting APRUTIL_EXPORT_LIBS to "/Users/scottpalmer/dev/svn_test/
subversion/apr-util/xml/expat/lib/libexpat.la"
setting APRUTIL_INCLUDES to "-I/Users/scottpalmer/dev/svn_test/
subversion/apr-util/xml/expat/lib"
setting APRUTIL_LDFLAGS to "-L/Users/scottpalmer/dev/svn_test/
subversion/apr-util/xml/expat/lib"
setting APRUTIL_LIBS to "/Users/scottpalmer/dev/svn_test/
subversion/apr-util/xml/expat/lib/libexpat.la"
checking iconv.h usability... yes
checking iconv.h presence... yes
checking for iconv.h... yes
setting LIBS to "-liconv"
adding "-liconv" to APRUTIL_LIBS
adding "-liconv" to APRUTIL_EXPORT_LIBS
nulling LIBS
checking for type of inbuf parameter to iconv... const char **
checking for iconv.h... (cached) yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking for nl_langinfo... yes
checking for CODESET in langinfo.h... yes
checking for library containing crypt... none required
checking if system crypt() function is threadsafe... no
checking for crypt_r... no
adding "/Users/scottpalmer/dev/svn_test/subversion/apr/
libapr-1.la" to APRUTIL_LIBS
adding "-lpthread" to APRUTIL_LIBS
configure: creating ./config.status
config.status: creating export_vars.sh
config.status: creating apu-1-config
config.status: creating apr-util.pc
config.status: creating include/private/apu_select_dbm.h
config.status: creating include/apr_ldap.h
config.status: creating include/apu.h
config.status: creating include/apu_want.h
config.status: creating Makefile
config.status: creating test/Makefile
config.status: creating include/private/apu_config.h
config.status: include/private/apu_config.h is unchanged
config.status: executing default commands
apr-util configured properly
checking APR-UTIL version... 1.0.1
configuring libtool now
checking for a sed that does not truncate output... /usr/bin/sed
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -p
checking how to recognise dependent libraries... pass_all
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 65536
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared
libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking dynamic linker characteristics... darwin8.0.0 dyld
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries... yes
checking for g++ option to produce PIC... -fno-common
checking if g++ PIC flag -fno-common works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking dynamic linker characteristics... darwin8.0.0 dyld
appending configuration tag "F77" to libtool
checking whether libtool accepts --tag=XXX... yes
checking whether libtool needs -no-undefined... no
configure: checking neon library
checking neon library version... 0.24.7
Using neon found in source directory.
configuring package in neon now
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... powerpc-apple-darwin8.0.0
checking host system type... powerpc-apple-darwin8.0.0
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -p
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking the maximum length of command line arguments... 65536
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared
libraries... no
checking dynamic linker characteristics... darwin8.0.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
configure: creating libtool
checking for library containing strerror... none required
checking for inline... inline
checking for an ANSI C-conforming const... yes
checking for size_t... yes
checking for off_t... yes
checking for Darwin... yes
checking whether make sets $(MAKE)... yes
checking for int... yes
checking size of int... 4
checking for long... yes
checking size of long... 4
checking for long long... yes
checking size of long long... 8
checking for gcc -Wformat -Werror sanity... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking for string.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for size_t... (cached) yes
checking size of size_t... 4
checking how to print size_t... lu
checking for off_t... (cached) yes
checking size of off_t... 8
checking how to print off_t... qd
checking for ssize_t... yes
checking size of ssize_t... 4
checking how to print ssize_t... ld
checking for pid_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for ar... /usr/bin/ar
checking for ranlib... /usr/bin/ranlib
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for pipe... yes
checking for isatty... yes
checking for usleep... yes
checking for shutdown... yes
checking for time_t... yes
checking size of time_t... 4
checking how to print time_t... ld
checking whether byte ordering is bigendian... yes
checking whether strerror_r is declared... yes
checking for strerror_r... yes
checking whether strerror_r returns char *... no
checking for snprintf... yes
checking for vsnprintf... yes
checking for strings.h... (cached) yes
checking for sys/time.h... (cached) yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking netinet/tcp.h usability... yes
checking netinet/tcp.h presence... yes
checking for netinet/tcp.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking for strcasecmp... yes
checking for signal... yes
checking for setvbuf... yes
checking for setsockopt... yes
checking for stpcpy... yes
checking whether stpcpy is declared... yes
checking for library containing socket... none needed
checking for library containing gethostbyname... none needed
checking for getaddrinfo... yes
checking for gai_strerror... yes
checking for inet_ntop... yes
checking for working AI_ADDRCONFIG... no
checking for struct tm.tm_gmtoff... yes
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for inflate in -lz... yes
checking whether to enable ACL support in neon... yes
checking for krb5-config... /usr/bin/krb5-config
checking gssapi/gssapi.h usability... yes
checking gssapi/gssapi.h presence... yes
checking for gssapi/gssapi.h... yes
checking for gss_init_sec_context... yes
configure: GSSAPI authentication support enabled
checking gssapi/gssapi_generic.h usability... yes
checking gssapi/gssapi_generic.h presence... yes
checking for gssapi/gssapi_generic.h... yes
checking whether GSS_C_NT_HOSTBASED_SERVICE is declared... yes
checking whether to enable WebDAV support in neon... yes
configure: XML parser used: expat in /Users/scottpalmer/dev/svn_test/
subversion/apr-util/xml/expat/lib
configure: debugging is enabled
configure: creating ./config.status
config.status: creating neon-config
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating test/Makefile
config.status: creating neon.pc
config.status: creating config.h
config.status: config.h is unchanged
configure: Configured to build neon 0.24.7:

Install prefix: /usr/local
Compiler: gcc
XML Parser: expat in /Users/scottpalmer/dev/svn_test/
subversion/apr-util/xml/expat/lib
SSL library: No SSL support
zlib support: found in -lz
Build libraries: Shared=no, Static=yes

Now run 'make' to compile the neon library.

neon configured properly
checking for any extra libraries neon needs... -L/usr/local/lib -lz -
L/usr/lib -Wl,-search_paths_first -lgssapi_krb5 -lkrb5 -lk5crypto -
lkrb5support -lcom_err -lresolv
checking for static Apache module support... no
checking for Apache module support via DSO through APXS... no -
Unable to locate /usr/include/httpd/mod_dav.h
==================================================================
WARNING: skipping the build of mod_dav_svn
--with-apxs or --with-apache must be used
==================================================================
checking for socket in -lsocket... no
checking for msgfmt... none
checking for msgmerge... none
checking for xgettext... none
checking for ANSI C header files... (cached) yes
checking for an ANSI C-conforming const... yes
checking for size_t... yes
checking for working memcmp... yes
checking for vprintf... yes
checking for _doprnt... no
checking for symlink... yes
checking for readlink... yes
checking for python2... no
checking for python... /usr/bin/python
checking that the Python found is at least version 2.0... yes
checking for JDK... yes
checking for perl... /usr/bin/perl
checking for ruby... /usr/bin/ruby
checking for rb_hash_foreach()... no
configure: WARNING: The detected Ruby is too old for Subversion to use
configure: WARNING: A Ruby which has rb_hash_foreach is required to
use the
configure: WARNING: Subversion Ruby bindings
configure: WARNING: Upgrade to the official 1.8.2 release, or later
checking for swig... none
checking for makeinfo... /usr/bin/makeinfo
configure: creating ./config.status
config.status: creating Makefile
config.status: creating svn-config
config.status: creating tools/backup/hot-backup.py
config.status: creating contrib/client-side/svn_load_dirs.pl
config.status: creating contrib/client-side/svncopy.pl
config.status: creating contrib/client-side/testsvncopy.pl
config.status: creating tools/hook-scripts/commit-access-control.pl
config.status: creating tools/hook-scripts/commit-email.pl
config.status: creating tools/hook-scripts/propchange-email.pl
config.status: creating subversion/bindings/swig/perl/native/Makefile.PL
config.status: creating subversion/svn_private_config.h
config.status: subversion/svn_private_config.h is unchanged
config.status: executing mkdir-init commands
configure: WARNING: we have configured without BDB filesystem support


You don't seem to have Berkeley DB version 4.1.25 or newer
installed and linked to APR-UTIL. We have created Makefiles which
will build without the Berkeley DB back-end; your repositories will
use FSFS as the default back-end. You can find the latest version of
Berkeley DB here:
http://www.sleepycat.com/download/index.shtml

$ make
------ making all in apr
...
------ completed all in apr
------ making all in apr-util
Making all in xml/expat
...
------ completed all in apr-util
------ making all in neon
cd src && make
...
Compilation complete. Run 'make install' (as root?) to install neon.

------ completed all in neon
...
libtool: link: warning: `/usr/lib/gcc/powerpc-apple-
darwin8/4.0.0/../../..//libiconv.la' seems to be moved
... [above line appears several times throughout]

ld: multiple definitions of symbol __Unwind_DeleteException
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_DeleteException in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_DeleteException in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_FindEnclosingFunction
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_FindEnclosingFunction in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_FindEnclosingFunction in
section (__TEXT,__text)
ld: multiple definitions of symbol __Unwind_ForcedUnwind
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_ForcedUnwind in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_ForcedUnwind in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetDataRelBase
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetDataRelBase in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetDataRelBase in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetGR
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetGR in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetGR in section (__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetIP
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetIP in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetIP in section (__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetLanguageSpecificData
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetLanguageSpecificData in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetLanguageSpecificData in
section (__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetRegionStart
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetRegionStart in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetRegionStart in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetTextRelBase
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetTextRelBase in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetTextRelBase in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_RaiseException
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_RaiseException in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_RaiseException in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_Resume
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_Resume in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_Resume in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_SetGR
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_SetGR in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_SetGR in section (__TEXT,__text)
ld: multiple definitions of symbol __Unwind_SetIP
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_SetIP in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_SetIP in section (__TEXT,__text)
ld: multiple definitions of symbol ___frame_state_for
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
___frame_state_for in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of ___frame_state_for in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_Find_FDE
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of __Unwind_Find_FDE in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of __Unwind_Find_FDE in section
(__TEXT,__text)
ld: multiple definitions of symbol ___deregister_frame
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___deregister_frame in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___deregister_frame in
section (__TEXT,__text)
ld: multiple definitions of symbol ___deregister_frame_info
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___deregister_frame_info in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___deregister_frame_info in
section (__TEXT,__text)
ld: multiple definitions of symbol ___deregister_frame_info_bases
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___deregister_frame_info_bases in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of
___deregister_frame_info_bases in section (__TEXT,__text)
ld: multiple definitions of symbol ___register_frame
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___register_frame in section
(__TEXT,__text)
ld: multiple definitions of symbol ___register_frame_info
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame_info in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___register_frame_info in
section (__TEXT,__text)
ld: multiple definitions of symbol ___register_frame_info_bases
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame_info_bases in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___register_frame_info_bases
in section (__TEXT,__text)
ld: multiple definitions of symbol ___register_frame_info_table
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame_info_table in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___register_frame_info_table
in section (__TEXT,__text)
ld: multiple definitions of symbol ___register_frame_info_table_bases
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame_info_table_bases in section
(__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of
___register_frame_info_table_bases in section (__TEXT,__text)
ld: multiple definitions of symbol ___register_frame_table
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame_table in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___register_frame_table in
section (__TEXT,__text)
/usr/bin/libtool: internal link edit command failed
make: *** [subversion/libsvn_ra_dav/libsvn_ra_dav-1.la] Error 1

[Karan, Cem (Civ, ARL/CISD)]

This will most likely get you what you need:

./autogen.sh
./configure --enable-maintainer-mode --disable-shared GXX=yes
make
make check
make install

In past incarnations, you had to have GXX=yes to make everything work. In this current release (1.2 RC 3), it looks like all you really need is to disable the shared library support. This is because currently, the auto* tools call libtool to generate the shared libraries; unfortunately, Apple decided to create their own tool called libtool, and rename the GNU libtool to glibtool. This breaks the various auto* tools, as you can see from the tail end of your transcript.

I turn on the maintainer mode in the hopes that I'll see useful messages should svn crash or something. You don't need to if you don't want to. I also run all the tests to help ensure that nothing nasty has happened since the last release.

If you are REALLY stuck, I found that (at least on my system) if I compiled svn 1.1.4 on a 10.3.9 machine with --disable-shared, then it would run under 10.4. I didn't do any serious testing though, so you may want to run make check on it before trusting your system to it.

Good luck,
Cem Karan

-----Original Message-----
From: Scott Palmer [mailto:***@2connected.org]
Sent: Wed 11-May-05 09:47 AM
To: Subversion users group
Cc:
Subject: Building Subversion 1.2 on OS X 10.4 fails

I'm trying to build on OS X 10.4

I don't need BDB support and i don't have BDB installed (that I know
of).

It fails to build. Note that I was able to build a few weeks ago,
prior to updating to OS X 10.4

Here's a transcript (excuse the huge dump from ./configure, but I
didn't know what bits were relevant, the whole ./configure thing is a
complete mystery to me):

[Scott Palmer]

Post by Scott Palmer
./autogen.sh
./configure --enable-maintainer-mode --disable-shared GXX=yes
make
make check
make install
In past incarnations, you had to have GXX=yes to make everything
work. In this current release (1.2 RC 3), it looks like all you
really need is to disable the shared library support. This is
because currently, the auto* tools call libtool to generate the
shared libraries; unfortunately, Apple decided to create their own
tool called libtool, and rename the GNU libtool to glibtool. This
breaks the various auto* tools, as you can see from the tail end of
your transcript.

Thank you!

Just for kicks I tried moving Apple's libtool out of the way and
renaming glibtool to libtool and continuing my build. It did go
farther, but still ultimately failed with:

libtool: unrecognized option `-dynamic'
Try `libtool --help' for more information.
make[2]: *** [libapr-1.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [external-all] Error 1

So then I stopped trying to be smart and did what you said (without
the maintainer mode) and it compiled fine. Btw, do I need shared
libs to use the Java HL bindings ?

Scott

[Stephen Davis]

Post by Scott Palmer

Post by Scott Palmer
./autogen.sh
./configure --enable-maintainer-mode --disable-shared GXX=yes
make
make check
make install
In past incarnations, you had to have GXX=yes to make everything
work. In this current release (1.2 RC 3), it looks like all you
really need is to disable the shared library support. This is
because currently, the auto* tools call libtool to generate the
shared libraries; unfortunately, Apple decided to create their own
tool called libtool, and rename the GNU libtool to glibtool. This
breaks the various auto* tools, as you can see from the tail end of
your transcript.

Thank you!
Just for kicks I tried moving Apple's libtool out of the way and
renaming glibtool to libtool and continuing my build. It did go
libtool: unrecognized option `-dynamic'
Try `libtool --help' for more information.
make[2]: *** [libapr-1.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [external-all] Error 1
So then I stopped trying to be smart and did what you said (without
the maintainer mode) and it compiled fine. Btw, do I need shared libs
to use the Java HL bindings ?

It works fine shared if you do:

GXX=yes ./configure --without-berkeley-db --with-zlib
--enable-shared=yes --with-ssl

You don't have to turn off bdb, I just have that turned off for my own
needs.

No need for maintainer mode or autogen.sh.

stephen

[Scott Palmer]

Post by Scott Palmer
./autogen.sh
./configure --enable-maintainer-mode --disable-shared GXX=yes
make
make check
make install
In past incarnations, you had to have GXX=yes to make everything
work. In this current release (1.2 RC 3), it looks like all you
really need is to disable the shared library support. This is
because currently, the auto* tools call libtool to generate the
shared libraries; unfortunately, Apple decided to create their
own tool called libtool, and rename the GNU libtool to glibtool.
This breaks the various auto* tools, as you can see from the tail
end of your transcript.

GXX=yes ./configure --without-berkeley-db --with-zlib --enable-
shared=yes --with-ssl
You don't have to turn off bdb, I just have that turned off for my
own needs.
No need for maintainer mode or autogen.sh.

Ok, so what exactly is the key to making it work? One person says
"it looks like all you really need is to disable the shared library
support", but apparently that isn't required. How is "-with-zlib --
enable-shared=yes --with-ssl" different from the defaults? I assumed
that without "--disable-shared" that "--enable-shared=yes" is
implied. Same for "--with-zlib" and "--with-ssl" .. aren't they
normally enabled with a standard "./configure" ????

Any ideas why renaming glibtool so that it is used isn't enough?

Scott

[Stephen Davis]

Post by Stephen Davis

Post by Scott Palmer
./autogen.sh
./configure --enable-maintainer-mode --disable-shared GXX=yes
make
make check
make install
In past incarnations, you had to have GXX=yes to make everything
work. In this current release (1.2 RC 3), it looks like all you
really need is to disable the shared library support. This is
because currently, the auto* tools call libtool to generate the
shared libraries; unfortunately, Apple decided to create their own
tool called libtool, and rename the GNU libtool to glibtool. This
breaks the various auto* tools, as you can see from the tail end of
your transcript.

GXX=yes ./configure --without-berkeley-db --with-zlib
--enable-shared=yes --with-ssl
You don't have to turn off bdb, I just have that turned off for my
own needs.
No need for maintainer mode or autogen.sh.

Ok, so what exactly is the key to making it work? One person says "it
looks like all you really need is to disable the shared library
support", but apparently that isn't required. How is "-with-zlib
--enable-shared=yes --with-ssl" different from the defaults? I assumed
that without "--disable-shared" that "--enable-shared=yes" is implied.
Same for "--with-zlib" and "--with-ssl" .. aren't they normally
enabled with a standard "./configure" ????

The bundled neon library will not enable SSL unless --with-ssl is
passed in. This is in the subversion FAQ I think.

The bundled neon library will fail to build shared if GXX=yes is not
specified. On Panther, this was silently ignored. On Tiger, it fails
the build (last I checked).

--enable-shared=yes is just another hint to neon that it should build
shared. It may or may not be necessary in the presence of GXX=yes.

I'm not sure --with-zlib is required b/c configure may find it anyway
but it's explicitly listed in "./configure --help" so I thought I would
add it.

Any ideas why renaming glibtool so that it is used isn't enough?

I'm sure that works too but I'd rather not rename my system-supplied
binaries if I don't have to.

As you can see, there are many ways to skin the cat. If something
doesn't build straight out of the box (e.g. ./configure), then lots of
people just whack on stuff until it works. I know I do. Cem and I
obviously used different approaches to solve the problem and both are
valid depending on what you need. If you don't need shared libaries,
then turn 'em off. If you want SSL, add "--with-ssl". It's just the
magic and pain that is autoconf. :-)

stephen

[Scott Palmer]

Post by Stephen Davis

Post by Scott Palmer
Any ideas why renaming glibtool so that it is used isn't enough?

I'm sure that works too but I'd rather not rename my system-
supplied binaries if I don't have to.

You misunderstood. I DID rename that as an experiment and it was
NOT enough. It did fix some libtool related issues, but the build
still failed.

Post by Stephen Davis
As you can see, there are many ways to skin the cat. If something
doesn't build straight out of the box (e.g. ./configure), then lots
of people just whack on stuff until it works. I know I do.

I haven't got THAT much free time. Quite frankly, if it doesn't work
"straight out of the box" it's broken, and just because it's open
source doesn't mean it's MY job to fix it.

Post by Stephen Davis
Cem and I obviously used different approaches to solve the
problem and both are valid depending on what you need. If you
don't need shared libaries, then turn 'em off. If you want SSL,
add "--with-ssl". It's just the magic and pain that is autoconf. :-)

I agree with the part about "pain" :)

To be honest I find the entire process of "./configure" utterly
ridiculous. For example: It checks for things like stdlib.h - if you
have a C compiler that doesn't have this file you have much bigger
problems than compiling subversion. It checks for fortran compilers
- why? subversion is written in C. I could go on, but the point is
that the massive amount of "checking" just goes to show that there is
something so fundamentally wrong with the entire process that it just
makes me sad.

Part of my question was meant to be "do I need shared libraries?"
with respect to javahl, I wasn't sure if javahl required shared
libraries... but I seem to have compiled it so I guess not.

Thanks for the help.

Scott

[Ben Collins-Sussman]

Post by Scott Palmer
To be honest I find the entire process of "./configure" utterly
ridiculous.

Perhaps you don't remember what the world was like before autoconf
existed? Eek.

Post by Scott Palmer
For example: It checks for things like stdlib.h - if you have a C
compiler that doesn't have this file you have much bigger problems
than compiling subversion. It checks for fortran compilers - why?
subversion is written in C. I could go on, but the point is that
the massive amount of "checking" just goes to show that there is
something so fundamentally wrong with the entire process that it
just makes me sad.

Fundamentally wrong? autoconf solves the problem of portability
better than anyone could have possibly dreamed of 20 years ago.
There's a reason it's the "standard'. Is it pleasant? No. Does it
greet you in the morning with french toast, the daily paper, and a
smile? No. Does it alleviate tremendous portability pain? Absolutely.

The behavior you're seeing is simply a bunch of pre-packaged tests
that are par for the course, part of the standard AC macros.
Subversion doesn't care about stdlib or fortran, it just asks that a
C compiler and preprocessor be present:

(from configure.in:)

dnl Look for a C compiler (before anything can set CFLAGS)
AC_PROG_CC

dnl Look for a C pre-processor
AC_PROG_CPP

[Scott Palmer]

Post by Ben Collins-Sussman

Post by Scott Palmer
To be honest I find the entire process of "./configure" utterly
ridiculous.

Perhaps you don't remember what the world was like before autoconf
existed? Eek.

I've been programming since the mid 80's and thankfully I never had
to deal with what you imply was a worse mess. I suspect perhaps the
problem is mostly with unix.

Post by Ben Collins-Sussman

Post by Scott Palmer
For example: It checks for things like stdlib.h - if you have a
C compiler that doesn't have this file you have much bigger
problems than compiling subversion. It checks for fortran
compilers - why? subversion is written in C. I could go on, but
the point is that the massive amount of "checking" just goes to
show that there is something so fundamentally wrong with the
entire process that it just makes me sad.

Fundamentally wrong?

Yes. It's ludicrous, pathetically so. What part of checking for
fortran 77 to compile 'C' do you find reasonable?

When I run ./configure I shake my head and wonder "what were they
thinking?" Just what went so bad that THIS was considered the
solution? It's not so much that the solution is "fundamentally
wrong", it's the situation that leads to such a solution.

As you wrote "Subversion doesn't care about stdlib or fortran, it
just asks that a C compiler and preprocessor be present."

A C compiler is a prerequisite for compiling C code - brilliant..
let's write a tool that takes forever to scan my system (in two
stages ./autogen.sh and ./configure) to see if I have one, rather
than simply running 'make' and seeing it complain if I don't. ;-) I
can get the error message from autoconf after watching it go through
a ton of useless stuff, or I can get the error message instantly from
'make'.

Strangely enough on my Mac 'cc' invokes the C complier, like it does
on every unix-ish system I've ever seen. What problem is autoconf
solving for me again?

What is fundamentally wrong is that autoconf is needed at all.

I'm obviously missing the bit that makes any of this a sane process.
And I'm quite happy to remain ignorant :-)

Scott

[Holger Rauch]

Hi Scott!

Post by Scott Palmer

Post by Ben Collins-Sussman

Post by Scott Palmer
To be honest I find the entire process of "./configure" utterly
ridiculous.

Perhaps you don't remember what the world was like before autoconf
existed? Eek.

I've been programming since the mid 80's and thankfully I never had
to deal with what you imply was a worse mess. I suspect perhaps the
problem is mostly with unix.

Well, what did YOU have to deal with then?

And no, the problem is not limited to Unix, porting software from one
version of Winblows to another can be a nightmare as well (if Microsoft
simply changed some APIs)...

Another reason why autoconf exists is to *standardize* these checks. Before
the existence of autoconf, each programmer either wrote his own checks, or
worse, simply omitted them for the sake of making assumptions.
Unfortunately, in quite a few cases, these assumptions didn't prove to be
true...

Post by Scott Palmer

Post by Ben Collins-Sussman

Post by Scott Palmer
For example: It checks for things like stdlib.h - if you have a
C compiler that doesn't have this file you have much bigger
problems than compiling subversion. It checks for fortran
compilers - why? subversion is written in C. I could go on, but
the point is that the massive amount of "checking" just goes to
show that there is something so fundamentally wrong with the
entire process that it just makes me sad.

The reason for this is basically that the configure shell script includes a
set of standard checks when it was initially created by running "autoscan".
This tool creates a configure.scan file which includes these standard checks
in the correct order. Later on, configure.scan is renamed to configure.in,
further checks (m4 macros usually starting with AC_) are added by the
developer(s) and then autoconf is run in order to actually create the
configure shell script that performs these checks when it is invoked.

Post by Scott Palmer
Yes. It's ludicrous, pathetically so. What part of checking for
fortran 77 to compile 'C' do you find reasonable?

You're right that not all of the checks performed are reasonable for the
particular case of compiling Subversion, BUT see my statement above :-)

Post by Scott Palmer
When I run ./configure I shake my head and wonder "what were they
thinking?"

Should be a bit more obvious from what I said above.

Post by Scott Palmer
Just what went so bad that THIS was considered the
solution?

Yes, because it's a *standardized* solution.

Post by Scott Palmer
It's not so much that the solution is "fundamentally
wrong", it's the situation that leads to such a solution.

Well the situation regarding portability of software was much worse at the
time when autoconf was created. Things have become better now with the POSIX
standard, but there are still some differences between the BSD and SYSV
flavors of Unix.

Apart from that, note that there are also checks for 3rd party packages,
which are quite useful when compiling Subversion.

Post by Scott Palmer
A C compiler is a prerequisite for compiling C code - brilliant..

Yep. Bear in mind that

/1/ C compilers can be named differently from system to system (dependent on
which implementation is installed). For instance, a C compiler can be
named cc but it can also be named xlc (AIX C compiler).
/2/ There can be more than one implementation of a C compiler installed on a
particular system (gcc in addition to implementation provided by the
vendor)

Post by Scott Palmer
let's write a tool that takes forever to scan my system (in two
stages ./autogen.sh and ./configure) to see if I have one, rather
than simply running 'make' and seeing it complain if I don't. ;-) I
can get the error message from autoconf after watching it go through
a ton of useless stuff, or I can get the error message instantly from
'make'.

Ah, you're saying that making the programmer messing around with makefiles
is better than having a correct one automatically generated for you (in case
you pass the right option to configure)?

Post by Scott Palmer
Strangely enough on my Mac 'cc' invokes the C complier, like it does
on every unix-ish system I've ever seen. What problem is autoconf
solving for me again?

See above.

Post by Scott Palmer
What is fundamentally wrong is that autoconf is needed at all.

Right, but blame the different Unix vendors. Furthermore, each developer has
the freedom to install Berkeley DB by compiling it by himself or use the
implementation shipped with his Linux/BSD/whatever distribution. autoconf
provides support for such cases.

Post by Scott Palmer
I'm obviously missing the bit that makes any of this a sane process.

Hope it all is a bit clearer now...

Post by Scott Palmer
And I'm quite happy to remain ignorant :-)

You seriously consider this a good attitude???

Kind regards,

Holger

[Ulrich Eckhardt]

Post by Holger Rauch

Post by Scott Palmer

Post by Ben Collins-Sussman

Post by Scott Palmer
To be honest I find the entire process of "./configure" utterly
ridiculous.

Perhaps you don't remember what the world was like before autoconf
existed? Eek.

I've been programming since the mid 80's and thankfully I never had
to deal with what you imply was a worse mess. I suspect perhaps the
problem is mostly with unix.

Well, what did YOU have to deal with then?
And no, the problem is not limited to Unix, porting software from one
version of Winblows to another can be a nightmare as well (if Microsoft
simply changed some APIs)...
Another reason why autoconf exists is to *standardize* these checks. Before
the existence of autoconf, each programmer either wrote his own checks, or
worse, simply omitted them for the sake of making assumptions.
Unfortunately, in quite a few cases, these assumptions didn't prove to be
true...

Post by Scott Palmer

Post by Ben Collins-Sussman

Post by Scott Palmer
For example: It checks for things like stdlib.h - if you have a
C compiler that doesn't have this file you have much bigger
problems than compiling subversion. It checks for fortran
compilers - why? subversion is written in C. I could go on, but
the point is that the massive amount of "checking" just goes to
show that there is something so fundamentally wrong with the
entire process that it just makes me sad.

The reason for this is basically that the configure shell script includes a
set of standard checks when it was initially created by running "autoscan".
This tool creates a configure.scan file which includes these standard
checks in the correct order. Later on, configure.scan is renamed to
configure.in, further checks (m4 macros usually starting with AC_) are
added by the developer(s) and then autoconf is run in order to actually
create the configure shell script that performs these checks when it is
invoked.

Post by Scott Palmer
Yes. It's ludicrous, pathetically so. What part of checking for
fortran 77 to compile 'C' do you find reasonable?

You're right that not all of the checks performed are reasonable for the
particular case of compiling Subversion, BUT see my statement above :-)

Post by Scott Palmer
When I run ./configure I shake my head and wonder "what were they
thinking?"

Should be a bit more obvious from what I said above.

Post by Scott Palmer
Just what went so bad that THIS was considered the
solution?

Yes, because it's a *standardized* solution.

Post by Scott Palmer
It's not so much that the solution is "fundamentally
wrong", it's the situation that leads to such a solution.

Well the situation regarding portability of software was much worse at the
time when autoconf was created. Things have become better now with the
POSIX standard, but there are still some differences between the BSD and
SYSV flavors of Unix.
Apart from that, note that there are also checks for 3rd party packages,
which are quite useful when compiling Subversion.

Post by Scott Palmer
A C compiler is a prerequisite for compiling C code - brilliant..

Yep. Bear in mind that
/1/ C compilers can be named differently from system to system (dependent
on which implementation is installed). For instance, a C compiler can be
named cc but it can also be named xlc (AIX C compiler).
/2/ There can be more than one implementation of a C compiler installed on
a particular system (gcc in addition to implementation provided by the
vendor)

There is no need for autotools for this. A sane make tool knows $(CC) and if
you want to change that you can set it in the environment - which also works
with configure, but to the extent that it is fixed after the configure call,
so you don't have to make the same settings for compiling in a different
shell.

Post by Holger Rauch

Post by Scott Palmer
let's write a tool that takes forever to scan my system (in two
stages ./autogen.sh and ./configure) to see if I have one, rather
than simply running 'make' and seeing it complain if I don't. ;-) I
can get the error message from autoconf after watching it go through
a ton of useless stuff, or I can get the error message instantly from
'make'.

Ah, you're saying that making the programmer messing around with makefiles
is better than having a correct one automatically generated for you (in
case you pass the right option to configure)?

A properly written makefile doesn't define anything like CC=gcc or other
similar atrocities. At most it supplements the existing settings.

Post by Holger Rauch

Post by Scott Palmer
Strangely enough on my Mac 'cc' invokes the C complier, like it does
on every unix-ish system I've ever seen. What problem is autoconf
solving for me again?

See above.

Post by Scott Palmer
What is fundamentally wrong is that autoconf is needed at all.

Right, but blame the different Unix vendors. Furthermore, each developer
has the freedom to install Berkeley DB by compiling it by himself or use
the implementation shipped with his Linux/BSD/whatever distribution.
autoconf provides support for such cases.

Just as a well written makefile does with CPPFLAGS and LDFLAGS.

All this said, I use autotools for every non-trivial project because of its
dependency tracking, easy creation and installation of programs and
libraries, aforementioned saved configuration vs having to set them on every
compilation, having different configurations in different build dirs and the
checks it performs on the system. Yes, there is some serious pain involved
seeing which is also what the original ranter was annoyed by, but in the end
it's not so bad - in fact quite a few times some sensible checks did help me
getting things up and running quicker than if I had not had them.

Oh, btw: be happy that you don't have to mess with autotools integration,
Scott, that is where The Real Pain(tm) is. ;)

Uli

[Steve Greenland]

Post by Holger Rauch
Ah, you're saying that making the programmer messing around with makefiles
is better than having a correct one automatically generated for you (in case
you pass the right option to configure)?

If autoconf actually reliably created working Makefiles et. al., it
would be tolerable. But it doesn't. It breaks in completely undebuggable
ways, and breaks differently on every new release (of autoconf,
not subversion). And don't even get me started on the whole option
nightmare.

So yes, I would rather spend 1 minute editing a Makefile than 10 or 20
minutes watching configure repeatedly look for stdio.h. (Even that would
be tolerable if it then didn't also check for printf(), etc. etc. etc.)

And then, of course, is the horrible #ifdef code mess that using
autoconf encourages. There are good ways and bad ways to achieve code
portability. Automating the worst one was a Bad Idea.

Steve

[Helge Jensen]

I've been programming since the mid 80's and thankfully I never had to
deal with what you imply was a worse mess. I suspect perhaps the
problem is mostly with unix.

No matter who's fault it is, compilitaion won't succeed on a multitude
of platforms unless you solve these problems.

When I run ./configure I shake my head and wonder "what were they
thinking?" Just what went so bad that THIS was considered the
solution? It's not so much that the solution is "fundamentally wrong",
it's the situation that leads to such a solution.

You don't *have* to run configure. Try making your own makefile and see
how you fare -- now try that makefile on another platform (not another
gnu-make, gcc, gld one, try HPUX with it's make, CC and linker).

One problem is that you will have to write, not only *what* has to be
done (compile foo.c), but also how: ($(CC) -o ...). (BTW: not all
compilers support "-o" or even "-c".

Another problem is that you want to use the available extensions to
standard functions, and the right structs for their arguments.
While this can be achived via long "#if .... #elif ... " chanins, this
has the problem of requering code-change for (almost) every tuple of
(compiler, library, os). Autoconf can do better: it tries the compiler
and sees what is available.

Make is a very poor language (not GNU-make, make). Automake+autoconf is
a compiler from the "high-level" language of Makefile.am and
configure.in to a combination of sh and make.

The reason another Makefile-approach works for the Linux kernel is that
it only compiles only with gnu-make, gcc, on linux and doesn't use any
diversity of libraries.

error message from autoconf after watching it go through a ton of
useless stuff, or I can get the error message instantly from 'make'.

Try porting your software to a non-GNU system. The problem is *there*.
Make does not solve the problem that autoconf/automake does.

BTW: you don't write "./autogen.sh && make" to compile, do you? You
really only need to invoke autoconf when the code is just checked out.

make of automake generated makefiles should only re-run configure when
configure.in changes.

What is fundamentally wrong is that autoconf is needed at all.

While that may be true, so is the state of the world. Refusing to accept
that will not improve things.

Autoconf is the current defacto solution, not because it's "stadard" or
endorsed by a huge company, but because it competed with other solutions
(the horrible "imake" for one) and won (for the time being).

Autoconf is not perfect, but perfect isn't really always needed and
autoconf seems to be doing quite ok.

I'm obviously missing the bit that makes any of this a sane process.
And I'm quite happy to remain ignorant :-)

autoconf and automake is actually what allows you to remain ignorant yet
still compile vast amounts of software ;)

[Ben Collins-Sussman]

Post by Helge Jensen

Post by Scott Palmer
What is fundamentally wrong is that autoconf is needed at all.

While that may be true, so is the state of the world. Refusing to
accept that will not improve things.

Well explained, Helge.

Anyone can create a simple standalone Makefile that will run on
nearly every distribution of Linux. But try having that Makefile
work on all flavors of SunOS, HP-UX, AIX, IRIX, Tru64, FreeBSD,
NetBSD, Darwin... and work with every possible C compiler, both free
and commercial, installed in different locations on each syste.m
Heck, even the basic C libraries have different quirky behaviors on
each system!

At my previous job, they refused to use autoconf, and my job *was* to
do exactly this. Our product had to compile on 7 flavors of Unix,
and my job was to write a Makefile / build system. It was the
biggest nightmare ever... huge, complex, impossible to maintain.
Contrast that against a few macro calls in configure.in: "find a C
compiler", "does the system have X feature? how about this other
feature?". And it *works*, because autoconf is a gigantic library of
knowledge, a compendium of OS-specific quirks and workarounds
gathered from thousands of programmers over many years. When you use
it, you're standing on the shoulders of everyone's collective
experience.

I think the problem is that Scott is grimacing at the the ugliness of
the cure, having never seen the horror of the original disease. :-)

That said, the world is slowly changing; Linux and BSD are pushing
Unix back towards unification again. It's gotten to the point where
non-GNU systems (like SunOS) are now considered 'eclectic'
platforms. Who'da thunk it?

OK, have we wandered off-topic enough yet?

[Scott Palmer]

Post by Ben Collins-Sussman
I think the problem is that Scott is grimacing at the the ugliness
of the cure,
having never seen the horror of the original disease. :-)

That's certainly part of it. One wonders how such systems attract
enough developers to survive.

Post by Ben Collins-Sussman
it *works*, because autoconf is a gigantic library of knowledge, a
compendium of OS-specific quirks and workarounds gathered from
thousands of programmers over many years. When you use it, you're
standing on the shoulders of everyone's collective experience.

I think that is as much of the problem as it is a solution..
everyone and their dog took out their duct tape to patch one tiny
hole which happened to work for their one specific issue on there one
specific system... repeat that thousands of times and the result is
not going to be pretty.

No matter how bad the problem was in the past - I do not believe
there is a reason to check for fortran 77 before compiling
Subversion :). I also doubt very much that there is a supported
system in existence today that has 'C' but not 'stdio.h'. Quite
likely half of the collective knowledge in autoconf is obsolete -
simply because it only made sense for one of those thousands of
programmers on one specific system and such system combinations have
never occurred since.

Anyway... yes we are sufficiently off-topic... I only brought it up
because, well, it didn't actually work (see the earlier in the
thread). So I figured that was enough justification to go on a
little rant :)

I've vented and I am happy again.

Scott

[K. Richard Pixley]

Post by Ben Collins-Sussman
Anyone can create a simple standalone Makefile that will run on
nearly every distribution of Linux. But try having that Makefile
work on all flavors of SunOS, HP-UX, AIX, IRIX, Tru64, FreeBSD,
NetBSD, Darwin... and work with every possible C compiler, both free
and commercial, installed in different locations on each syste.m
Heck, even the basic C libraries have different quirky behaviors on
each system!

Been there, done that. See the configuration system for binutils or gdb.

Post by Ben Collins-Sussman
At my previous job, they refused to use autoconf, and my job *was* to
do exactly this. Our product had to compile on 7 flavors of Unix,
and my job was to write a Makefile / build system. It was the
biggest nightmare ever... huge, complex, impossible to maintain.
Contrast that against a few macro calls in configure.in: "find a C
compiler", "does the system have X feature? how about this other
feature?". And it *works*, because autoconf is a gigantic library of
knowledge, a compendium of OS-specific quirks and workarounds
gathered from thousands of programmers over many years. When you use
it, you're standing on the shoulders of everyone's collective
experience.

No, I'm at the mercy of a very few people's experience - namely, those
that understand the tests enough to write them and those who spend many
hours tuning the tests to fit their package.

Clearly this hasn't been done for subversion. It if had, I'd have a
working subversion right now and wouldn't even both to participate in
this discussion. As is, I can't build it out of the box, there are no
available binary packages, and so I'm stuck for a while.

Ho, hum.

--rich

[Ben Collins-Sussman]

Post by K. Richard Pixley
Clearly this hasn't been done for subversion. It if had, I'd have
a working subversion right now and wouldn't even both to
participate in this discussion. As is, I can't build it out of the
box, there are no available binary packages, and so I'm stuck for a
while.

I find your attitude awfully judgemental. There's no need to respond
with bile to every single mail in this thread. I'm sorry you're
having problems, but you're making quite an unfair accusation.

Our configure.in isn't some two-bit hack thrown together. It was
written by folks who know what they're doing, evolved and tested over
the years. A good number of core Subversion developers use OSX...
including me. We've not had any problems with configuration. We
test the tarballs we release, in fact, which includes unpacking, ./
configure && make. We've haven't seen any problems on OSX, or we
wouldn't have released the tarball.

So, let's work to figure out what's so special about your & Scott's
systems, and fix the problem.

[K. Richard Pixley]

Post by Ben Collins-Sussman
I find your attitude awfully judgemental.

Heard.

Post by Ben Collins-Sussman
So, let's work to figure out what's so special about your & Scott's
systems, and fix the problem.

Mine's pretty much virgin. Unfortunately, I can't wipe and reload right
now to prove/test that, though.

--rich

[Scott Palmer]

Post by Ben Collins-Sussman
So, let's work to figure out what's so special about your & Scott's
systems, and fix the problem.

Well I have a standard install of 10.4.1. I upgraded to 10.4 from
10.3.9. I installed the new dev tools that came with 10.4. I
installed the 10.4.1 update. I try yo keep the tools up to date, but
I haven't done anything to alter the standard configuration that I
can think of. As I stated before, I don't have BDB or Apache 2
installed and I don't need it.

This is what I tried. Note that there are some warnings in the
configure process, I'm not sure how serious they are.

$ svn info
Path: .
URL: http://svn.collab.net/repos/svn/branches/1.2.x
Repository UUID: 65390229-12b7-0310-b90b-f21a5aa7ec8e
Revision: 14770
Node Kind: directory
Schedule: normal
Last Changed Author: djh
Last Changed Rev: 14760
Last Changed Date: 2005-05-16 19:44:46 -0400 (Mon, 16 May 2005)
Properties Last Updated: 2005-03-22 13:01:35 -0500 (Tue, 22 Mar 2005)

$ ./autogen.sh
buildcheck: checking installation...
buildcheck: autoconf version 2.59 (ok)
buildcheck: autoheader version 2.59 (ok)
buildcheck: libtool version 1.5 (ok)
buildcheck: local copy of PrintPath does not match APR's copy.
An updated copy of PrintPath may need to be checked in.
Copying libtool helper: /usr/share/aclocal/libtool.m4
Creating build-outputs.mk...
Creating svn_private_config.h.in...
Creating configure...
Creating configuration files for apr.
buildconf: checking installation...
buildconf: python version 2.3.5 (ok)
buildconf: autoconf version 2.59 (ok)
buildconf: libtool version 1.5 (ok)
Copying libtool helper files ...
buildconf: Using libtool.m4 at /usr/share/aclocal/libtool.m4.
Creating include/arch/unix/apr_private.h.in ...
autoheader: WARNING: Using auxiliary files such as `acconfig.h',
`config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for
`config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be
produced, see the
autoheader: WARNING: documentation.
Creating configure ...
Generating 'make' outputs ...
rebuilding rpm spec file
Creating configuration files for apr-util.

Looking for apr source in ../apr
Creating include/private/apu_config.h ...
Creating configure ...
Generating 'make' outputs ...
Invoking xml/expat/buildconf.sh ...
Copying libtool helper files ...
Incorporating /usr/share/aclocal/libtool.m4 into aclocal.m4 ...
Creating config.h.in ...
autoheader: WARNING: Using auxiliary files such as `acconfig.h',
`config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for
`config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be
produced, see the
autoheader: WARNING: documentation.
Creating configure ...
rebuilding rpm spec file

You can run ./configure now.

Running autogen.sh implies you are a maintainer. You may prefer
to run configure in one of the following ways:

./configure --enable-maintainer-mode
./configure --disable-shared
./configure --enable-maintainer-mode --disable-shared

Note: If you wish to run a Subversion HTTP server, you will need
Apache 2.0. See the INSTALL file for details.

$ ./configure
...
...

configure: WARNING: we have configured without BDB filesystem support


You don't seem to have Berkeley DB version 4.1.25 or newer
installed and linked to APR-UTIL. We have created Makefiles which
will build without the Berkeley DB back-end; your repositories will
use FSFS as the default back-end. You can find the latest version of
Berkeley DB here:
http://www.sleepycat.com/download/index.shtml

[that's okay with me]

$ make clean
rm [lots of stuff]
...

$ make
...
...
/bin/sh ../libtool --quiet --mode=compile gcc -DHAVE_CONFIG_H -no-
cpp-precomp -I/usr/include -I/Users/scottpalmer/dev/svn_test/
subversion/apr-util/xml/expat/lib -g -O2 -I.. -DNEON_ZLIB -c
ne_stubssl.c -o ne_stubssl.lo
/bin/sh ../libtool --quiet --mode=link gcc -flat_namespace -rpath /
usr/local/lib -version-info 24:7:0 -o libneon.la ne_request.lo
ne_session.lo ne_basic.lo ne_string.lo ne_uri.lo ne_dates.lo
ne_alloc.lo ne_md5.lo ne_utils.lo ne_socket.lo ne_auth.lo
ne_cookies.lo ne_redirect.lo ne_compress.lo ne_207.lo ne_xml.lo
ne_props.lo ne_locks.lo ne_acl.lo ne_stubssl.lo -lz -L/usr/lib -Wl,-
search_paths_first -lgssapi_krb5 -lkrb5 -lk5crypto -lkrb5support -
lcom_err -lresolv /Users/scottpalmer/dev/svn_test/subversion/apr-util/
xml/expat/lib/libexpat.la

Compilation complete. Run 'make install' (as root?) to install neon.

------ completed all in neon

[so far so good...]

...

cd subversion/libsvn_subr && /bin/sh /Users/scottpalmer/dev/svn_test/
subversion/libtool --tag=CC --silent --mode=link gcc -g -O2 -g -O2
-DNEON_ZLIB -L/Users/scottpalmer/dev/svn_test/subversion/apr-util/
xml/expat/lib -rpath /usr/local/lib -o libsvn_subr-1.la auth.lo
cmdline.lo config.lo config_auth.lo config_file.lo config_win.lo
ctype.lo date.lo error.lo hash.lo io.lo lock.lo md5.lo opt.lo path.lo
pool.lo quoprint.lo sorts.lo stream.lo subst.lo svn_base64.lo
svn_string.lo target.lo time.lo utf.lo utf_validate.lo validate.lo
version.lo xml.lo /Users/scottpalmer/dev/svn_test/subversion/apr-util/
libaprutil-1.la /Users/scottpalmer/dev/svn_test/subversion/apr-util/
xml/expat/lib/libexpat.la -liconv /Users/scottpalmer/dev/svn_test/
subversion/apr/libapr-1.la -lpthread
libtool: link: warning: `/usr/lib/gcc/powerpc-apple-
darwin8/4.0.0/../../..//libiconv.la' seems to be moved

[should I be concerned?]

...

cd subversion/libsvn_ra_dav && /bin/sh /Users/scottpalmer/dev/
svn_test/subversion/libtool --tag=CC --silent --mode=link gcc -g -
O2 -g -O2 -DNEON_ZLIB -L/Users/scottpalmer/dev/svn_test/subversion/
apr-util/xml/expat/lib -rpath /usr/local/lib -o libsvn_ra_dav-1.la
commit.lo fetch.lo file_revs.lo log.lo merge.lo options.lo props.lo
session.lo util.lo ../../subversion/libsvn_delta/
libsvn_delta-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /
Users/scottpalmer/dev/svn_test/subversion/apr-util/libaprutil-1.la /
Users/scottpalmer/dev/svn_test/subversion/apr-util/xml/expat/lib/
libexpat.la -liconv /Users/scottpalmer/dev/svn_test/subversion/apr/
libapr-1.la -lpthread /Users/scottpalmer/dev/svn_test/subversion/neon/
src/libneon.la -L/usr/local/lib -lz -L/usr/lib -Wl,-
search_paths_first -lgssapi_krb5 -lkrb5 -lk5crypto -lkrb5support -
lcom_err -lresolv
libtool: link: warning: `/usr/lib/gcc/powerpc-apple-
darwin8/4.0.0/../../..//libiconv.la' seems to be moved
libtool: link: warning: `/usr/lib/gcc/powerpc-apple-
darwin8/4.0.0/../../..//libiconv.la' seems to be moved
libtool: link: warning: `/usr/lib/gcc/powerpc-apple-
darwin8/4.0.0/../../..//libiconv.la' seems to be moved
ld: multiple definitions of symbol __Unwind_DeleteException
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_DeleteException in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_DeleteException in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_FindEnclosingFunction
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_FindEnclosingFunction in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_FindEnclosingFunction in
section (__TEXT,__text)
ld: multiple definitions of symbol __Unwind_ForcedUnwind
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_ForcedUnwind in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_ForcedUnwind in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetDataRelBase
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetDataRelBase in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetDataRelBase in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetGR
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetGR in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetGR in section (__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetIP
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetIP in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetIP in section (__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetLanguageSpecificData
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetLanguageSpecificData in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetLanguageSpecificData in
section (__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetRegionStart
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetRegionStart in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetRegionStart in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_GetTextRelBase
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_GetTextRelBase in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_GetTextRelBase in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_RaiseException
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_RaiseException in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_RaiseException in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_Resume
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_Resume in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_Resume in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_SetGR
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_SetGR in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_SetGR in section (__TEXT,__text)
ld: multiple definitions of symbol __Unwind_SetIP
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
__Unwind_SetIP in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of __Unwind_SetIP in section (__TEXT,__text)
ld: multiple definitions of symbol ___frame_state_for
/usr/lib/libgcc.a(unwind-dw2.o) private external definition of
___frame_state_for in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2.o)
private external definition of ___frame_state_for in section
(__TEXT,__text)
ld: multiple definitions of symbol __Unwind_Find_FDE
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of __Unwind_Find_FDE in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of __Unwind_Find_FDE in section
(__TEXT,__text)
ld: multiple definitions of symbol ___deregister_frame
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___deregister_frame in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___deregister_frame in
section (__TEXT,__text)
ld: multiple definitions of symbol ___deregister_frame_info
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___deregister_frame_info in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___deregister_frame_info in
section (__TEXT,__text)
ld: multiple definitions of symbol ___deregister_frame_info_bases
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___deregister_frame_info_bases in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of
___deregister_frame_info_bases in section (__TEXT,__text)
ld: multiple definitions of symbol ___register_frame
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___register_frame in section
(__TEXT,__text)
ld: multiple definitions of symbol ___register_frame_info
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame_info in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___register_frame_info in
section (__TEXT,__text)
ld: multiple definitions of symbol ___register_frame_info_bases
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame_info_bases in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___register_frame_info_bases
in section (__TEXT,__text)
ld: multiple definitions of symbol ___register_frame_info_table
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame_info_table in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___register_frame_info_table
in section (__TEXT,__text)
ld: multiple definitions of symbol ___register_frame_info_table_bases
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame_info_table_bases in section
(__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of
___register_frame_info_table_bases in section (__TEXT,__text)
ld: multiple definitions of symbol ___register_frame_table
/usr/lib/libgcc.a(unwind-dw2-fde-darwin.o) private external
definition of ___register_frame_table in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc_eh.a(unwind-dw2-fde-
darwin.o) private external definition of ___register_frame_table in
section (__TEXT,__text)
/usr/bin/libtool: internal link edit command failed
make: *** [subversion/libsvn_ra_dav/libsvn_ra_dav-1.la] Error 1

[now I'm concerned]

So "out of the box" on OS X 10.4 - it's hosed.

Now I'm trying:

$ CC=gcc-3.3 GXX=yes ./configure
...
==================================================================
WARNING: skipping the build of mod_dav_svn
--with-apxs or --with-apache must be used
==================================================================
...
configure: WARNING: we have configured without BDB filesystem support


You don't seem to have Berkeley DB version 4.1.25 or newer
installed and linked to APR-UTIL. We have created Makefiles which
will build without the Berkeley DB back-end; your repositories will
use FSFS as the default back-end. You can find the latest version of
Berkeley DB here:
http://www.sleepycat.com/download/index.shtml

$ make clean

$ make

[worked - not sure why it didn't for Rich.]

$ make check
...
Running all tests in cat_tests.py...success
Running all tests in import_tests.py...success
At least one test was SKIPPED, checking /Users/scottpalmer/dev/
svn_test/subversion/tests.log
SKIP: revert_tests.py 2: reverting to corrupt text base should fail
SKIP: utf8_tests.py 1: conversion of paths and logs to/from utf8


Seems to have worked. So I guess it is just an incompatibility with
GCC 4.0?


Scott

[Scott Palmer]

Post by Ben Collins-Sussman
So, let's work to figure out what's so special about your & Scott's
systems, and fix the problem.

I was a competent software engineer earlier today.. but it seems that
Subversion 1.2.x fails to build "out of the box" on my SuSE 9.1 Linux
installation as well.

I checked out a fresh copy of the 1.2.x branch...

Post by Ben Collins-Sussman
./autogen.sh
./configure

[claims it won't build with BDB support - that's fine.]

Post by Ben Collins-Sussman
make

...
cd subversion/libsvn_subr && /bin/sh /home/scottpalmer/dev/
subversion1.2/libtool --tag=CC --silent --mode=link gcc -g -O2 -g -
Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -
pthread -DNEON_ZLIB -rpath /usr/local/lib -o libsvn_subr-1.la
auth.lo cmdline.lo config.lo config_auth.lo config_file.lo
config_win.lo ctype.lo date.lo error.lo hash.lo io.lo lock.lo md5.lo
opt.lo path.lo pool.lo quoprint.lo sorts.lo stream.lo subst.lo
svn_base64.lo svn_string.lo target.lo time.lo utf.lo utf_validate.lo
validate.lo version.lo xml.lo /usr/lib/libaprutil-0.la -lgdbm -
ldb-4.2 -lexpat /usr/lib/libapr-0.la -lrt -lm -lcrypt -lnsl -
lpthread -ldl
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/
bin/ld: cannot find -lgdbm
collect2: ld returned 1 exit status
make: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1

So I have to wonder how things were "worse" before this autoconf
thing. :-)

The procedure appears to be quite unreliable. I've had it "just
work" when compiling 1.1.x, but the fact that it goes through all
that hoopla only to fail is a tad depressing.

Scott

[Kyle Kline]

SuSE Linux 9.1 -- I just built SVN from trunk a few days ago for the
first time and got this error as well. I had to go to YaST and
download the gdbm & gdbm-devel rpms to fix it. I also had to download
and build a few GNU utils (apr, automake, libtool) and download a copy
of neon & unzip srcs to my subversion dir and rename to /neon. :(

Hope that helps. gdbm is here: http://www.gnu.org/software/gdbm/gdbm.html

-Kyle

Post by Scott Palmer

Post by Ben Collins-Sussman
So, let's work to figure out what's so special about your & Scott's
systems, and fix the problem.

I was a competent software engineer earlier today.. but it seems that
Subversion 1.2.x fails to build "out of the box" on my SuSE 9.1 Linux
installation as well.
I checked out a fresh copy of the 1.2.x branch...

Post by Ben Collins-Sussman
./autogen.sh
./configure

[claims it won't build with BDB support - that's fine.]

Post by Ben Collins-Sussman
make

...
cd subversion/libsvn_subr && /bin/sh /home/scottpalmer/dev/
subversion1.2/libtool --tag=CC --silent --mode=link gcc -g -O2 -g -
Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -
pthread -DNEON_ZLIB -rpath /usr/local/lib -o libsvn_subr-1.la
auth.lo cmdline.lo config.lo config_auth.lo config_file.lo
config_win.lo ctype.lo date.lo error.lo hash.lo io.lo lock.lo md5.lo
opt.lo path.lo pool.lo quoprint.lo sorts.lo stream.lo subst.lo
svn_base64.lo svn_string.lo target.lo time.lo utf.lo utf_validate.lo
validate.lo version.lo xml.lo /usr/lib/libaprutil-0.la -lgdbm -
ldb-4.2 -lexpat /usr/lib/libapr-0.la -lrt -lm -lcrypt -lnsl -
lpthread -ldl
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/
bin/ld: cannot find -lgdbm
collect2: ld returned 1 exit status
make: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1
So I have to wonder how things were "worse" before this autoconf
thing. :-)
The procedure appears to be quite unreliable. I've had it "just
work" when compiling 1.1.x, but the fact that it goes through all
that hoopla only to fail is a tad depressing.
Scott
---------------------------------------------------------------------

[Scott Palmer]

Post by Kyle Kline
SuSE Linux 9.1 -- I just built SVN from trunk a few days ago for the
first time and got this error as well. I had to go to YaST and
download the gdbm & gdbm-devel rpms to fix it. I also had to download
and build a few GNU utils (apr, automake, libtool) and download a copy
of neon & unzip srcs to my subversion dir and rename to /neon. :(
Hope that helps. gdbm is here: http://www.gnu.org/software/gdbm/
gdbm.html
-Kyle

So autoconf fails again. I can't say that I'm surprised.

Thanks for the fix.

Scott

[Ben Collins-Sussman]

Post by Scott Palmer

Post by Kyle Kline
SuSE Linux 9.1 -- I just built SVN from trunk a few days ago for the
first time and got this error as well. I had to go to YaST and
download the gdbm & gdbm-devel rpms to fix it. I also had to
download
and build a few GNU utils (apr, automake, libtool) and download a copy
of neon & unzip srcs to my subversion dir and rename to /neon. :(
Hope that helps. gdbm is here: http://www.gnu.org/software/gdbm/
gdbm.html
-Kyle

So autoconf fails again. I can't say that I'm surprised.

What does this have to do with autoconf?

As far as I can tell, it's a weirdness with library dependencies.

The apr-util library links to many other sub-libraries; it has a
generic DBM interface, so it usually links to dbm, gdbm, or whatever
dbm library it can find. It also as an XML interface, so it links to
expat, libxml, or whatever it can find.

It looks like whatever apr-util subversion was linking to, expected
to be already linked to gdbm, and your system didn't have gdbm. This
indicates to be something bogus with your pre-installed apr-util...
in other words, something wrong with the package dependencies on your
system, not with subversion's ./configure. Subversion picked up an
installed apr-util, but the apr-util itself was already broken.

[Kyle Kline]

Post by Ben Collins-Sussman
in other words, something wrong with the package dependencies on your
system, not with subversion's ./configure

Very true - SuSE 9.1 out of the box does NOT include many of the
common GNU developer tools, and some of the ones it does include (or
you can download using YaST) are outdated. More the fault of the
distro not being geared toward developers.

-Kyle

Post by Ben Collins-Sussman

Post by Scott Palmer

Post by Kyle Kline
SuSE Linux 9.1 -- I just built SVN from trunk a few days ago for the
first time and got this error as well. I had to go to YaST and
download the gdbm & gdbm-devel rpms to fix it. I also had to download
and build a few GNU utils (apr, automake, libtool) and download a copy
of neon & unzip srcs to my subversion dir and rename to /neon. :(
Hope that helps. gdbm is here: http://www.gnu.org/software/gdbm/
gdbm.html
-Kyle

So autoconf fails again. I can't say that I'm surprised.

What does this have to do with autoconf?
As far as I can tell, it's a weirdness with library dependencies.
The apr-util library links to many other sub-libraries; it has a
generic DBM interface, so it usually links to dbm, gdbm, or whatever
dbm library it can find. It also as an XML interface, so it links to
expat, libxml, or whatever it can find.
It looks like whatever apr-util subversion was linking to, expected
to be already linked to gdbm, and your system didn't have gdbm. This
indicates to be something bogus with your pre-installed apr-util...
in other words, something wrong with the package dependencies on your
system, not with subversion's ./configure. Subversion picked up an
installed apr-util, but the apr-util itself was already broken.

[Scott Palmer]

Post by Kyle Kline

Post by Ben Collins-Sussman
in other words, something wrong with the package dependencies on your
system, not with subversion's ./configure

Very true - SuSE 9.1 out of the box does NOT include many of the
common GNU developer tools, and some of the ones it does include (or
you can download using YaST) are outdated. More the fault of the
distro not being geared toward developers.

Post by Ben Collins-Sussman
So autoconf fails again. I can't say that I'm surprised.

What does this have to do with autoconf?
As far as I can tell, it's a weirdness with library dependencies.

Isn't that one of the things that autoconf is supposed to figure
out? Shouldn't it tell me that I don't have some needed module?
Isn't that one of it's main reasons for being? If SuSE 9.1 was
suitable for compiling subversion isn't that exactly what autoconf
was going to detect with the zillions of queries of every
developement related property of my system that there could possibly be?

I guess the issue is that it doesn't realize in this case that there
are additional dependancies that apr-utils had? And apparently those
dependencies should have been resolved by the SuSE installation? I
just figured that if it was going to scan my system so completely
that it should have known that the build was going to fail.

Post by Kyle Kline
The apr-util library links to many other sub-libraries; it has a
generic DBM interface, so it usually links to dbm, gdbm, or
whatever dbm library it can find. It also as an XML interface, so
it links to expat, libxml, or whatever it can find.
It looks like whatever apr-util subversion was linking to, expected
to be already linked to gdbm, and your system didn't have gdbm.
This indicates to be something bogus with your pre-installed apr-
util... in other words, something wrong with the package
dependencies on your system, not with subversion's ./configure.
Subversion picked up an installed apr-util, but the apr-util itself
was already broken.

So apr-util is sitting on my system in a useless state? This is a
problem with SuSE 9.1 pretending to have apr-util installed but
actually it is missing big chunks that are required for apr-util to
actually be usable?
I could go into another rant about why Linux will probably still take
another 20 years to become usable for the mainstream.. but I'll
resist the urge this time... ;-)

All I can say is that building stuff shouldn't be this difficult, not
that it is a fault with subversion code in this case. It appears that
building anything on Linux is a roll of the dice. It's unfortunate
to say the least.

Scott

[Blair Zajac]

Post by Scott Palmer
So apr-util is sitting on my system in a useless state? This is a
problem with SuSE 9.1 pretending to have apr-util installed but
actually it is missing big chunks that are required for apr-util to
actually be usable?
I could go into another rant about why Linux will probably still take
another 20 years to become usable for the mainstream.. but I'll resist
the urge this time... ;-)

I wouldn't say useless, because it probably runs existing packages just
fine.

I don't have a SuSE system around, but I'm guessing they split up
apr-util into a run-time and a build-time component. Most of the time,
you don't have the development packages installed.

On my Debian box, I have can have libapr0 and libapr0-dev on my system,
but I never install libapr0-dev until I need to compile something
against it.

I don't count on configure testing every dependency it needs.

Most of the time, the best way to build a newer version of a package on
a system is to get the source package for that distribution (which I'm
guessing will be for an older version of Subversion that you want) and
use that as a basis to build the newer version. It already contains all
the dependencies on other packages that you will need to build
Subversion sucessfully. I'll install the dependencies by hand or hack
the older package to build the newer one for me. This works around the
problems of trying to figure out what packages need to be installed.

Regards,
Blair

[John Szakmeister]

Post by Scott Palmer

Post by Kyle Kline

Post by Ben Collins-Sussman
in other words, something wrong with the package dependencies on
your system, not with subversion's ./configure

Very true - SuSE 9.1 out of the box does NOT include many of the
common GNU developer tools, and some of the ones it does include (or
you can download using YaST) are outdated. More the fault of the
distro not being geared toward developers.

I've never found this to be the case... I've been using SuSE's
distributions for years now, and find them to not only be pretty
reliable, but easy to install, and up-to-date (at least if you buy when
it first comes out). I think the biggest problem (and most distributions
suffer from this), is having to know to install the '-dev' packages so
that you can correctly compile programs.

Post by Scott Palmer

Post by Kyle Kline

Post by Ben Collins-Sussman
So autoconf fails again. I can't say that I'm surprised.

What does this have to do with autoconf?
As far as I can tell, it's a weirdness with library dependencies.

Isn't that one of the things that autoconf is supposed to figure
out? Shouldn't it tell me that I don't have some needed module?
Isn't that one of it's main reasons for being? If SuSE 9.1 was
suitable for compiling subversion isn't that exactly what autoconf
was going to detect with the zillions of queries of every
developement related property of my system that there could possibly be?
I guess the issue is that it doesn't realize in this case that there
are additional dependancies that apr-utils had? And apparently those
dependencies should have been resolved by the SuSE installation? I
just figured that if it was going to scan my system so completely
that it should have known that the build was going to fail.

If you look, I'll bet that you find that the gdbm share library is on your
system. For apr-utils to run with an application, everything necessary
is there. However, if you want to *link* to apr-utils, you need the
gdbm-devel package (which brings in the extra information so that you can
link to the shared library).

Post by Scott Palmer

Post by Kyle Kline
The apr-util library links to many other sub-libraries; it has a
generic DBM interface, so it usually links to dbm, gdbm, or
whatever dbm library it can find. It also as an XML interface, so
it links to expat, libxml, or whatever it can find.
It looks like whatever apr-util subversion was linking to, expected
to be already linked to gdbm, and your system didn't have gdbm.
This indicates to be something bogus with your pre-installed apr-
util... in other words, something wrong with the package
dependencies on your system, not with subversion's ./configure.
Subversion picked up an installed apr-util, but the apr-util itself
was already broken.

So apr-util is sitting on my system in a useless state? This is a
problem with SuSE 9.1 pretending to have apr-util installed but
actually it is missing big chunks that are required for apr-util to
actually be usable?

It's useable... just not able to be linked to. Fire up Apache, and you'll
see that it can run just fine.

Post by Scott Palmer
I could go into another rant about why Linux will probably still take
another 20 years to become usable for the mainstream.. but I'll
resist the urge this time... ;-)
All I can say is that building stuff shouldn't be this difficult, not
that it is a fault with subversion code in this case. It appears that
building anything on Linux is a roll of the dice. It's unfortunate
to say the least.

I can definitely sympathize. I'm by no means a Linux guru, and it took me
a while to get spun up and figure out the distributions break up their
packages. The good news is that everything you need is there in SuSE
9.1. If you still have trouble building, I can probably give you some
more insight into that (I was using 9.1 for quite a while and more
recently upgraded to 9.2... compiling is the same for both of them).

-John

[Ben Collins-Sussman]

Keep in mind, Scott, that there are two different 'modes' of building
Subversion:


1. as a developer

2. as a user


To build as a developer, you must run ./autogen.sh, which means you
need python, as well as the correct versions of autoconf and
libtool. And you must also have correct, functional versions of apr,
apr-util, and neon all pre-installed on your system. The list of
requirements is quite complex.

When we package tarballs for users, we make them self-contained. The
*maintainers* run ./autogen.sh ahead of time, so that the tarball has
a ./configure script and libtool utilities ready to go. So users
building the tarball don't need autoconf, or libtool. Nor do they
need apr, apr-util, or neon preinstalled; those sub-packages are
already bundled into the tarball.

So the maxim of "just ./configure && make" only applies to the
*tarball*, not to somebody trying to checkout /trunk. As a
developer, there's a lot more stuff you need to worry about. In this
case, it's the fact that your pre-installed apr-util wasn't set up
for development, which is a linux distribution issue.

[Scott Palmer]

Post by Ben Collins-Sussman
Keep in mind, Scott, that there are two different 'modes' of
1. as a developer
2. as a user

Really what you describe above are two types of developers. "Users"
by my definition never need to compile code. #2 is just a developer
of more limited knowledge and often end users are forced to cross
their fingers and play that role. (That could be a whole other unix
rant.. but I will resist the urge.)

Post by Ben Collins-Sussman
In this case, it's the fact that your pre-installed apr-util wasn't
set up for development, which is a linux distribution issue.

I generally install developer packages, I must have missed something
when installing SuSE. I know I do intentionally skip some dev
packages that I think I won't need, since I don't do any X Windows
development for example. I'll use not being familiar with the
multitude of packages as my excuse. I haven't had the energy to boot
back into Linux and investigate further. I will try to do that to
see if there is apr-dev package that I don't have installed.

Thanks,

Scott

[Ben Collins-Sussman]

Post by Scott Palmer

Post by Ben Collins-Sussman
Keep in mind, Scott, that there are two different 'modes' of
1. as a developer
2. as a user

Really what you describe above are two types of developers. "Users"
by my definition never need to compile code.

Yeah, really, the categories are better named "subversion maintainer"
and "developer".

The tarball is meant for general consumption by anyone who just wants
to build and install ("developers"). Meanwhile, people who actually
work on subversion itself must build from project working copies
("maintainers"), and have a much larger set of build requirements.

[K. Richard Pixley]

Post by Helge Jensen

Post by Scott Palmer
What is fundamentally wrong is that autoconf is needed at all.

While that may be true, so is the state of the world. Refusing to
accept that will not improve things.

Untrue. There are superior alternatives.

Post by Helge Jensen
Autoconf is the current defacto solution, not because it's "stadard"
or endorsed by a huge company, but because it competed with other
solutions (the horrible "imake" for one) and won (for the time being).

Not true. It won because it was written by FSF folks. It's biggest
competitor in the gnu world is mine and it's still in use.

The user interface to configure was a fine idea. But the idea that any
tool can infer the set of configuration parameters you might like is
awkward. I can't provide conclusive regression testing when I can't
even guarantee that two different builds will even build the same code.

A superior approach involves listing those configuration parameters in a
sort of database, with standard system configurations named in a
predictable fashion. This allows for particular combinations to work
transparently and allows configurations with-just-one-difference to be
easily inferred. It also allows for simple extention by any developer
with half a brain rather than requiring the steep learning curve of
autoconf.

Post by Helge Jensen
Autoconf is not perfect, but perfect isn't really always needed and
autoconf seems to be doing quite ok.

Of the last 100 packages I've attempted to compile out of the box,
roughly 86% of them failed, due to configuration problems. Autoconf
works great for fire&forget packages like fileutils which already come
bundled with my operating system. Autoconf really sucks for new
packages like bind9 or subversion or apache or python or...

Post by Helge Jensen
autoconf and automake is actually what allows you to remain ignorant
yet still compile vast amounts of software ;)

No. Ports are what make this possible. Autotools make some ports
trivial while making other ports extremely difficult.

--rich

[K. Richard Pixley]

Post by Ben Collins-Sussman

Post by Scott Palmer
To be honest I find the entire process of "./configure" utterly
ridiculous.

Perhaps you don't remember what the world was like before autoconf
existed? Eek.

I do. It was a lot simpler. Things tended to fail in minor ways out of
the box that were trivial to fix and forward the fix on to the maintainers.

Now some things build easily, but generally only the mature ones.
Configuration takes longer than compilation. And errors mean most
developers are stuck against a huge learning curve that very few ever
surmount.

Post by Ben Collins-Sussman

Post by Scott Palmer
For example: It checks for things like stdlib.h - if you have a C
compiler that doesn't have this file you have much bigger problems
than compiling subversion. It checks for fortran compilers - why?
subversion is written in C. I could go on, but the point is that
the massive amount of "checking" just goes to show that there is
something so fundamentally wrong with the entire process that it
just makes me sad.

Fundamentally wrong? autoconf solves the problem of portability
better than anyone could have possibly dreamed of 20 years ago.

No, it doesn't. I dreamed of and built a superior system. So did a
number of other people.

Post by Ben Collins-Sussman
There's a reason it's the "standard'.

Oh? And what reason is that? The popularity of the GNU suite which
usually carries the load of autoconf as a necessary evil?

Post by Ben Collins-Sussman
Is it pleasant? No. Does it greet you in the morning with french
toast, the daily paper, and a smile? No. Does it alleviate
tremendous portability pain? Absolutely.

No, it doesn't. It alleviates some minor portability nuisances at a
huge cost in complexity. Moderate portability issues become major
portability issues. And major portability issues become insurmountable.

There are also an entire category of easy portability issues that
autoconf doesn't address at all, choosing instead to throw up it's hands
and demand that the user state something, in spite of the fact that easy
and obvious defaults exist.

Autoconf was never a good solution. It was a so-so solution whose
shortcomings were covered by enthusiastic maintainers. It is grossly
showing it's cracks now, even for simple and mature things like the
older gnu packages. The GNU standard "configure" interface was
basically a fine idea, (skipping the --host --target problems rms never
seemed to understand), but autoconf always has been and continues to be
a huge overhead by comparison to the alternatives. For tested software,
it's just flat out wrong.

--rich
ps, 1.2 fails for me on mac also.

[Stephen Davis]

Post by Stephen Davis

Post by Scott Palmer
Any ideas why renaming glibtool so that it is used isn't enough?

I'm sure that works too but I'd rather not rename my system-supplied
binaries if I don't have to.

You misunderstood. I DID rename that as an experiment and it was NOT
enough. It did fix some libtool related issues, but the build still
failed.

Indeed I did.

Post by Stephen Davis
As you can see, there are many ways to skin the cat. If something
doesn't build straight out of the box (e.g. ./configure), then lots
of people just whack on stuff until it works. I know I do.

I haven't got THAT much free time. Quite frankly, if it doesn't work
"straight out of the box" it's broken, and just because it's open
source doesn't mean it's MY job to fix it.

Yes and no. OSes change too and a configure setup that works on one
version of the OS might break on another (see previous email about neon
on panther vs. tiger). It takes time for the developers to track these
changes and often it is up to the interested users of a given platform
to take the time to figure this stuff out and feed it back to the
project.

For example, the fine folks at Metissian have taken the time to build
what I think you might be looking for (an OS X install package w/
javahl bindings):

http://metissian.com/projects/macosx/subversion/

Post by Stephen Davis
Cem and I obviously used different approaches to solve the problem
and both are valid depending on what you need. If you don't need
shared libaries, then turn 'em off. If you want SSL, add
"--with-ssl". It's just the magic and pain that is autoconf. :-)

I agree with the part about "pain" :)
To be honest I find the entire process of "./configure" utterly
ridiculous. For example: It checks for things like stdlib.h - if you
have a C compiler that doesn't have this file you have much bigger
problems than compiling subversion. It checks for fortran compilers -
why? subversion is written in C. I could go on, but the point is that
the massive amount of "checking" just goes to show that there is
something so fundamentally wrong with the entire process that it just
makes me sad.

As grotesque and incomprehensible as I find autoconf, it is a marvelous
tool for developers to port to platforms they would have no other
chance of supporting.

stephen

[K. Richard Pixley]

FTR, I'm one of the original developers of the gnu configure system. I
wrote the one that was being distributed with binutils & gdb, last I
checked. I, too, am having trouble building subversion on a mac.

Post by Scott Palmer

Post by Stephen Davis
As you can see, there are many ways to skin the cat. If something
doesn't build straight out of the box (e.g. ./configure), then lots
of people just whack on stuff until it works. I know I do.

I haven't got THAT much free time. Quite frankly, if it doesn't work
"straight out of the box" it's broken, and just because it's open
source doesn't mean it's MY job to fix it.

I completely agree. It should be trivial to build this thing using
standard defaults right out of the box. I don't mind mucking about to
get non-default behavior, but standard default behavior should Just
Work(tm).

It's MUCH easier to muck with something that works than it is to muck
around trying to get it to work the first time.

Post by Scott Palmer
To be honest I find the entire process of "./configure" utterly
ridiculous. For example: It checks for things like stdlib.h - if you
have a C compiler that doesn't have this file you have much bigger
problems than compiling subversion. It checks for fortran compilers
- why? subversion is written in C. I could go on, but the point is
that the massive amount of "checking" just goes to show that there is
something so fundamentally wrong with the entire process that it just
makes me sad.

It is ridiculous.

The original idea was that if you actively tested for the bits you
needed, then the configuration system should be capable of inferring
itself into new systems with minor variations. In practice, those
variations need to be tested. And the activity of writing tests is so
onerous that people who would be happy writing down and sharing that
macosx10.4 requires such-and-such a library will instead just hack their
own configuration, never share that data, and now everyone has the same
problem.

More, you can't use cross compilation if the configuration checking
requires any run time checks.

FTR, one available binary package doesn't work. A second requires a
distribution system (fink) which doesn't work, so I can't even try it.

I can't build 1.1.4 from source on tiger out of the box, default configs.

I'm waiting for 1.2 to configure now.

--rich

[Stephen Davis]

Post by K. Richard Pixley
FTR, one available binary package doesn't work. A second requires
a distribution system (fink) which doesn't work, so I can't even
try it.

The crux of the problem is neon 0.24.7 which is bundled with
subversion <= 1.2. Out of the box, neon is broken on OS X b/c it
does not build the shared library and the rest of the subversion
build process expects to find it (on 10.3, this somehow gets
overlooked but on 10.4 it is not). The next version of neon does not
have this problem (and it is my understanding that kfogel has began
the update to the latest version on trunk but I could be wrong).

The configure script for neon 0.24.7 does not build shared but
something gets broken such that subversion tries to find the shared
library that didn't get built. That is the failure.

Since this was already fixed in a later version of neon, it is not
clear to me who to report this to.

Post by K. Richard Pixley
I can't build 1.1.4 from source on tiger out of the box, default configs.
I'm waiting for 1.2 to configure now.

CC=gcc-3.3 GXX=yes ./configure

should work for 1.2-rc4 on 10.4 (I'm building now but my machine is
slow). Note that Tiger ships with gcc 4.0 as the default compiler
and this version appears to be, shall we say, less than perfect.
Having said that, only one of the subversion self-tests fails (I
forget which one) so it may not be that bad but it is a question
mark, to be sure.

Post by K. Richard Pixley
Autoconf was never a good solution. It was a so-so solution whose
shortcomings were covered by enthusiastic maintainers. It is
grossly showing it's cracks now, even for simple and mature things
like the older gnu packages. The GNU standard "configure"
interface was basically a fine idea, (skipping the --host --target
problems rms never seemed to understand), but autoconf always has
been and continues to be a huge overhead by comparison to the
alternatives. For tested software, it's just flat out wrong.

Out of curiousity, what better alternatives exist? I've seen
makefiles that "just work" (which is impressive) but I'm not familiar
with any other autoconf-esque mechanisms.

BTW, subversion maintainers, why is there no "make uninstall"
option? Cleaning out my /usr/local heirarchy of all things
subversion to test fresh builds of new releases or different
configure options is irritating.

stephen

[K. Richard Pixley]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Stephen Davis wrote:
<blockquote cite="midA9059D5A-351A-4EF7-87AF-***@soundgeek.org"
type="cite">
<div>CC=gcc-3.3 GXX=yes ./configure</div>
</blockquote>
Still fails for me.&nbsp; "-lpthread is not an object file" error from
libtool.<br>
<blockquote cite="midA9059D5A-351A-4EF7-87AF-***@soundgeek.org"
type="cite">
<div>Out of curiousity, what better alternatives exist?&nbsp; I've seen
makefiles that "just work" (which is impressive) but I'm not familiar
with any other autoconf-esque mechanisms.</div>
</blockquote>
Configuration systems can be broken down into two basic categories.&nbsp; In
one category, a set of configuration parameters is manually crafted,
stored, distributed with the package, and then recalled prior to
compilation.&nbsp; If there is any testing done at all, it's done on a very
macro level in order to guess which parameter set will be selected.<br>
<br>
In the other category, a set of configuration parameters are generated
on the fly prior to each compile using a set of rules which have been
shipped with the package.&nbsp; Each parameter may require multiple tests in
order to determine a suitable value and each nested package will
generally retest in order to generate parameter values in terms it
understands.<br>
<br>
Autoconf generates.&nbsp; Larry Wall's Configure also generated.&nbsp; And I
think setup.py also generates, although most of the heavy lifting has
already been done for setup.py by whoever ported python.<br>
<br>
Autoconf further suffers from the problem that autoconf scripts are
generated using a tool whose version isn't kept in sync with your
product.&nbsp; So trying to port an old package can be nightmarish when new
versions of autoconf don't regenerate your scripts and old versions of
autoconf aren't available or can't manage the newer tests.<br>
<br>
The database approach, has advantages:<br>
<ul>
<li>way, way, way faster being basically a fixed time operation to
set a series of predetermined constants<br>
</li>
<li>can exactly reproduce a particular configuration numerous times</li>
<li>fails in clear and obvious ways for unsupported configurations<br>
</li>
<li>can be configured by hand if necessary</li>
<li>can be configured on a machine other than the one used for
building, (ie, cross or third party compilations)</li>
<li>simpler</li>
<li>avoids unnecessary and redundant testing for nested instantiations<br>
</li>
</ul>
While it's true that a database system will fail on many minor issues,
those issues are minor to fix.&nbsp; Add a new row to the database and
change the parameter you need.&nbsp; Even moderate issues requiring new
parameters are minor to fix since you know that all previous systems
worked without it.&nbsp; The learning curve here is minor or trivial for
anyone who understands basic software building concepts like gcc &amp;
make.<br>
<br>
Cygnus configure, (which I originally wrote and is still in use for gdb
and binutils, I think), implements the GNU "configure" interface using
a database approach.&nbsp; Cygnus configure predates autoconf by a year or
so.&nbsp; Cygnus configure can support cross configuration, third party
configuration, nesting, and it does it quickly and completely using a
single /bin/sh script with table data stored in simple makefile
fragments and/or symlinked source alternatives, (ie, t-macox.h vs
t-solaris.h).<br>
<br>
This means that Cygnus configure essentially forks every time a package
that uses it ships, but that's ok because Cygnus configure is v7
compatible /bin/sh - it runs anywhere, or at least on a much wider
variety of platforms than can possibly be supported by
autoconf+m4+autotools+etc.&nbsp; It's both source and executable and doesn't
need to be rebuilt.&nbsp; When necessary, you can simply edit an old copy to
add a feature to an old distribution.&nbsp; Of course, changes to Cygnus
configure are rare, since it doesn't really know anything about your
package's features anyway - those are kept in your source fragments.<br>
<br>
Autoconf works well if you believe that a very small number of packages
will ever be compiled on a very large number of different types of
systems, particularly so if the types of systems are so dynamic that
they can't be defined.&nbsp; But in fact, what we've seen over the years is
a drastic curtailment in the number of types of systems and a literal
explosion in the number of packages.&nbsp; Basically we're down to windows,
macosx, and linux, with occasional allowances for bsd systems or
solaris.&nbsp; In past years I could literally list over 50 operating system
distributions each with multiple versions.&nbsp; And the number of available
packages is just simply so large as to be uncountable.<br>
<br>
--rich<br>
</body>
</html>

[Stephen Davis]

Post by Stephen Davis
CC=gcc-3.3 GXX=yes ./configure

Still fails for me. "-lpthread is not an object file" error from
libtool.

Hmm, worked fine for me and all tests passed. Did you perhaps do an
upgrade install of the OS but didn't install the newer developer
tools? Are there any other copies of APR on the system?

Thanks for the explanation about db-driven configure systems. Pretty
cool.

stephen

[Karan, Cem (Civ, ARL/CISD)]

Post by Scott Palmer

Post by Scott Palmer
./autogen.sh
./configure --enable-maintainer-mode --disable-shared GXX=yes
make
make check
make install
In past incarnations, you had to have GXX=yes to make everything
work. In this current release (1.2 RC 3), it looks like all you
really need is to disable the shared library support. This is
because currently, the auto* tools call libtool to generate the
shared libraries; unfortunately, Apple decided to create their own
tool called libtool, and rename the GNU libtool to glibtool. This
breaks the various auto* tools, as you can see from the tail end of
your transcript.

Thank you!
Just for kicks I tried moving Apple's libtool out of the way and
renaming glibtool to libtool and continuing my build. It did go
libtool: unrecognized option `-dynamic'
Try `libtool --help' for more information.
make[2]: *** [libapr-1.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [external-all] Error 1
So then I stopped trying to be smart and did what you said (without
the maintainer mode) and it compiled fine. Btw, do I need shared
libs to use the Java HL bindings ?

Truthfully, I don't know. I'm not one of the developers, I'm just an
end user. If you figure it out, post it to the list so that it gets
into the archives.

Good luck,
Cem Karan

[Karan, Cem (Civ, ARL/CISD)]

...If something doesn't build straight out of the box (e.g. ./configure),
then lots of people just whack on stuff until it works...
stephen

Yup, thats pretty much what I do! ;-)

No, actually, what I've been trying to do is 'manual regression testing', which is basically trying out the various combinations to see what works and what breaks. I then try to tell someone about what broke, and why I think it broke. I know that I don't have time to write code for subversion (apologies to the developers, I know I should write patches!), so my plan is to contribute by testing instead.

Thanks,
Cem Karan

[Karan, Cem (Civ, ARL/CISD)]

Try the following:

./autogen.sh
./configure --disable-shared
make
make check (just to be sure!)
make install

I'm not sure WHY I have to always run autogen, but that is the only way I can get things to work. The --disable-shared is there (I think) because of the neon library problems.

Good luck,
Cem Karan

-----Original Message-----
From: K. Richard Pixley [mailto:***@noir.com]
Sent: Tue 17-May-05 07:11 PM
To: Stephen Davis
Cc: Subversion users group
Subject: Re: Building Subversion 1.[12] on OS X 10.4 fails

Stephen Davis wrote:

CC=gcc-3.3 GXX=yes ./configure

Still fails for me. "-lpthread is not an object file" error from libtool.


Out of curiousity, what better alternatives exist? I've seen makefiles that "just work" (which is impressive) but I'm not familiar with any other autoconf-esque mechanisms.

Configuration systems can be broken down into two basic categories. In one category, a set of configuration parameters is manually crafted, stored, distributed with the package, and then recalled prior to compilation. If there is any testing done at all, it's done on a very macro level in order to guess which parameter set will be selected.

In the other category, a set of configuration parameters are generated on the fly prior to each compile using a set of rules which have been shipped with the package. Each parameter may require multiple tests in order to determine a suitable value and each nested package will generally retest in order to generate parameter values in terms it understands.

Autoconf generates. Larry Wall's Configure also generated. And I think setup.py also generates, although most of the heavy lifting has already been done for setup.py by whoever ported python.

Autoconf further suffers from the problem that autoconf scripts are generated using a tool whose version isn't kept in sync with your product. So trying to port an old package can be nightmarish when new versions of autoconf don't regenerate your scripts and old versions of autoconf aren't available or can't manage the newer tests.

The database approach, has advantages:


* way, way, way faster being basically a fixed time operation to set a series of predetermined constants

* can exactly reproduce a particular configuration numerous times
* fails in clear and obvious ways for unsupported configurations

* can be configured by hand if necessary
* can be configured on a machine other than the one used for building, (ie, cross or third party compilations)
* simpler
* avoids unnecessary and redundant testing for nested instantiations


While it's true that a database system will fail on many minor issues, those issues are minor to fix. Add a new row to the database and change the parameter you need. Even moderate issues requiring new parameters are minor to fix since you know that all previous systems worked without it. The learning curve here is minor or trivial for anyone who understands basic software building concepts like gcc & make.

Cygnus configure, (which I originally wrote and is still in use for gdb and binutils, I think), implements the GNU "configure" interface using a database approach. Cygnus configure predates autoconf by a year or so. Cygnus configure can support cross configuration, third party configuration, nesting, and it does it quickly and completely using a single /bin/sh script with table data stored in simple makefile fragments and/or symlinked source alternatives, (ie, t-macox.h vs t-solaris.h).

This means that Cygnus configure essentially forks every time a package that uses it ships, but that's ok because Cygnus configure is v7 compatible /bin/sh - it runs anywhere, or at least on a much wider variety of platforms than can possibly be supported by autoconf+m4+autotools+etc. It's both source and executable and doesn't need to be rebuilt. When necessary, you can simply edit an old copy to add a feature to an old distribution. Of course, changes to Cygnus configure are rare, since it doesn't really know anything about your package's features anyway - those are kept in your source fragments.

Autoconf works well if you believe that a very small number of packages will ever be compiled on a very large number of different types of systems, particularly so if the types of systems are so dynamic that they can't be defined. But in fact, what we've seen over the years is a drastic curtailment in the number of types of systems and a literal explosion in the number of packages. Basically we're down to windows, macosx, and linux, with occasional allowances for bsd systems or solaris. In past years I could literally list over 50 operating system distributions each with multiple versions. And the number of available packages is just simply so large as to be uncountable.

--rich

[Holger Rauch]

Hi Scott!

Post by Scott Palmer
[...]
I could go into another rant about why Linux will probably still take
another 20 years to become usable for the mainstream.. but I'll
resist the urge this time... ;-)

As has already been pointed out, you've run into a Linux *distribution*
issue, not a general Linux issue. You're if this was an issue for *all*
Linux distributions, but that's not the case. It's the responsibility
of the distributor to keep its distribution in a sane state (which to
a great deal involves having correct dependencies on software packages).
In your case, the (g)dbm packages should have been added as a dependency by
SuSE so that they would have been installed automatically at the time the
apr-utils package has been installed. A user shouldn't normally have to mess
with this sort of problem. But some distributors don't do their homework in
the way they're supposed to. That's the reason why it helps to be a bit familiar
with the distribution's contents (packages) and why one should double check
that all required packages have actually been installed.

Post by Scott Palmer
All I can say is that building stuff shouldn't be this difficult,

I fully agree with you on this one.

Post by Scott Palmer
not
that it is a fault with subversion code in this case. It appears that
building anything on Linux is a roll of the dice. It's unfortunate
to say the least.

No, it's not a roll of the dice. It's just a matter of having the required
packages installed ;-) Though I admit that your case is unfortunate indeed.

Kind regards,

Holger