couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peng Hui Jiang" <jian...@cn.ibm.com>
Subject RE: Help with linking against SpiderMonkey 60 on macOS
Date Mon, 06 Jan 2020 02:00:19 GMT
Yes, Jan. The switch for configure will make difference. This is also true
for Windows platform. I drafted one PR
https://github.com/apache/couchdb-glazier/pull/11/files for Windows
platform.

Below is one fro Debian and I notice that most of them are the same as
yours now but `make j4` which will make compile faster.
===========
                                              
 RUN echo "-- building and installing         
 spidermonkey" && \                           
                                              
                                              
                                              


                             
 apt-get install -y          
 autoconf2.13 && \           
                             
                             
                             


                       
 apt-get install -y    
 yasm && \             
                       
                       
                       


                                                   
 mkdir -p ~/tmp/spidermonkey && cd                 
 ~/tmp/spidermonkey && \                           
                                                   
                                                   
                                                   


                                                                                         
    
 wget                                                                                    
    
 http://ftp.mozilla.org/pub/firefox/releases/60.3.0esr/source/firefox-60.3.0esr.source.tar.xz

 && \                                                                            
            
                                                                                         
    
                                                                                         
    
                                                                                         
    


                                  
 tar -xf                          
 firefox-60.3.0esr.source.tar.xz  
 && \                             
                                  
                                  
                                  


                       
 cd                    
 firefox-60.3.0/js/src 
 && \                  
                       
                       
                       


                         
 export SHELL=/bin/bash  
 && \                    
                         
                         
                         


              
 mkdir obj && 
 \            
              
              
              


           
 cd obj && 
 \         
           
           
           


              
 ../configure 
 \            
              
              
              


                  
 --disable-ctypes 
 \                
                  
                  
                  


               
 --disable-ion 
 \             
               
               
               


                    
 --disable-jemalloc 
 \                  
                    
                    
                    


                   
 --enable-optimize 
 \                 
                   
                   
                   


                               
 --enable-posix-nspr-emulation 
 \                             
                               
                               
                               


                    
 --enable-hardening 
 \                  
                    
                    
                    


                    
 --with-system-zlib 
 \                  
                    
                    
                    


                 
 --with-intl-api 
 && \            
                 
                 
                 


             
 make -j4 && 
 \           
             
             
             



make install

===========

Best regards,
Peng Hui



From:	Jan Lehnardt <jan@apache.org>
To:	CouchDB Developers <dev@couchdb.apache.org>
Date:	2020/01/06 03:32 AM
Subject:	[EXTERNAL] Re: Help with linking against SpiderMonkey 60 on
            macOS



Thanks to Joan, Paul and
https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_map&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=PKZ65oA9tV05sXjYYyZUJf_d-ASaaLXiLw-gQdWPDsQ&m=gAC474eVypB0az_jWlFjWV1wXNtFR4yUEF0OqvxqjyA&s=twpZaJ9jipxmC-iB4O106jvTkjITbty5VIF__px8Z1A&e=
 , I’ve got it working. The trick was slightly different ./configure
options for SM60:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_janl_homebrew-2Dcouchdb_blob_master_Formula_spidermonkey60.rb&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=PKZ65oA9tV05sXjYYyZUJf_d-ASaaLXiLw-gQdWPDsQ&m=gAC474eVypB0az_jWlFjWV1wXNtFR4yUEF0OqvxqjyA&s=OkgFS-ZYhmuxDEfLfHvrZucVZwvS14wzQLGu4qKBfRo&e=


the --disable-jemalloc and --enable-posix-nspr-emulation options seem to
have done the trick.

Thanks all!

Best
Jan
—

> On 5. Jan 2020, at 18:01, Jan Lehnardt <jan@apache.org> wrote:
>
> Hey all,
>
> I’m trying to get the Mac binary build set up for the 3.0 release.
>
> The biggest change in that regard is the new SpiderMonkey version.
>
> To make my life here a little easier, I want to separate the building of
SpiderMonkey and CouchDB. To that end, I’ve set up a Homebrew Tap for SM60
that I then just depend on being installed when building CouchDB.
>
> This is my build script for SM60 itself:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_janl_homebrew-2Dcouchdb_blob_master_Formula_spidermonkey60.rb&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=PKZ65oA9tV05sXjYYyZUJf_d-ASaaLXiLw-gQdWPDsQ&m=gAC474eVypB0az_jWlFjWV1wXNtFR4yUEF0OqvxqjyA&s=OkgFS-ZYhmuxDEfLfHvrZucVZwvS14wzQLGu4qKBfRo&e=

