How to build Seamonkey?

[Jochen Schäfer]

It doesn't.

[Dave Yeo]

Ok, I forgot another change that has happened, Mozilla's head is now based on 52ESR.
CD into mozilla/
Do

Code: [Select]

git checkout esr45


Code: [Select]

git branch
will tell you what branch you're on.

[Jochen Schäfer]

Hi Dave.

That did it. Also, it seems that the autoreconf in ffi is not necessary anymore.
Autoreconf is necessary, but it fails to run autoconf213, claiming it's not existing. AUTOCONF should be set to autoconf, while Laurenz' mozconfig.suite points to autoconf213. How is the correct setting (AUTOCONF213 points to autoconf213).

EDIT: Now I get the error message configure: error: ECMAScript Internationalization API is not yet supported on this platform.
How can I fix that?
Seems to be because mach mercurial-setup wasn't run.


Bye Jochen

[Dave Yeo]

Do you have libicu-devel installed? Do you have
ac_add_options --with-intl-api
ac_add_options --with-system-icu
in your mozconfig?
You could always change
ac_add_options --with-intl-api
to
ac_add_options --without-intl-api
for now.

[Jochen Schäfer]

Yes, I have. But look my above message: I have edited it.

[Dave Yeo]

Current autoconf-2.69 and autoconf 2.13 are quite different. Comm-45 and Mozilla-45 configure scripts are both based on autoconf 2.13 while libffi and NSPR's are based on the newer autoconf.
Client.mk uses the autoconf variable to find autoconf-2.13, its possible having this set may break autoconf-2.69 so run autoreconf or autoconf-2.69 in a session without %AUTOCONF% set.
Once run, the autogenerated files should be ignored by git/mercurial, see .gitignore and .hgignore, which is likely why autoreconf didn't seem to be needed to be run again. To be safe, I'd rerun it.
Not sure about running mach mercurial-setup, our mercurial is pretty broken due to being old and Python updates.
You do probably need to setup your %HOME%\.hgrc file, here's mine including commented out lines

Code: [Select]

[ui]
username = dryeo <dave.r.yeo@gmail.com>
merge = kdiff3
editor = epm.exe
verbose = True
debug = True
ssh = ssh -C -i I:/fate/.ssh/id_dsa
# 2012-11-12 SHL testing encoding warning fix
fallbackencoding = UTF-8

[diff]
git = 1
unified=8

[defaults]
diff=-U 8 -p
qdiff=-U 8
qnew = -U

[extensions]
hgext.mq=
#eol=
#hgext.win32text =
#hgext.bookmarks =
#hggit = i:/python26/Lib/site-packages/haggit
#hggit= i:/usr/src/hg-git/hggit

[win32text]
warn = False

[encode]
#**.cmd = dumbencode:
#** = cleverencode:
[decode]
#**.cmd = dumbdecode:
#** = cleverdecode:

[hooks]
# Reject commits which would introduce windows-style text" files

#pretxncommit.crlf = python:hgext.win32text.forbidcrlf

[hostsecurity]
disabletls10warning = true
[/code

[Jochen Schäfer]

Hi Dave.

Actually, I got it running. Alas, the build stopped at not finding gtest_prod.h.
According to the internet, it belongs to Google Test. How do I go on?

[Dave Yeo]

That's weird, it should be in mozilla/testing/gtest/gtest/include/gtest and mozilla/media/webrtc/trunk/testing/gtest/include/gtest. (copy in nss too). Seems to only be referenced by some tests.
Did you disable tests? Sometimes the fix is to delete your object directory and start over. Also look at your log and try to see what was including it.

[Jochen Schäfer]

I did that. I re-auto(re)confed everything.
Now, it stops in libffi with an ended pipe. What now?

[Dave Yeo]

Hmm. Try going to $OBJDIR/js/src/ctypes/libffi and doing make clean and then make and see if it still happens. If that don't work, try putting SET GCCOPTS=-nopipe in your environment.

[Jochen Schäfer]

Oh, my. It makes no difference.
You know, I only want to establish a good build environment for autoconf/make ports. So I don't know whether, it is necessary to solve this problem. What do you think?

[Dave Yeo]

Well if all you're doing is testing your build environment, it is likely set up good enough. The broken pipe is a weird error and could be lots of things. It's up to you if you want to try pursuing it.

[Jochen Schäfer]

Thanks for your help. I will try to go from here.