incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed
Date Thu, 01 Mar 2012 22:42:59 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220442#comment-13220442
] 

Paul Joseph Davis commented on COUCHDB-1426:
--------------------------------------------

> 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.
                
> error while building with 2 spidermonkey installed
> --------------------------------------------------
>
>                 Key: COUCHDB-1426
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1426
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 1.1.1, 1.2
>            Reporter: Benoit Chesneau
>            Priority: Blocker
>         Attachments: 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch,
0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message