>
> It produces a .dylib (think .so, but for a Mac) that looks good from the
outside:
>
>> file /usr/local/lib/libmozjs-60.dylib
> /usr/local/lib/libmozjs-60.dylib: Mach-O 64-bit dynamically linked shared
library x86_64
>
>> otool -L /usr/local/lib/libmozjs-60.dylib
> /usr/local/lib/libmozjs-60.dylib:
> 		 /usr/local/opt/spidermonkey60/lib/libmozjs-60.dylib
(compatibility version 1.0.0, current version 1.0.0)
> 		 /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 228.0.0)
>
/System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling
 (compatibility version 1.0.0, current version 13.0.0)
> 		 @executable_path/libmozglue.dylib (compatibility version
1.0.0, current version 1.0.0)
> 		 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1252.250.1)
> 		 /usr/local/opt/icu4c/lib/libicui18n.64.dylib (compatibility
version 64.0.0, current version 64.2.0)
> 		 /usr/local/opt/icu4c/lib/libicuuc.64.dylib (compatibility
version 64.0.0, current version 64.2.0)
> 		 /usr/local/opt/icu4c/lib/libicudata.64.dylib (compatibility
version 64.0.0, current version 64.2.0)
> 		 /usr/local/opt/nspr/lib/libplds4.dylib (compatibility version
1.0.0, current version 1.0.0)
> 		 /usr/local/opt/nspr/lib/libplc4.dylib (compatibility version
1.0.0, current version 1.0.0)
> 		 /usr/local/opt/nspr/lib/libnspr4.dylib (compatibility version
1.0.0, current version 1.0.0)
> 		 /usr/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.11)
> 		 /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
version 400.9.4)
>
> Now I’m building CouchDB master. I have to add some more options to
src/couch/rebar.config.script to make things work:
>
> @@ -153,7 +158,10 @@ CouchJSEnv = case SMVsn of
>         [
>             {"CXXFLAGS", JS_CFLAGS ++ " " ++ CURL_CFLAGS},
>             {"LDFLAGS", JS_LDFLAGS ++ " " ++ CURL_LDFLAGS}
> -        ]
> +        ] ++ case os:type() of
> +                {unix, darwin} -> [{"CC", "clang++"}];
> +                _ -> []
> +            end
>
>
> This sets CC to clang++, the native C++ compiler. This might seem odd,
normally rebar should pick that up on its own, but it doesn’t. If I don’t
do this, I get a number of other errors, where research had convinced me to
make this particular change:
>
>
> Undefined symbols for architecture x86_64:
>  "std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::__init(char const*, unsigned long)",
referenced from:
>      std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::basic_string<std::nullptr_t>(char const*) in
util.o
> … (full log
https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_janl_05bda5498d1851c13966cbcd20f656f7&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=PKZ65oA9tV05sXjYYyZUJf_d-ASaaLXiLw-gQdWPDsQ&m=gAC474eVypB0az_jWlFjWV1wXNtFR4yUEF0OqvxqjyA&s=atZc17TxH7QJlffWNjLnTNj_fqHUvVBTuKGx2x5o5pc&e=
 )
