CouchDB
  1. CouchDB
  2. COUCHDB-1426

error while building with 2 spidermonkey installed

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.1.1, 1.2, 1.3
    • Fix Version/s: 1.2
    • Component/s: Build System
    • Labels:
      None

      Description

      Context:

      To bench the differences between different versions of couchdb I had to test against spidermonkey 1.7 and 1.8.5 . 1.8.5 is installed globally in /usr/local while the 1.7 version is installed on a temporary path.

      Problem:

      Using --witth-js-include & --with-js-lib configure options aren't enough to use the 1.7 version it still want to use spidermonkey 1.8.5 . Removing js-config from the path doesn't change anything. I had to uninstall spidermonkey 1.8.5 to have these setting working.

      Error result:

      $ ./configure --with-erlang=/Users/benoitc/local/otp-r14b04/lib/erlang/usr/include --with-js-include=/Users/benoitc/local/js-1.7.0/include --with-js-lib=/Users/benoitc/local/js-1.7.0/lib64
      checking for a BSD-compatible install... /usr/bin/install -c
      checking whether build environment is sane... yes
      checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
      checking for gawk... no
      checking for mawk... no
      checking for nawk... no
      checking for awk... awk
      checking whether make sets $(MAKE)... yes
      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 ISO C89... none needed
      checking for style of include used by make... GNU
      checking dependency style of gcc... gcc3
      checking build system type... i386-apple-darwin11.3.0
      checking host system type... i386-apple-darwin11.3.0
      checking for a sed that does not truncate output... /usr/bin/sed
      checking for grep that handles long lines and -e... /usr/bin/grep
      checking for egrep... /usr/bin/grep -E
      checking for fgrep... /usr/bin/grep -F
      checking for ld used by gcc... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
      checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
      checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
      checking the name lister (/usr/bin/nm) interface... BSD nm
      checking whether ln -s works... yes
      checking the maximum length of command line arguments... 196608
      checking whether the shell understands some XSI constructs... yes
      checking whether the shell understands "+="... yes
      checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld option to reload object files... -r
      checking how to recognize dependent libraries... pass_all
      checking for ar... ar
      checking for strip... strip
      checking for ranlib... ranlib
      checking command to parse /usr/bin/nm output from gcc object... ok
      checking for dsymutil... dsymutil
      checking for nmedit... nmedit
      checking for lipo... lipo
      checking for otool... otool
      checking for otool64... no
      checking for -single_module linker flag... yes
      checking for -exported_symbols_list linker flag... yes
      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 for dlfcn.h... yes
      checking for objdir... .libs
      checking if gcc supports -fno-rtti -fno-exceptions... no
      checking for gcc option to produce PIC... -fno-common -DPIC
      checking if gcc PIC flag -fno-common -DPIC works... yes
      checking if gcc static flag -static works... no
      checking if gcc supports -c -o file.o... yes
      checking if gcc supports -c -o file.o... (cached) yes
      checking whether the gcc linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) supports shared libraries... yes
      checking dynamic linker characteristics... darwin11.3.0 dyld
      checking how to hardcode library paths into programs... immediate
      checking whether stripping libraries is possible... yes
      checking if libtool supports shared libraries... yes
      checking whether to build shared libraries... yes
      checking whether to build static libraries... no
      checking whether ln -s works... yes
      checking for pthread_create in -lpthread... yes
      checking for JS_NewContext in -lmozjs185... yes
      checking jsapi.h usability... yes
      checking jsapi.h presence... yes
      checking for jsapi.h... yes
      checking whether JSOPTION_ANONFUNFIX is declared... no
      configure: error: Your SpiderMonkey library is too new.

      Versions of SpiderMonkey after the js185-1.0.0 release remove the optional
      enforcement of preventing anonymous functions in a statement context. This
      will most likely break your existing JavaScript code as well as render all
      example code invalid.

      If you wish to ignore this error pass --enable-js-trunk to ./configure.

      1. 0001-close-COUCHDB-1426.patch
        7 kB
        Benoit Chesneau
      2. 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch
        4 kB
        Benoit Chesneau
      3. 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch
        7 kB
        Benoit Chesneau
      4. 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch
        7 kB
        Benoit Chesneau
      5. 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch
        7 kB
        Benoit Chesneau
      6. 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch
        7 kB
        Benoit Chesneau
      7. COUCHDB-1426.patch
        7 kB
        Paul Joseph Davis

        Activity

        Hide
        Benoit Chesneau added a comment -

        mark it as a blocker since I don't think we should release couchdb with such issue.

        Show
        Benoit Chesneau added a comment - mark it as a blocker since I don't think we should release couchdb with such issue.
        Hide
        Benoit Chesneau added a comment -

        This patch make sure that js libs and include given using the options --with-js-lib and --with-js-include are used in priority, ie before the detection of the version. Also if spidermonkey 1.7.0 is detected it removes useless tests.

        Show
        Benoit Chesneau added a comment - This patch make sure that js libs and include given using the options --with-js-lib and --with-js-include are used in priority, ie before the detection of the version. Also if spidermonkey 1.7.0 is detected it removes useless tests.
        Hide
        Filipe Manana added a comment -

        Neither current master with or without this patch works for me.
        I have spidermonkey 1.8.0 installed via homebrew and built my own spidermonkey 1.8.5 from source. If I try to use the later compilation fails:

        Running configure like:

        $ ./configure --with-js-include=/Users/fdmanana/sm185/install/include --with-js-lib=/Users/fdmanana/sm185/install/lib

        My spidermonkey 1.8.5's tree:

        http://friendpaste.com/2UVvchXGJKGDv2tIzKKgMR

        fdmanana 20:35:42 ~/sm185 > pwd
        /Users/fdmanana/sm185
        fdmanana 20:35:43 ~/sm185 > ./js-1.8.5/js/src/js --version
        JavaScript-C 1.8.5 2011-03-31

        And 'make dev' errors with the patch:

        http://friendpaste.com/6pd556mxhZPRgrVegIV4pH

        Without the patch:

        http://friendpaste.com/5MwatQTQLgiN4Jiz0nWLMd

        My config.log:

        http://friendpaste.com/2M1ijtykz1eDwyZLXNAgsI

        Show
        Filipe Manana added a comment - Neither current master with or without this patch works for me. I have spidermonkey 1.8.0 installed via homebrew and built my own spidermonkey 1.8.5 from source. If I try to use the later compilation fails: Running configure like: $ ./configure --with-js-include=/Users/fdmanana/sm185/install/include --with-js-lib=/Users/fdmanana/sm185/install/lib My spidermonkey 1.8.5's tree: http://friendpaste.com/2UVvchXGJKGDv2tIzKKgMR fdmanana 20:35:42 ~/sm185 > pwd /Users/fdmanana/sm185 fdmanana 20:35:43 ~/sm185 > ./js-1.8.5/js/src/js --version JavaScript-C 1.8.5 2011-03-31 And 'make dev' errors with the patch: http://friendpaste.com/6pd556mxhZPRgrVegIV4pH Without the patch: http://friendpaste.com/5MwatQTQLgiN4Jiz0nWLMd My config.log: http://friendpaste.com/2M1ijtykz1eDwyZLXNAgsI
        Hide
        Benoit Chesneau added a comment - - edited

        @filipe I forgot the case where includes are in include/js (or mozjs). This new iteration should fix it.

        Show
        Benoit Chesneau added a comment - - edited @filipe I forgot the case where includes are in include/js (or mozjs). This new iteration should fix it.
        Hide
        Benoit Chesneau added a comment -

        patch without this spurious print.

        Show
        Benoit Chesneau added a comment - patch without this spurious print.
        Hide
        Filipe Manana added a comment -

        Thanks Benoît.

        Tried the latest patch, there seems to be a syntax error:

        ./configure: line 16477: syntax error near unexpected token `('
        ./configure: line 16477: ` echo $ECHO_N "(cached) $ECHO_C" >&6'

        Show
        Filipe Manana added a comment - Thanks Benoît. Tried the latest patch, there seems to be a syntax error: ./configure: line 16477: syntax error near unexpected token `(' ./configure: line 16477: ` echo $ECHO_N "(cached) $ECHO_C" >&6'
        Hide
        Benoit Chesneau added a comment -

        new patch fixing the issue of filippe. Just tested and it should work as expected.

        @davisp About possible indentation issue, tell me the bible and I will apply it.

        Show
        Benoit Chesneau added a comment - new patch fixing the issue of filippe. Just tested and it should work as expected. @davisp About possible indentation issue, tell me the bible and I will apply it.
        Hide
        Paul Joseph Davis added a comment -

        @benoit

        How about we match the rest of the file for formatting? There are zero cases of indentation matching the argument column. Fixed width indents are used throughout and should be used here as well.

        As to the actual test in that AC_COMPILE_IFELSE I finally realized that its relying on an error being generated due to an invalid preprocessing instruction. It would be better to use the error preprocessor directive there.

        The more I think on this the less I think its fixing either issue directly. The globally installed SM 1.8.5 should have put its headers into $PREFIX/js/ which was being picked up by the three lines you removed that I explicitly added in response to a different error report. Seeing as the header checks haven't changed I'm still not convinced that this isn't introducing a regression for some combination of headers installed.

        On the other hand, there's also this large rearrangement to fix the detection of SM170 which didn't have the anonymous function option. It sure does seem like there's quite a bit of change for this.

        IOW, this patch should be at least two patches. And I'm not convinced we should even attempt at supporting building against multiple installed versions of a library. Picking up headers from system directories is going to be a bitch regardless and trying to teach configure.ac to do a dance itself into knots figuring this out seems like a losing proposition.

        Show
        Paul Joseph Davis added a comment - @benoit How about we match the rest of the file for formatting? There are zero cases of indentation matching the argument column. Fixed width indents are used throughout and should be used here as well. As to the actual test in that AC_COMPILE_IFELSE I finally realized that its relying on an error being generated due to an invalid preprocessing instruction. It would be better to use the error preprocessor directive there. The more I think on this the less I think its fixing either issue directly. The globally installed SM 1.8.5 should have put its headers into $PREFIX/js/ which was being picked up by the three lines you removed that I explicitly added in response to a different error report. Seeing as the header checks haven't changed I'm still not convinced that this isn't introducing a regression for some combination of headers installed. On the other hand, there's also this large rearrangement to fix the detection of SM170 which didn't have the anonymous function option. It sure does seem like there's quite a bit of change for this. IOW, this patch should be at least two patches. And I'm not convinced we should even attempt at supporting building against multiple installed versions of a library. Picking up headers from system directories is going to be a bitch regardless and trying to teach configure.ac to do a dance itself into knots figuring this out seems like a losing proposition.
        Hide
        Benoit Chesneau added a comment -

        I don't see the interrest to specify a lib and include paths if they are not handled in priority. This isn't common at all.

        "On the other hand, there's also this large rearrangement to fix the detection of SM170 which didn't have the anonymous function option. It sure does seem like there's quite a bit of change for this." Can you elaborate ?

        The patch can't be really splitted since all this change is needed. I didn't want at first introduce this detection, but the way the tests are done currently mozjs185 will be always took in priotirty if it exists on the disk even if another path to find js libs has been used. It's probably the same for 1.8.0 though it should be fixed too.

        The other way may be having something like --with-js-version= and we test against that. Though it's still unusual to not use paths defined by the user to find the correct lib. I guess it will give some headache to maintainers on OS when they will have to deal with xulrunner, js 1.8 ... and maybe old lib still installed for old programs. I think the correct way is to discover the versions in this order :

        path given : we should find the version in this path. I think in this case we should test 1.7.0 -> 1.8.5

        if lib or include is not given: 1.8.5 -> 1.8.0 -> ... 1.7.0

        Show
        Benoit Chesneau added a comment - I don't see the interrest to specify a lib and include paths if they are not handled in priority. This isn't common at all. "On the other hand, there's also this large rearrangement to fix the detection of SM170 which didn't have the anonymous function option. It sure does seem like there's quite a bit of change for this." Can you elaborate ? The patch can't be really splitted since all this change is needed. I didn't want at first introduce this detection, but the way the tests are done currently mozjs185 will be always took in priotirty if it exists on the disk even if another path to find js libs has been used. It's probably the same for 1.8.0 though it should be fixed too. The other way may be having something like --with-js-version= and we test against that. Though it's still unusual to not use paths defined by the user to find the correct lib. I guess it will give some headache to maintainers on OS when they will have to deal with xulrunner, js 1.8 ... and maybe old lib still installed for old programs. I think the correct way is to discover the versions in this order : path given : we should find the version in this path. I think in this case we should test 1.7.0 -> 1.8.5 if lib or include is not given: 1.8.5 -> 1.8.0 -> ... 1.7.0
        Hide
        Paul Joseph Davis added a comment -

        > I don't see the interrest to specify a lib and include paths if they are not handled in priority.

        These are there for people to specify extra search paths when the library is not installed in the system wide search paths.

        > This isn't common at all.

        I assume you mean uncommon, and I'm not sure which you're referring to. The priority of handling extra paths?

        If so, then I would disagree a bit in regards to include and link search paths. The compiler already has a default set of paths that it searches and we're trying to work around that to a certain extent. It doesn't help that SpiderMonkey makes this harder than it has to be, but at a certain point that's what we get for using a language that was designed to be used in a browser.

        > "On the other hand, there's also this large rearrangement to fix the detection of SM170 which didn't have the anonymous function option. It sure does seem like there's quite a bit of change for this." Can you elaborate ?

        This is a fairly large change and a lot of it seems unnecessary. There are definitely things we should include. For instance, I like that you reordered the pkg-config check after the command line args checks. But the whole use_js170 flag stuff seems extremely brittle and adds a fair amount of complexity. Unless I'm mistaken we should be able to fix the bug by just reordering the tests so we find defualt = 17.0; check for 1.8.0 -> 1.8.5 -> too_new_version

        > The patch can't be really splitted since all this change is needed.

        Sure it can and if it can't then it just means that we've done it wrong. There are two issues here:

        1. "Accidentally" picking up a system wide SpiderMonkey
        2. Checking for JS_ANON_FUNFIX in 1.7.0 which is a bug.

        Item #2 should be simple enough to fix by changing the ordering when we test for the version detection.

        Item #1 OTOH is a bit of a pain. Its definitely possible to make this work, but I'm not entirely convinced that this patch accomplishes anything more than allowing 1.8.5 installed globally which is different than 1.7 installed globally.

        Show
        Paul Joseph Davis added a comment - > I don't see the interrest to specify a lib and include paths if they are not handled in priority. These are there for people to specify extra search paths when the library is not installed in the system wide search paths. > This isn't common at all. I assume you mean uncommon, and I'm not sure which you're referring to. The priority of handling extra paths? If so, then I would disagree a bit in regards to include and link search paths. The compiler already has a default set of paths that it searches and we're trying to work around that to a certain extent. It doesn't help that SpiderMonkey makes this harder than it has to be, but at a certain point that's what we get for using a language that was designed to be used in a browser. > "On the other hand, there's also this large rearrangement to fix the detection of SM170 which didn't have the anonymous function option. It sure does seem like there's quite a bit of change for this." Can you elaborate ? This is a fairly large change and a lot of it seems unnecessary. There are definitely things we should include. For instance, I like that you reordered the pkg-config check after the command line args checks. But the whole use_js170 flag stuff seems extremely brittle and adds a fair amount of complexity. Unless I'm mistaken we should be able to fix the bug by just reordering the tests so we find defualt = 17.0; check for 1.8.0 -> 1.8.5 -> too_new_version > The patch can't be really splitted since all this change is needed. Sure it can and if it can't then it just means that we've done it wrong. There are two issues here: 1. "Accidentally" picking up a system wide SpiderMonkey 2. Checking for JS_ANON_FUNFIX in 1.7.0 which is a bug. Item #2 should be simple enough to fix by changing the ordering when we test for the version detection. Item #1 OTOH is a bit of a pain. Its definitely possible to make this work, but I'm not entirely convinced that this patch accomplishes anything more than allowing 1.8.5 installed globally which is different than 1.7 installed globally.
        Hide
        Filipe Manana added a comment -

        Thanks Benoit.

        However even with the latest patch I get the same issue as with the first patch:

        gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/snappy/google-snappy -I/opt/local/include -I/usr/local/include -I/usr/include -g -Wall -Werror -D_BSD_SOURCE -DXP_UNIX -I/Users/fdmanana/sm185/install/include -O2 -g -O2 -MT couchjs-http.o -MD -MP -MF .deps/couchjs-http.Tpo -c -o couchjs-http.o `test -f 'couch_js/http.c' || echo './'`couch_js/http.c
        couch_js/http.c:19:19: error: jsapi.h: No such file or directory
        In file included from couch_js/http.c:21:

        However, Randall's initial spidermonkey 1.8.5 commit works for me on Mac OS X:

        http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=7b0f330627c9f3ef1ccb9e3ffe1e909e3a27f1bf

        A few weeks ago I recall master worked for me on Linux with custom --with-js-include and --with-js-lib configure flags.

        Show
        Filipe Manana added a comment - Thanks Benoit. However even with the latest patch I get the same issue as with the first patch: gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/snappy/google-snappy -I/opt/local/include -I/usr/local/include -I/usr/include -g -Wall -Werror -D_BSD_SOURCE -DXP_UNIX -I/Users/fdmanana/sm185/install/include -O2 -g -O2 -MT couchjs-http.o -MD -MP -MF .deps/couchjs-http.Tpo -c -o couchjs-http.o `test -f 'couch_js/http.c' || echo './'`couch_js/http.c couch_js/http.c:19:19: error: jsapi.h: No such file or directory In file included from couch_js/http.c:21: However, Randall's initial spidermonkey 1.8.5 commit works for me on Mac OS X: http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=7b0f330627c9f3ef1ccb9e3ffe1e909e3a27f1bf A few weeks ago I recall master worked for me on Linux with custom --with-js-include and --with-js-lib configure flags.
        Hide
        Benoit Chesneau added a comment - - edited

        @filiippe thanks for the test

        @davisp i was referreing at my previous sentence. Also it used to work.

        I agree that if we can stop on the arguments check rearrangement it would be better. I initailly stopped here. But the reason I have to detect if spidermonkey 1.7.0 is installed is because of the error raised :

        configure: error: Your SpiderMonkey library is too new.

        Versions of SpiderMonkey after the js185-1.0.0 release remove the optional
        enforcement of preventing anonymous functions in a statement context. This
        will most likely break your existing JavaScript code as well as render all
        example code invalid.

        If you wish to ignore this error pass --enable-js-trunk to ./configure.

        which is due to this test:

        AC_CHECK_LIB([$JS_LIB_BASE], [JS_NewCompartmentAndGlobalObject],

        1. Prevent people from accidentally using SpiderMonkey's that are too new

        if test "$use_js_trunk" = "no"; then
        AC_CHECK_DECL([JSOPTION_ANONFUNFIX], [], [
        AC_MSG_ERROR([Your SpiderMonkey library is too new.

        Versions of SpiderMonkey after the js185-1.0.0 release remove the optional
        enforcement of preventing anonymous functions in a statement context. This
        will most likely break your existing JavaScript code as well as render all
        example code invalid.

        If you wish to ignore this error pass --enable-js-trunk to ./configure.])],
        [include <jsapi.h>])
        fi

        I wasn't aware that Spidermonley 1.7.0 was sensible to the anon functions problem. Didn't we add it for new versions? If not then the option naming & error message is awkward and maybe we should rather define a capacity instead of stopping the configure step ? If this test isn't needed for 1.7.0 then we should escape it in that case or test it differently.

        Not sure what we should do.

        Show
        Benoit Chesneau added a comment - - edited @filiippe thanks for the test @davisp i was referreing at my previous sentence. Also it used to work. I agree that if we can stop on the arguments check rearrangement it would be better. I initailly stopped here. But the reason I have to detect if spidermonkey 1.7.0 is installed is because of the error raised : configure: error: Your SpiderMonkey library is too new. Versions of SpiderMonkey after the js185-1.0.0 release remove the optional enforcement of preventing anonymous functions in a statement context. This will most likely break your existing JavaScript code as well as render all example code invalid. If you wish to ignore this error pass --enable-js-trunk to ./configure. which is due to this test: AC_CHECK_LIB( [$JS_LIB_BASE] , [JS_NewCompartmentAndGlobalObject] , Prevent people from accidentally using SpiderMonkey's that are too new if test "$use_js_trunk" = "no"; then AC_CHECK_DECL( [JSOPTION_ANONFUNFIX] , [], [ AC_MSG_ERROR([Your SpiderMonkey library is too new. Versions of SpiderMonkey after the js185-1.0.0 release remove the optional enforcement of preventing anonymous functions in a statement context. This will most likely break your existing JavaScript code as well as render all example code invalid. If you wish to ignore this error pass --enable-js-trunk to ./configure.])], [ include <jsapi.h> ]) fi I wasn't aware that Spidermonley 1.7.0 was sensible to the anon functions problem. Didn't we add it for new versions? If not then the option naming & error message is awkward and maybe we should rather define a capacity instead of stopping the configure step ? If this test isn't needed for 1.7.0 then we should escape it in that case or test it differently. Not sure what we should do.
        Hide
        Benoit Chesneau added a comment -

        make it non blocking for next release. But it's still a critical issue.

        Show
        Benoit Chesneau added a comment - make it non blocking for next release. But it's still a critical issue.
        Hide
        Paul Joseph Davis added a comment -

        I'm so confused. JSOPTION_ANONFUNFIX is an option to the SpiderMonkey VM that appeared and then disappeared (along with its functionality). The test has a bug because 1.7 doesn't have the option (though has the expected behavior). There is a bug in that test, but we should just reorder things so that we only test for JSOPTION_ANONFUNFIX after we test for JS_ThrowStopIteration. And I swear that I've already fixed this at least once. Perhaps I screwed the pooch on a backport or something.

        Show
        Paul Joseph Davis added a comment - I'm so confused. JSOPTION_ANONFUNFIX is an option to the SpiderMonkey VM that appeared and then disappeared (along with its functionality). The test has a bug because 1.7 doesn't have the option (though has the expected behavior). There is a bug in that test, but we should just reorder things so that we only test for JSOPTION_ANONFUNFIX after we test for JS_ThrowStopIteration. And I swear that I've already fixed this at least once. Perhaps I screwed the pooch on a backport or something.
        Hide
        Alex Markham added a comment -

        I had this issue on Centos 5.6 with 1.7 installed and 1.8.5 in /opt/js-1.8.5/
        setting --with-js-include=/opt/js-1.8.5/include resulted in the error above, but setting it to the js folder (where the header files were) resolved it --with-js-include=/opt/js-1.8.5/include/js
        Possibily unrelated, but it showed the same error as the ticket description.

        Show
        Alex Markham added a comment - I had this issue on Centos 5.6 with 1.7 installed and 1.8.5 in /opt/js-1.8.5/ setting --with-js-include=/opt/js-1.8.5/include resulted in the error above, but setting it to the js folder (where the header files were) resolved it --with-js-include=/opt/js-1.8.5/include/js Possibily unrelated, but it showed the same error as the ticket description.
        Hide
        Benoit Chesneau added a comment -

        new version of the patch:

        This patch make sure that js libs and include given using the options --with-js-lib and --with-js-include are used in priority, ie before the detection of the version.

        It also revert the libs detected (JS -> JS185) to make sure the order of CFLAGS and LDFLAGS are used.

        Show
        Benoit Chesneau added a comment - new version of the patch: This patch make sure that js libs and include given using the options --with-js-lib and --with-js-include are used in priority, ie before the detection of the version. It also revert the libs detected (JS -> JS185) to make sure the order of CFLAGS and LDFLAGS are used.
        Hide
        Paul Joseph Davis added a comment -

        There were a couple issues with the last version from Benoit that needed fixing.

        First, the JS_LIB_BASE selection was broken and only worked because of his particular combination of system vs. custom installation paths. It was relying on the older version being installed in a custom path, and picking up the right JS_LIB_BASE based on the order of tests. But if you swap the order (ie, system installed 1.8.0rc1 and custom path for 1.8.5) then you end up getting an error because it picks up -ljs for 1.8.0rc1 and fails to link properly.

        There were also some weirdo edge cases based on how we screw up our usage of LDFLAGS. This should be fixed now.

        I've tried a large number of combinations in specifying custom paths while having a 1.8.0rc1 installed on system paths with no errors, although, this does require some knowledge.

        BIG IMPORTANT NOTE:

        There's a new configuration parameter --with-js-lib-name that people can use to specify the value for -l which bypasses our checks of the various library names that SpiderMonkey uses. Its possible that if you don't specify this that the case I mentioned above kicks in and then there's gnarly error output. Unfortunately, there doesn't appear to be a sane way to match up library names to versions so if you have this error then you can try the new setting to force the use of the proper library name.

        Show
        Paul Joseph Davis added a comment - There were a couple issues with the last version from Benoit that needed fixing. First, the JS_LIB_BASE selection was broken and only worked because of his particular combination of system vs. custom installation paths. It was relying on the older version being installed in a custom path, and picking up the right JS_LIB_BASE based on the order of tests. But if you swap the order (ie, system installed 1.8.0rc1 and custom path for 1.8.5) then you end up getting an error because it picks up -ljs for 1.8.0rc1 and fails to link properly. There were also some weirdo edge cases based on how we screw up our usage of LDFLAGS. This should be fixed now. I've tried a large number of combinations in specifying custom paths while having a 1.8.0rc1 installed on system paths with no errors, although, this does require some knowledge. BIG IMPORTANT NOTE: There's a new configuration parameter --with-js-lib-name that people can use to specify the value for -l which bypasses our checks of the various library names that SpiderMonkey uses. Its possible that if you don't specify this that the case I mentioned above kicks in and then there's gnarly error output. Unfortunately, there doesn't appear to be a sane way to match up library names to versions so if you have this error then you can try the new setting to force the use of the proper library name.
        Hide
        Wendall Cada added a comment -

        The latest version of this patch works for me. The only caveat here is that this forces the use of --with-js-lib and --with-js-include, as it does not auto-detect the installed version of SpiderMonkey. Will require some documentation updates if this is the intended behaviour.

        Show
        Wendall Cada added a comment - The latest version of this patch works for me. The only caveat here is that this forces the use of --with-js-lib and --with-js-include, as it does not auto-detect the installed version of SpiderMonkey. Will require some documentation updates if this is the intended behaviour.
        Hide
        Benoit Chesneau added a comment -

        iterration over last Paul's patch . Some typos were preventing the CFLAGS to be correct.

        Show
        Benoit Chesneau added a comment - iterration over last Paul's patch . Some typos were preventing the CFLAGS to be correct.
        Hide
        Dave Cottlehuber added a comment -

        Thanks Paul & Benoit for helping me on this. My newish linux mint debian, has a /usr/lib/pkgconfig/mozilla-js.pc that points to files that don't exist http://friendpaste.com/1yuN07ZWGTiKQoh47WyFRb and this breaks the configure using above patch. Not sure if this is common case - config.log here http://friendpaste.com/1QhtlBaCUw9RLpPj3UNCrC . mozjs is in /usr/include /usr/lib etc as normal, and is found correctly by current 1.2.x git.

        Show
        Dave Cottlehuber added a comment - Thanks Paul & Benoit for helping me on this. My newish linux mint debian, has a /usr/lib/pkgconfig/mozilla-js.pc that points to files that don't exist http://friendpaste.com/1yuN07ZWGTiKQoh47WyFRb and this breaks the configure using above patch. Not sure if this is common case - config.log here http://friendpaste.com/1QhtlBaCUw9RLpPj3UNCrC . mozjs is in /usr/include /usr/lib etc as normal, and is found correctly by current 1.2.x git.
        Hide
        Noah Slater added a comment -

        We need to address Wendall's comment before this can land. By default, we should auto-detect everything. You should only need to use the flags if you are in a non-default, non-common situation.

        Show
        Noah Slater added a comment - We need to address Wendall's comment before this can land. By default, we should auto-detect everything. You should only need to use the flags if you are in a non-default, non-common situation.
        Hide
        Benoit Chesneau added a comment -

        @noah last iterration should fix the issue of Wendall Cada . At least it does here.

        @Wendall any possibility you can test it ?

        @dave what do you mean by "as normal" ? /usr/include/mozjs ? Can you tell me where is jsapi.h ? Apprently the pkg config doesn't return the right info....

        Show
        Benoit Chesneau added a comment - @noah last iterration should fix the issue of Wendall Cada . At least it does here. @Wendall any possibility you can test it ? @dave what do you mean by "as normal" ? /usr/include/mozjs ? Can you tell me where is jsapi.h ? Apprently the pkg config doesn't return the right info....
        Hide
        Randall Leeds added a comment -

        For me, auto-detection of my libmozjs185 works fine, but the checks are wrong.
        In particular, the AC_CHECK_DECL for JS_ANONFUNFIX says it's not defined. However, config.log reveals that's because 'jsapi.h' can't be found. The header is in /usr/include/js, but that's not being included in the search path.

        I thought a fix would be to amend the PKG_CONFIG success case for libmozjs185 to set $JS_INCLUDE.

        However, now I'm having compilation errors on couchjs, but no problems on an unpatched 1.2.x. I'll report back when I figure out what the difference is.

        Show
        Randall Leeds added a comment - For me, auto-detection of my libmozjs185 works fine, but the checks are wrong. In particular, the AC_CHECK_DECL for JS_ANONFUNFIX says it's not defined. However, config.log reveals that's because 'jsapi.h' can't be found. The header is in /usr/include/js, but that's not being included in the search path. I thought a fix would be to amend the PKG_CONFIG success case for libmozjs185 to set $JS_INCLUDE. However, now I'm having compilation errors on couchjs, but no problems on an unpatched 1.2.x. I'll report back when I figure out what the difference is.
        Hide
        Wendall Cada added a comment -

        The installed js is not being detected if the js headers are in /usr/include/ This is the case for js 1.7 in RHEL/Centos 5/6

        This even fails using --with-js-include=/usr/include/

        COUCHDB-1426 branch 64a1634725ee
        checking for JS... no
        checking for JS... no
        checking for JS... no
        checking jsapi.h usability... no
        checking jsapi.h presence... no
        checking for jsapi.h... no
        checking js/jsapi.h usability... no
        checking js/jsapi.h presence... no
        checking for js/jsapi.h... no
        configure: error: Could not find the jsapi header.

        Are the Mozilla SpiderMonkey headers installed?

        Show
        Wendall Cada added a comment - The installed js is not being detected if the js headers are in /usr/include/ This is the case for js 1.7 in RHEL/Centos 5/6 This even fails using --with-js-include=/usr/include/ COUCHDB-1426 branch 64a1634725ee checking for JS... no checking for JS... no checking for JS... no checking jsapi.h usability... no checking jsapi.h presence... no checking for jsapi.h... no checking js/jsapi.h usability... no checking js/jsapi.h presence... no checking for js/jsapi.h... no configure: error: Could not find the jsapi header. Are the Mozilla SpiderMonkey headers installed?
        Hide
        Wendall Cada added a comment -

        auto-configure, as well as specifying --with-js-lib and --with-js-include works for js-devel-1.8.5

        Here are the file manifests for each of these packages:
        js-devel-1.7: http://friendpaste.com/3nj3hPEsn05f8iQlizahna
        js-devel-1.8.5: http://friendpaste.com/4PoD6hKihtyAyTI64Rpaxx

        Show
        Wendall Cada added a comment - auto-configure, as well as specifying --with-js-lib and --with-js-include works for js-devel-1.8.5 Here are the file manifests for each of these packages: js-devel-1.7: http://friendpaste.com/3nj3hPEsn05f8iQlizahna js-devel-1.8.5: http://friendpaste.com/4PoD6hKihtyAyTI64Rpaxx
        Hide
        Dave Cottlehuber added a comment -

        @benoit thanks again for continuing on this!
        /usr/include/mozjs/ has the include files in it e.g. /usr/include/mozjs/jsapi.h
        this is linux mint 64 debian edition + enough packages for couchdb (erlang-* and libmozjs-dev and libmozjs5d).

        Show
        Dave Cottlehuber added a comment - @benoit thanks again for continuing on this! /usr/include/mozjs/ has the include files in it e.g. /usr/include/mozjs/jsapi.h this is linux mint 64 debian edition + enough packages for couchdb (erlang-* and libmozjs-dev and libmozjs5d).
        Hide
        Paul Joseph Davis added a comment -

        New version of the patch [1] is on the COUCHDB-1426 branch on the ASF Git repo. Sorry about the mass emails earlier. Jason had a branch up there that was based on a weird commit and I didn't check close enough what I was overwriting. (Note to self, we should start a best practices using commiter names in branches).

        So, Dave gave me access to a machine he had that was demonstrating the issue. It turns out with some serendipity from Benoit's diff I figured the issue is that the way we're running PKG_CHECK_MODULE multiple times caches some values that short circuit its internal logic in later invocations. So, when we run it once for the lib detection we cache some values that are reused when checking headers. This means that the include header detection ends up thinking it had 185 installed which ends up adding nothing to the includes.

        I've also used pkg-config --cflags for both mozilla-js and mozjs185 instead of our --variable=includedir shenanigans.

        Randall had one last compilation issue with 1.8.5. I'll try and reproduce here shortly but I might have to wait for him to come back before I can top that off.

        [1] http://git-wip-us.apache.org/repos/asf/couchdb/diff/0150670afa3dda957fd4ce9ab3b58495106f62f2

        Show
        Paul Joseph Davis added a comment - New version of the patch [1] is on the COUCHDB-1426 branch on the ASF Git repo. Sorry about the mass emails earlier. Jason had a branch up there that was based on a weird commit and I didn't check close enough what I was overwriting. (Note to self, we should start a best practices using commiter names in branches). So, Dave gave me access to a machine he had that was demonstrating the issue. It turns out with some serendipity from Benoit's diff I figured the issue is that the way we're running PKG_CHECK_MODULE multiple times caches some values that short circuit its internal logic in later invocations. So, when we run it once for the lib detection we cache some values that are reused when checking headers. This means that the include header detection ends up thinking it had 185 installed which ends up adding nothing to the includes. I've also used pkg-config --cflags for both mozilla-js and mozjs185 instead of our --variable=includedir shenanigans. Randall had one last compilation issue with 1.8.5. I'll try and reproduce here shortly but I might have to wait for him to come back before I can top that off. [1] http://git-wip-us.apache.org/repos/asf/couchdb/diff/0150670afa3dda957fd4ce9ab3b58495106f62f2
        Hide
        Paul Joseph Davis added a comment -

        No go reproducing Randall's issue. Checked the command lines for the linking to no avail. I know I've seen his error before but I can't remember what the screwy fix was.

        His build errors found here:

        http://friendpaste.com/7PHtN13NFGH7q3OT6J9Ega

        Show
        Paul Joseph Davis added a comment - No go reproducing Randall's issue. Checked the command lines for the linking to no avail. I know I've seen his error before but I can't remember what the screwy fix was. His build errors found here: http://friendpaste.com/7PHtN13NFGH7q3OT6J9Ega
        Hide
        Paul Joseph Davis added a comment -

        Whoops. To no avail means they're different. I'm on OS X 10.7.something with whatever that uses. Occurred to me it could be an llvm-gcc vs. gnu gcc on Linux thing or something vs should be g++ or something.

        Show
        Paul Joseph Davis added a comment - Whoops. To no avail means they're different. I'm on OS X 10.7.something with whatever that uses. Occurred to me it could be an llvm-gcc vs. gnu gcc on Linux thing or something vs should be g++ or something.
        Hide
        Wendall Cada added a comment -

        This issue is resolved for me on all my build targets. Ubuntu 10.4+, Fedora 16, RHEL/Centos 6. Using both spidermonkey 1.7/1.8.5 with auto-configuration. Configure flags work as expected in all cases.

        Show
        Wendall Cada added a comment - This issue is resolved for me on all my build targets. Ubuntu 10.4+, Fedora 16, RHEL/Centos 6. Using both spidermonkey 1.7/1.8.5 with auto-configuration. Configure flags work as expected in all cases.
        Hide
        Benoit Chesneau added a comment - - edited

        I have an issue using spidermonkey installed with homebrew on latest OSX lion release with xcode 4.2.1 build 4D502 :

        http://friendpaste.com/1veOXN7EVUC8Z7ZHTDkn6n

        Apparently the check fails due to a problem with the arch. I'm using the COUCHDB-1426 branch.

        Show
        Benoit Chesneau added a comment - - edited I have an issue using spidermonkey installed with homebrew on latest OSX lion release with xcode 4.2.1 build 4D502 : http://friendpaste.com/1veOXN7EVUC8Z7ZHTDkn6n Apparently the check fails due to a problem with the arch. I'm using the COUCHDB-1426 branch.
        Hide
        Dave Cottlehuber added a comment -

        On Mac OS X I get the same as benoitc

        1. COUCHDB-1426
          1. mac os x 10.7 lion
          2. Xcode 4.2 Build version 4D199
          1. spidermonkey versions
            full logs in https://www.dropbox.com/sh/17lzsj9du1fu08v/zkNnXkn46B

        none -> configure fails as expected
        1.7.0 -> configure ok
        1.8.0 -> configure ok
        1.8.5 -> configure fails - pkg-config can't detect nspr

        It seems PKG_CHECK_MODULES([JS185] fails.

        checking for erl... /usr/local/bin/erl
        checking for JS185... yes
        checking for JS185... yes
        Package nspr was not found in the pkg-config search path.
        Perhaps you should add the directory containing `nspr.pc'
        to the PKG_CONFIG_PATH environment variable
        Package 'nspr', required by 'SpiderMonkey 1.8.5', not found
        checking jsapi.h usability... no
        checking jsapi.h presence... no
        checking for jsapi.h... no
        checking js/jsapi.h usability... yes
        checking js/jsapi.h presence... yes
        checking for js/jsapi.h... yes
        checking for JS_NewObject in -lmozjs... no
        checking for JS_NewObject in -ljs... no
        checking for JS_NewObject in -ljs3250... no
        checking for JS_NewObject in -ljs32... no
        checking for JS_NewObject in -lmozjs185-1.0... no
        checking for JS_NewObject in -lmozjs185... yes
        checking for JS_NewCompartmentAndGlobalObject in -lmozjs185... yes
        checking whether JSOPTION_ANONFUNFIX is declared... no
        configure: error: Your SpiderMonkey library is too new.

        Show
        Dave Cottlehuber added a comment - On Mac OS X I get the same as benoitc COUCHDB-1426 mac os x 10.7 lion Xcode 4.2 Build version 4D199 spidermonkey versions full logs in https://www.dropbox.com/sh/17lzsj9du1fu08v/zkNnXkn46B none -> configure fails as expected 1.7.0 -> configure ok 1.8.0 -> configure ok 1.8.5 -> configure fails - pkg-config can't detect nspr It seems PKG_CHECK_MODULES( [JS185] fails. checking for erl... /usr/local/bin/erl checking for JS185... yes checking for JS185... yes Package nspr was not found in the pkg-config search path. Perhaps you should add the directory containing `nspr.pc' to the PKG_CONFIG_PATH environment variable Package 'nspr', required by 'SpiderMonkey 1.8.5', not found checking jsapi.h usability... no checking jsapi.h presence... no checking for jsapi.h... no checking js/jsapi.h usability... yes checking js/jsapi.h presence... yes checking for js/jsapi.h... yes checking for JS_NewObject in -lmozjs... no checking for JS_NewObject in -ljs... no checking for JS_NewObject in -ljs3250... no checking for JS_NewObject in -ljs32... no checking for JS_NewObject in -lmozjs185-1.0... no checking for JS_NewObject in -lmozjs185... yes checking for JS_NewCompartmentAndGlobalObject in -lmozjs185... yes checking whether JSOPTION_ANONFUNFIX is declared... no configure: error: Your SpiderMonkey library is too new.
        Hide
        Randall Leeds added a comment -

        Current branch works beautifully for me. Global 1.8.5 installed is auto-detected, using only --with-js-include and -lib only I'm able to build against both 1.7.0 or 1.8.0.

        Show
        Randall Leeds added a comment - Current branch works beautifully for me. Global 1.8.5 installed is auto-detected, using only --with-js-include and -lib only I'm able to build against both 1.7.0 or 1.8.0.
        Hide
        Dave Cottlehuber added a comment -

        It seems depending on exactly when you last installed spidermonkey &
        its dependency nspr via homebrew, you may be missing nspr.pc.

        Missing nspr.pc causes the invocation of
        `pkg-config --exists --print-errors mozjs185`
        to fail, which AFAICT causes configure to fall through.

        This fixed it (added nspr.pc) for me:

        brew remove --force spidermonkey # clean out multiple versions
        brew remove --force nspr
        brew update # gets a newer version of nspr.rb which now has pkg-config added to it ref https://github.com/mxcl/homebrew/pull/9705 (sha b35dde2)

        Log of my fiddles http://friendpaste.com/6vFJo9ZlPMuHOW3cJZMl6B

        I've not yet checked if as a result, multiple installed Spidermonkeys are correctly handled.

        Show
        Dave Cottlehuber added a comment - It seems depending on exactly when you last installed spidermonkey & its dependency nspr via homebrew, you may be missing nspr.pc. Missing nspr.pc causes the invocation of `pkg-config --exists --print-errors mozjs185` to fail, which AFAICT causes configure to fall through. This fixed it (added nspr.pc) for me: brew remove --force spidermonkey # clean out multiple versions brew remove --force nspr brew update # gets a newer version of nspr.rb which now has pkg-config added to it ref https://github.com/mxcl/homebrew/pull/9705 (sha b35dde2) Log of my fiddles http://friendpaste.com/6vFJo9ZlPMuHOW3cJZMl6B I've not yet checked if as a result, multiple installed Spidermonkeys are correctly handled.
        Hide
        Benoit Chesneau added a comment -

        I tried the installation on a clean machine this afternoon. If pkg-config isn't installed first the pc files aren't created and then the build of couchdb will obviously not work. This is what caused the nspr bug here. Having it installed first and then installing spidermonkey using homebrew fixed the bug I had on macosx.

        At this point I think it's a documentation problem. Or maybe in case we don't discover pkg-config we should check -lnspr to add it to the cflags too. What do you think?

        Show
        Benoit Chesneau added a comment - I tried the installation on a clean machine this afternoon. If pkg-config isn't installed first the pc files aren't created and then the build of couchdb will obviously not work. This is what caused the nspr bug here. Having it installed first and then installing spidermonkey using homebrew fixed the bug I had on macosx. At this point I think it's a documentation problem. Or maybe in case we don't discover pkg-config we should check -lnspr to add it to the cflags too. What do you think?
        Hide
        Dave Cottlehuber added a comment -

        After ditching Xcode and installing just the xcode commandline dev tools, +1 same as Randall, nice clean result.

        I guess the formula update for homebrew couchdb should deal somehow with the missing nspr.pc issue?
        People who've installed spidermonkey etc themselves are not going to be impacted by this I think.

        Show
        Dave Cottlehuber added a comment - After ditching Xcode and installing just the xcode commandline dev tools, +1 same as Randall, nice clean result. I guess the formula update for homebrew couchdb should deal somehow with the missing nspr.pc issue? People who've installed spidermonkey etc themselves are not going to be impacted by this I think.
        Hide
        Randall Leeds added a comment -

        The only improvement I'd like to see, if possible, is a way to disambiguate path issues from non-declaration of the JS_ANONFUNFIX. For me, I had to dig into config.log. Is there an improvement we could make so that a test for jsapi.h fails first? I think we already have that, but we were missing some branch which properly set the CPPFLAGS. I'm pretty sure we're good to go, but I figured I would mention it.

        +1 to merge.

        Show
        Randall Leeds added a comment - The only improvement I'd like to see, if possible, is a way to disambiguate path issues from non-declaration of the JS_ANONFUNFIX. For me, I had to dig into config.log. Is there an improvement we could make so that a test for jsapi.h fails first? I think we already have that, but we were missing some branch which properly set the CPPFLAGS. I'm pretty sure we're good to go, but I figured I would mention it. +1 to merge.
        Hide
        Randall Leeds added a comment -

        A quick review of configure.ac has me convinced that the JS_ANONFUNFIX test should not fail for lack of finding jsapi.h anymore. +1 for certain. I don't see any outstanding failure reports. Okay to merge?

        Show
        Randall Leeds added a comment - A quick review of configure.ac has me convinced that the JS_ANONFUNFIX test should not fail for lack of finding jsapi.h anymore. +1 for certain. I don't see any outstanding failure reports. Okay to merge?
        Hide
        Benoit Chesneau added a comment -

        waiting for @davisp feedback, but will be happy to merge it if it's OK

        Show
        Benoit Chesneau added a comment - waiting for @davisp feedback, but will be happy to merge it if it's OK
        Hide
        Paul Joseph Davis added a comment -

        Last decision is to see if we want to check if we can detect this nspr issue using PKG_CHECK_EXISTS(mozjs185) && ! PKG_CHECK_EXISTS(nspr) and print a warning message if so (assuming that check even works). Other than that, I think we're good to go.

        Show
        Paul Joseph Davis added a comment - Last decision is to see if we want to check if we can detect this nspr issue using PKG_CHECK_EXISTS(mozjs185) && ! PKG_CHECK_EXISTS(nspr) and print a warning message if so (assuming that check even works). Other than that, I think we're good to go.
        Show
        Paul Joseph Davis added a comment - Fixed: http://git-wip-us.apache.org/repos/asf/couchdb/diff/29eac043
        Hide
        Dave Cottlehuber added a comment -

        works for me - thanks everybody!!

        Show
        Dave Cottlehuber added a comment - works for me - thanks everybody!!

          People

          • Assignee:
            Unassigned
            Reporter:
            Benoit Chesneau
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development