Open GoogleCodeExporter opened 9 years ago
Same error with rev 3040 and 2572.
Original comment by tae...@gmail.com
on 2 Jun 2010 at 9:53
I am sorry, jslibs is not supported on Mac OS yet. Currently I have no access
to a Mac
to achieve this porting task.
Original comment by sou...@gmail.com
on 3 Jun 2010 at 4:51
Original comment by sou...@gmail.com
on 2 Jun 2011 at 10:46
These reports are pretty old, so I'm not sure anyone will actually see this;
but, whatever -- I'll add some (maybe helpful?) pointers here, until work lets
up and I can actually take a swing at compiling everything on OSX (minus
MSWin-specific stuff, obviously)...
>> I have got an error when trying to compile on Mac OS 10.4.11 :
OK, hopefully no one's still using OSX 10.4. At any rate, I'm pretty sure (by
which I mean totally certain) that Mozilla's infrastructure (including
SpiderMonkey/MozJS/whatever-the-current-JS-engine-name-is) requires 10.6 to
build nowadays.
>> Rudloff:~ pierre$ cd /Users/pierre/Desktop/libs/jslibs/
>> Rudloff:~/Desktop/libs/jslibs pierre$ make all
OK, next big item: Using a Makefile specific to Linux will typically require --
at the least -- setting some extra envs and/or passing some extra flags.
Standard linux GCC flags don't always *directly* map to how OSX's binaries and
[DY]LD handle things. clang's more OSX-friendly out-of-the-box, but it *will*
still listen to many more "linux-oriented" flags, if explicitly given, leading
to crashing and/or burning -- that, or it will just refuse to accept those
flags and die.
Of course, I haven't actually looked at the main jslibs-specific Makefiles, so
I can't comment further on them. If all the prereqs are there, SpiderMonkey's
build system is quite capable of setting all of *its own* parameters for OSX,
but obviously everything around it has to be in sync and not overriding its own
detection mechanisms...
More to come here on this point, hopefully -- I've built most (all?) of the
non-MSWin libs individually, so then it would just be figuring out any kinks in
the `make` params + wrapper c files. In the meantime, I'd check out the
settings MacPorts uses to build some of these libs (their porting scripts are
quite readable, and tend to be a little more stable than Homebrew's)...
>> make -C libs/js all BUILD=opt BITS=32
>> DEST_DIR=/Users/pierre/Desktop/libs/jslibs/Darwin_32_opt/
>> uname: illegal option -- o
>> usage: uname [-amnprsv]
Gnu-specific `uname` opts: -o, -i. You might be able to get away with the
following shell function as a hacky quick-fix (works for me). If you select the
text below, starting at "export", down to the 2nd closing SINGLE-quote, and
copy those ~5 lines, you should be able to paste it *directly* at the prompt in
A NEW SHELL SESSION, without disaster ensuing (you might need to hit enter
after, depending on whether you copied the last linefeed -- OH, AND UNDER ALL
OTHER NORMAL CIRCUMSTANCES, DON'T EVER `eval` RANDOM SHELL SCRIPT SNIPPETS YOU
FIND ON THE INTERNET!):
export IFS=$' \t\n'; eval '
uname() {
set -- "${*//i/m}"; set -- "${*//o/s}"; command uname "-${*//[-[:space:]]/}";
}; export -f uname;
'
>> cd ./src/ && ( autoconf2.13 || autoconf-2.13 )
>> /bin/sh: line 1: autoconf2.13: command not found
>> /bin/sh: line 1: autoconf-2.13: command not found
SpiderMonkey literally requires that EXACTLY version 2.13 of autoconf be
available in $PATH (as `autoconf2.13`, by default). There's a long, sordid
story behind that, but that's the short of it... [continued below]
>> make[1]: *** [src/configure] Error 127
>> make: *** [libs/js] Error 2
>> Rudloff:~/Desktop/libs/jslibs pierre$
>> I have the last version of autoconf.
Yes, it is good to ALSO have the newest autoconf version TOO. *BUT*, much of
the mozilla software ecosystem still has random weirdo dependencies on autoconf
v2.13. SO YOU NEED BOTH. Again, check MacPorts (or Homebrew, if you really
prefer).
OK, we'll see when I can get back to this...
Original comment by Shannon....@gmail.com
on 15 Aug 2014 at 8:24
Original issue reported on code.google.com by
tae...@gmail.com
on 28 May 2010 at 6:29