| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
The python binary copied reports a valid signature on Big Sur and thus codesign fails.
Add the -f option so it overwrites the supposedly valid signature. Other versions are
either already unsigned or the install_name_tool invalidates the signature.
|
|
|
|
| |
This leaves just use of recursive make to build applications.
|
|
|
|
|
|
| |
Newer MSVC was failing to find the devenv executable for ./mach run --debug
This isn't the prettiest solution, but at least it's better than just relying
on a hardcoded path.
|
| |
|
|
|
|
|
|
| |
invalidates code signature.
The code signature is invalidated on Intel as well, but on ARM the binary fails to run with an invalid code signature error.
|
|
|
|
| |
set.
|
|
|
|
| |
Compilation failed due to missing sys/ioctl.h header on MacOS and FreeBSD. Call to function ioctl() with no prototype. This was non-fatal due to the psutil component being optional.
|
|
|
|
|
|
|
|
|
| |
the rest of the tree.”
This also removes some PP abuse and takes file entries out of PP when no longer
needed without XP_MACOSX conditionals.
This reverts commit 6f707bde95dab6998ac204f9ee6c925ee230c740.
|
|
|
|
|
| |
So we can build bzip2 MARs for selectively updating older versions of
the applications that don't understand xz.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Bug 1295937
|
|
|
|
| |
The Python script here claims it can handle any Bourne-compatible shell, but the detection logic here really only works with GNU Bash. Not that there are that many Bourne-compatible shell implementations to compare against...
|
|
|
|
|
| |
Hard-code the values in AppConstants.jsm for compatibility, even if
nobody should actually be using this in extensions or what not.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To make a long story short, there's an old flag called NSDISTMODE that
was never added to old-configure so it could be passed down through the
build system to all the places it needs to go nowadays if used in your
.mozconfig, but which still sort of works when set as an environment
variable. If you leave it unset, it uses relative symlinks. However, it
has two other modes. One of them is "copy" and the other is
"absolute_symlink." Copy simply copies the files into the directory, and
absolute_symlink attempts to use absolute symlinks instead of relative
ones.
I've been wondering for a while now if there was a way to make the
shared library files in `dist/bin` that we use `./mach run` against
*not* be relative symlinks, and this seems to be that elusive technique.
It seems to be a part of the institutional memory that was all but lost
shortly after Netscape went under. You mostly see a few references to it
in NSS, NSPR, and the Makefiles in the `config` directory. And also
there is one reference in a Makefile in the application directory, which
seems to explains why application executables themselves usually aren't
symlinks:
/platform/libs/nspr/src/pr/src/md/unix/Makefile.in#76
/platform/libs/nss/src/coreconf/UNIX.mk#34
/palemoon/app/Makefile.in#30
/platform/config/config.mk#396
My patch essentially revives NSDISTMODE and makes it work as intended
again, more or less. Some parts of the work are loosely inspired by this
bug that was never finished upstream, showing that Mozilla only
rediscovered it earlier this year while trying to disable symlinks in
dist/bin for WSL, as far as I can tell.
https://bugzilla.mozilla.org/show_bug.cgi?id=1699855
|
| |
|
|
|
|
| |
Resolves #1835
|
|
|
|
| |
Mostly IPC, tools and mozbuild.
|
|
|
|
|
|
|
|
| |
Part of Mozilla's DaaS, "bootstrapping" the tree is heavily dependent on
Mozilla infrastructure, m-c structure and dependencies, libs, toolchain,
etc. and would never work for us. Sweeping some clutter, in other words.
This copies in a function that was imported from mozboot to satisfy deps.
|
|
|
|
| |
as well as robocop.
|
|
|
|
| |
processors, some Andoid packaging stuff, Eclipse IDE support et al.
|
|
|
|
|
| |
This also removes some PP abuse and takes file entries out of PP when no longer
needed without XP_MACOSX conditionals.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make essential Tauthon's builtins and modules available in sandboxes, without
disrupting building with Python 2.7.
1. Allow new builtins and modules. "__build_class__" is for
building... new-style classes (to handle the new metaclass syntax imported from
3.x). "_oserror" is necessary because of internal changes to raise errors
deriving from OSError (which are reported as IOError if not caught).
2. Look for modules and packages in the right places.
This was tested on FreeBSD, and should work out of the box on Linux.
|
| |
|
|
|
|
|
|
| |
'sysctl' interface to currently opened connections changed in FreeBSD 12.
Drop support for FreeBSD < 9, these are very old and unsupported versions.
|
|
|
|
| |
Also adds options for new functionality in #1683
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This reverts PR #429
|
|
|
|
|
|
| |
"Make the unpreprocessed file script work on Solaris."
This reverts commit e51afbcc2fe7360bbcf5654f6e31752c48098ca0.
|
|
|
|
|
| |
* So far this seems to only affect Macintosh builds but other unix builds may be affected. Windows doesn't seem to be.
* This maintains consistency with other one-off file invocations and backwards compatibility with older comm setups
|
|
|
|
| |
This requires changes to package-manifest in all applications
|
| |
|
| |
|
|
|
|
| |
hardcoded values in comm-style configurations
|
|
|
|
|
| |
* The langpack is not generated via the package target but IS for mozpackage target using old behavior
* Add mach command to specifically generate the langpack when needed without the rest of the packaging routine (mach langpack)
|
|
|
|
|
|
|
| |
* This adds what will eventually be a rewritten packaging routine while maintaining backwards compatibility with the original mozilla routine
* Changes the build target and installer makefile to use the alternative packaging
* Adds build target to specifically invoke the original mozilla routine
* Update mach commands accordingly
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
work on Solaris.
https://www.tachytelic.net/2019/01/grep-recursively/
During testing, I tried simply replacing grep with ggrep, which was non-portable but worked fine. Using an environment variable with os.getenv set to 'g' also worked, but the problem with that approach is that you have to set it manually and some times the script will mess up if you don't explictly define it to an empty string for platforms that don't need it.
Setting TOOLCHAIN_PREFIX to 'g' seemed to solve all of my problems except this one, and it appears to be the only non-portable use of GNU grep in the whole tree. To understand what I tried to do here, let me present with you with two commands that yield the same output on my machine:
find . -name '*.xul' | xargs grep -E "#include"
ggrep -E -r "#include" --include="*.xul" .
I just tried to make the Python script follow the logic of those two commands, though I'm not sure how well I succeeded since I got no errors. I visualized everything this way:
ggrep -E -r "<strings>" --include="<filesuffixes>" <path>
find <path> -name '<filesuffixes>' | xargs grep -E "<strings>"
And arranged it all accordingly to the best of my ability, though I should point out that Python is not my strong suit.
|
|
|
|
|
|
|
|
| |
libevent/IPC junk.
This is mostly ifdefs, but as you can see, Solaris is actually a lot like Linux. They're both more SysV than BSD at core, and most of the differences have more to do with Solaris not using glibc than anything else.
I still need to audit a lot of these changes and understand why they're needed and what the alternative approaches are. After this patch, most of the core functionality needed to build Solaris is here.
|
|
|
|
|
|
| |
https://bugzilla.mozilla.org/show_bug.cgi?id=1360571
Solaris uses ksh as the default shell, and furthermore bash doesn't seem to support the 'local' keyword feature when invoked as sh on OpenIndiana. We could just change the script to use bash (it is an option even on Solaris), but this fix is available and Mozilla has been using it since Firefox 55 with no issues on any other platforms. It was specfically done this way to avoid any need to change existing mozconfig files, so I feel confident saying the change is totally benign and if anything the way it is now is technically a POSIX compliance issue inherited from Mozilla that we'll hit if we ever try to compile this on any Unix platform where bash isn't sh.
|
| |
|
| |
|
|
|
|
| |
The mozconfig output parsing code already (mostly) handles shell quoted strings, because that's what `set` outputs. By quoting environment variable values, we avoid a bunch of problems with "weird" values.
|
| |
|