Thrift
  1. Thrift
  2. THRIFT-844

Build Requirements state autoconf 2.59+ is required, but 2.60+ is needed

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.4, 0.5
    • Fix Version/s: 0.5
    • Component/s: None
    • Labels:
      None
    • Environment:

      CentOS release 5.5 (Final)

      Description

      Though the Build Requirements state that autoconf 2.59+ is required (even though 2.60+ is listed as recommended), and the configure.ac has a AC_PREREQ of 2.59, macros which require 2.60+ are being used in the configure.ac. This makes building SVN Thrift impossible on autoconf 2.59, the latest stable in CentOS 5.5.

      AC_PREREQ and the wiki should be updated to reflect the actual build requirements, or the macros which require the later version should be removed.

      1. bootstrap.txt
        1.0 kB
        Harlan Lieberman-Berg

        Activity

        Hide
        David Reiss added a comment -

        This is going to be fixed one way or another by patches on THRIFT-858.

        Show
        David Reiss added a comment - This is going to be fixed one way or another by patches on THRIFT-858 .
        Hide
        Anthony Molinaro added a comment -

        Oh, well good to know, I'll try a release tarball out at some point then, thanks!

        Show
        Anthony Molinaro added a comment - Oh, well good to know, I'll try a release tarball out at some point then, thanks!
        Hide
        Bryan Duxbury added a comment -

        ... but until cassandra ups their version ...

        I don't think this is actually true. The things like the protocol and transports are very stable between Thrift versions, so unless there's something I'm missing, you are free to whatever version of the clientside you want.

        Show
        Bryan Duxbury added a comment - ... but until cassandra ups their version ... I don't think this is actually true. The things like the protocol and transports are very stable between Thrift versions, so unless there's something I'm missing, you are free to whatever version of the clientside you want.
        Hide
        Anthony Molinaro added a comment -

        Instant releases don't work for me because the version of thrift I need will not have the patches I need to have php, the php extension, and erlang installed. Several of those patches I've actually had commited, but until cassandra ups their version I'm stuck with what I have. When the cassandra version is updated I will try to use the instant release to see it it works for me.

        As for where erlang things end up on x86_64, I don't totally remember the issue. I seem to recall that something was causing the erlang libs to end up in the wrong place for one of my early erlang packages. It might have been that I tried to make an architecture non-specific package for some pure erlang, but that installed in /usr/lib so wouldn't be found by erlang when installed on x86_64 (this is probably more a fault of the packagers of erlang, there is probably some way to have it work so that libraries can be found in both /usr/lib64/erlang and /usr/lib/erlang). Yeah, that must have been it, since I know and have used the command line switch to change libdir.

        Show
        Anthony Molinaro added a comment - Instant releases don't work for me because the version of thrift I need will not have the patches I need to have php, the php extension, and erlang installed. Several of those patches I've actually had commited, but until cassandra ups their version I'm stuck with what I have. When the cassandra version is updated I will try to use the instant release to see it it works for me. As for where erlang things end up on x86_64, I don't totally remember the issue. I seem to recall that something was causing the erlang libs to end up in the wrong place for one of my early erlang packages. It might have been that I tried to make an architecture non-specific package for some pure erlang, but that installed in /usr/lib so wouldn't be found by erlang when installed on x86_64 (this is probably more a fault of the packagers of erlang, there is probably some way to have it work so that libraries can be found in both /usr/lib64/erlang and /usr/lib/erlang). Yeah, that must have been it, since I know and have used the command line switch to change libdir.
        Hide
        David Reiss added a comment -

        You should use instant releases. You can get them for any svn revision, but they look like release tarballs.

        Do you mean that they end up in the wrong place on x86_64? That's strange. I would have expected it to default libdir to /usr/lib64. You can always override it on the configure command line.

        Show
        David Reiss added a comment - You should use instant releases. You can get them for any svn revision, but they look like release tarballs. Do you mean that they end up in the wrong place on x86_64? That's strange. I would have expected it to default libdir to /usr/lib64. You can always override it on the configure command line.
        Hide
        Anthony Molinaro added a comment -

        Yeah, the problem has been that I use thrift primarily to talk to cassandra and the lack of thrift releases have meant I've had to grab exact revisions (specifically the revision corresponding to the jar in the cassandra downloads) and build packages around those. Hopefully now that releases are coming, cassandra will start to use those and I won't have to resort to building versions from svn. Until then I'm sort of stuck with what I have now which is a bunch of patches which get thrift to build from svn with autoconf 2.59. Anyway, hopefully by the time this patch effects me I should be using releases and not svn, and if not I'll patch my local copy.

        Also, as for the erlang directory being different, the exact issue I've seen is with RedHat/Centos and erlang. When on x86_64 it puts erlang in /usr/lib64/erlang, on i386 it puts it into /usr/lib/erlang. By default libdir is usually /usr/lib, so things end up in the wrong place on i386. There is supposed to be some voodoo to fix this, but it turned out to be easier to just have erlang projects see where they should install themselves via inspecting the erlang code path. So I think their macro will work in most cases, although I'm not certain if it will work for x86_64 RedHat/Centos.

        Show
        Anthony Molinaro added a comment - Yeah, the problem has been that I use thrift primarily to talk to cassandra and the lack of thrift releases have meant I've had to grab exact revisions (specifically the revision corresponding to the jar in the cassandra downloads) and build packages around those. Hopefully now that releases are coming, cassandra will start to use those and I won't have to resort to building versions from svn. Until then I'm sort of stuck with what I have now which is a bunch of patches which get thrift to build from svn with autoconf 2.59. Anyway, hopefully by the time this patch effects me I should be using releases and not svn, and if not I'll patch my local copy. Also, as for the erlang directory being different, the exact issue I've seen is with RedHat/Centos and erlang. When on x86_64 it puts erlang in /usr/lib64/erlang, on i386 it puts it into /usr/lib/erlang. By default libdir is usually /usr/lib, so things end up in the wrong place on i386. There is supposed to be some voodoo to fix this, but it turned out to be easier to just have erlang projects see where they should install themselves via inspecting the erlang code path. So I think their macro will work in most cases, although I'm not certain if it will work for x86_64 RedHat/Centos.
        Hide
        David Reiss added a comment -

        > Well, AC_ERLANG_PATH_ERL and AC_ERLANG_PATH_ERLC could be done with AC_PATH_PROG, right?
        Yes, but I think the wrappers add a few conveniences.

        > AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR seems to just trying to figure out the correct place to install, framewerk does this by calling out to erlang and asking it where it should install things.
        The autoconf docs used to (incorrectly) say that this macro did that too, but it doesn't. I guess the install location might be different from the location of the version you use to build.

        > Anyway, I'm sure these sort of tricks won't convince you to get things working with 2.59, but figured I'd put them out there as alternatives.
        Kind of. If you just want to build a release, this won't affect you. If you want to build trunk, you can just download an instant release. If you actually want to develop Thrift, it shouldn't be too hard to just install autoconf in your homedir.

        Show
        David Reiss added a comment - > Well, AC_ERLANG_PATH_ERL and AC_ERLANG_PATH_ERLC could be done with AC_PATH_PROG, right? Yes, but I think the wrappers add a few conveniences. > AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR seems to just trying to figure out the correct place to install, framewerk does this by calling out to erlang and asking it where it should install things. The autoconf docs used to (incorrectly) say that this macro did that too, but it doesn't. I guess the install location might be different from the location of the version you use to build. > Anyway, I'm sure these sort of tricks won't convince you to get things working with 2.59, but figured I'd put them out there as alternatives. Kind of. If you just want to build a release, this won't affect you. If you want to build trunk, you can just download an instant release. If you actually want to develop Thrift, it shouldn't be too hard to just install autoconf in your homedir.
        Hide
        Anthony Molinaro added a comment -

        Well, AC_ERLANG_PATH_ERL and AC_ERLANG_PATH_ERLC could be done with AC_PATH_PROG, right?

        AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR seems to just trying to figure out the correct place to install, framewerk does this by calling out to erlang and asking it where it should install things

        http://code.google.com/p/fwtemplates/source/browse/trunk/fw-template-erlang/fw.local/m4/template_erlang.m4#20

        It's sort of ugly, but works with autoconf 2.59 and greater. Anyway, I'm sure these sort of tricks won't convince you to get things working with 2.59, but figured I'd put them out there as alternatives.

        Show
        Anthony Molinaro added a comment - Well, AC_ERLANG_PATH_ERL and AC_ERLANG_PATH_ERLC could be done with AC_PATH_PROG, right? AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR seems to just trying to figure out the correct place to install, framewerk does this by calling out to erlang and asking it where it should install things http://code.google.com/p/fwtemplates/source/browse/trunk/fw-template-erlang/fw.local/m4/template_erlang.m4#20 It's sort of ugly, but works with autoconf 2.59 and greater. Anyway, I'm sure these sort of tricks won't convince you to get things working with 2.59, but figured I'd put them out there as alternatives.
        Hide
        David Reiss added a comment -

        AC_ERLANG_PATH_ERL, AC_ERLANG_PATH_ERLC, and AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR are not available in autoconf 2.59.

        Show
        David Reiss added a comment - AC_ERLANG_PATH_ERL, AC_ERLANG_PATH_ERLC, and AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR are not available in autoconf 2.59.
        Hide
        Anthony Molinaro added a comment -

        What erlang macros are causing problems? (I'm on Centos5 and would like erlang to continue to work there).

        Show
        Anthony Molinaro added a comment - What erlang macros are causing problems? (I'm on Centos5 and would like erlang to continue to work there).
        Hide
        David Reiss added a comment -

        I've found no obvious way of getting the Erlang macros to work with Autoconf 2.59. How do other committers feel about upping our prereq to 2.60? Another option would be to disable Erlang support if bootstrap.sh is run with an older autoconf.

        Show
        David Reiss added a comment - I've found no obvious way of getting the Erlang macros to work with Autoconf 2.59. How do other committers feel about upping our prereq to 2.60? Another option would be to disable Erlang support if bootstrap.sh is run with an older autoconf.
        Hide
        Harlan Lieberman-Berg added a comment -

        Appreciate it. I'll use that in crafting my RPM. If you need help testing or if there's any other way I can be of help, just let me know.

        Show
        Harlan Lieberman-Berg added a comment - Appreciate it. I'll use that in crafting my RPM. If you need help testing or if there's any other way I can be of help, just let me know.
        Hide
        David Reiss added a comment -

        Hrm. This is due to the recent change for finding erlang paths. I'll see what I can do about it.

        In the meantime, if you want to use the latest trunk, you can download an "instant release" from http://instant.thrift-rpc.org/ , which has configure pregenerated with a more recent version of autoconf.

        Show
        David Reiss added a comment - Hrm. This is due to the recent change for finding erlang paths. I'll see what I can do about it. In the meantime, if you want to use the latest trunk, you can download an "instant release" from http://instant.thrift-rpc.org/ , which has configure pregenerated with a more recent version of autoconf.
        Hide
        Harlan Lieberman-Berg added a comment -

        Actually, for me, build is failing because of the missing macros. It tries to interpret them as shell commands during the configure which, obviously, turns out quite badly. I don't get a Makefile out of it with 2.59.

        Show
        Harlan Lieberman-Berg added a comment - Actually, for me, build is failing because of the missing macros. It tries to interpret them as shell commands during the configure which, obviously, turns out quite badly. I don't get a Makefile out of it with 2.59.
        Hide
        David Reiss added a comment -

        I agree with this issue. We've been lax to up the ac_prereq because the build actually will succeed with autoconf 2.59.

        Show
        David Reiss added a comment - I agree with this issue. We've been lax to up the ac_prereq because the build actually will succeed with autoconf 2.59.
        Hide
        Harlan Lieberman-Berg added a comment -

        An excerpt of the errors from bootstrap.sh on autoconf 2.59.

        Show
        Harlan Lieberman-Berg added a comment - An excerpt of the errors from bootstrap.sh on autoconf 2.59.

          People

          • Assignee:
            Harlan Lieberman-Berg
            Reporter:
            Harlan Lieberman-Berg
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development