[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Neon build issue with deps tarball

From: Greg Hudson <ghudson_at_mit.edu>
Date: Sat, 24 Jan 2009 22:54:23 -0500 (EST)

The bug: if you don't pass an --enable-shared option to configure, and
build from the deps tarball, neon gets configured with
--disable-shared. On Linux, the build seems to succeed anyway (I
guess you can build shared libraries against static ones) but on
Solaris the build fails as a result.

The cause: If you look at the configure script, you'll see:

  [... gobs of stuff ...]
            # The arguments passed to this configure script are passed
            # down to neon's configure script, but, since neon
            # defaults to *not* building shared libs, and we default
            # to building shared libs, we have to explicitly pass down
            # an --{enable,disable}-shared argument, to make sure neon
            # does the same as we do.
            if test "$enable_shared" = "yes"; then
              args="--enable-shared"
            else
              args="--disable-shared"
            fi
  [... more gobs of stuff ...]
  if test "${enable_shared+set}" = set; then
    [... stuff ...]
  else
    enable_shared=yes
  fi
  [... and the rest of the script ...]

Obviously, there is an ordering problem here. enable_shared doesn't
receive its default value until well after the neon configure goop
checks it with the assumption that the default has been set.

The workaround: Pass --enable-shared when configuring with the deps
tarball.

The fix: build/ac-macros/neon.m4 could check if enable_shared is not
no, instead of checking if it's yes. Or the libtool goop could be
moved above the neon goop in configure.ac. I'm not prepared to test
either option at this time.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1048352
Received on 2009-01-25 05:00:52 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.