>
> Now I’m not so sure any more, maybe there is another way to resolve these
undefined symbols without introducing the next error.
>
> With CC=clang++, the compilation step works all fine, but now the linker
complains:
>
> Undefined symbols for architecture x86_64:
>  "_moz_arena_malloc", referenced from:
>      js_malloc(unsigned long) in util.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
invocation)
> ERROR: sh(clang++ priv/couch_js/60/http.o priv/couch_js/60/main.o
priv/couch_js/60/utf8.o priv/couch_js/60/util.o -L/usr/local/lib -lmozjs-60
-lm -std=c++14 -DHAVE_CURL -lcurl
-L"/usr/local/Cellar/erlang/22.2.1/lib/erlang/lib/erl_interface-3.13.1/lib"
-lerl_interface -lei -o priv/couchjs)
> failed with return code 1 and the following output:
> Undefined symbols for architecture x86_64:
>  "_moz_arena_malloc", referenced from:
>      js_malloc(unsigned long) in util.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
invocation)
>
> ERROR: compile failed while processing /Users/jan/Work/couchdb/src/couch:
rebar_abort
> make: *** [couch] Error 1
>
>
> Which seems a lot more manageable, but I can’t for the life of me figure
out what’s wrong here.
>
> The linker invocation looks fine pointing
to /usr/local/lib/libmozjs-60.dylib.
>
> our util.o indeed uses a JS_alloc() function. Said function is a macro
defined in jsapi.h pointing to js/Utility.js’s js_malloc, which in turn
uses the _moz_arena_malloc.
>
> The symbols are all available in the libmozjs-60.dylib:
>
> nm -gC /usr/local/lib/libmozjs-60.dylib | grep malloc
> 000000000029da8b T JS_malloc(JSContext*, unsigned long)
>                 U _malloc
>                 U _moz_arena_malloc
>
> The only point of note is that _moz_arena_malloc is a U and JS_malloc a T
here. The no-C++ version garbles the JS_malloc symbol, but I’m not sure why
that would make _moz_arena_malloc unfindable:
>
>
> nm -g /usr/local/lib/libmozjs-60.dylib | grep malloc
> 000000000029da8b T __Z9JS_mallocP9JSContextm
>                 U _malloc
>                 U _moz_arena_malloc
>
>
> Inside SM60 moz_arena_malloc is defined in malloc_decls.h which gets
included via mozmemory.h and js/Utility.js which all seems cromulent.
js_alloc() is an inline function, which is, I think, why we get the
_moz_arena_malloc missing reference in our util.h, because we are not
calling out to any external functions actually.
>
> What I’m not sure about now is where to continue digging:
>
> 1. is my libmozjs-60.dylib somehow not up to snuff exporting all symbols
correctly for our C/C++ hybrid?
>
> 2. is the way we link against the dylib somehow missing options. I’ve
experimented with every which combination of -stdlib=libc++ -std=gnu++14
and whatever other settings I could find online, to no avail.
>
> 3. is my attempt to swap in clang++ as the CC at fault and is there
another way to fix the “undefined std::__1::basic_string” errors (note that
this route still also has a missing reference for _moz_arena_malloc.
>
>
> Either way,
https://urldefense.proofpoint.com/v2/url?u=http-3A__clang.llvm.org_compatibility.html-23inline&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=PKZ65oA9tV05sXjYYyZUJf_d-ASaaLXiLw-gQdWPDsQ&m=gAC474eVypB0az_jWlFjWV1wXNtFR4yUEF0OqvxqjyA&s=2bv-KzVkulaOHYeydU2R1PzG4iMUd9DcFtzHt0Q0Wew&e=
  suggests that if js_malloc() were an `inline` function, that would
explain the situation, and a fix would be to mark it `static inline`.
Unfortunately it is already a `static inline`.
>
> Ohey, while writing this, I found that when adding `-lc++` to LDFLAGS, I
get rid of the “undefined std::” errors, but the _moz_arena_malloc remains.
>
> I would imagine that swapping in clang++ as CC automatically links
against libc++, which is why we get to the same place via two routes.
>
> * * *
>
> Any tips very much appreciated!
>
> Best
> Jan
> --
> Professional Support for Apache CouchDB:
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__neighbourhood.ie_couchdb-2Dsupport_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=PKZ65oA9tV05sXjYYyZUJf_d-ASaaLXiLw-gQdWPDsQ&m=gAC474eVypB0az_jWlFjWV1wXNtFR4yUEF0OqvxqjyA&s=euEcqvU7pxVJpPU5LKcLdEsATIdiuSIns_5jYeHmACQ&e=

>

--
Professional Support for Apache CouchDB:
https://urldefense.proofpoint.com/v2/url?u=https-3A__neighbourhood.ie_couchdb-2Dsupport_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=PKZ65oA9tV05sXjYYyZUJf_d-ASaaLXiLw-gQdWPDsQ&m=gAC474eVypB0az_jWlFjWV1wXNtFR4yUEF0OqvxqjyA&s=euEcqvU7pxVJpPU5LKcLdEsATIdiuSIns_5jYeHmACQ&e=





Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message