This contains the contents of Haiku's sources, which is necessary
to include in "with source" builds for proper (L)GPL compliance,
mostly because we have GPL code in the tree.
"cpp" is the system C preprocessor, not the one from our cross-compiler,
and in the case of my system which does not have GCC installed at all,
it doesn't even exist.
With this, Clang-ARM builds successfully create a "haiku-arm.mmc".
I couldn't get it to output, even after blessing it with "rune",
but that may just be my fault...
Now that HOST_CC is actually passed in, we need to default
everything to it; otherwise, it's up to the Jambase as to
what CC we are actually using.
Found by trying to build Haiku on a system that has no "cc"
executable, but Jam tried to use it anyway (as all three of CC,
C++, and LINK.)
The former is passed to the compiler when linking using it,
the latter is passed to ld when it is invoked directly.
Also modify ArchitectureRules to not overwrite this setting.
This rule process the entire target's source files at once, and so
whoever wrote this rule in the first place (PulkoMandy?) probably
assumed without even testing that "cc -E" would create multiple
outputs for multiple inputs.
It doesn't, though: it just outputs them in sequence on the command line
the same way it does when the files are piped in through "cat". This
also has other advantages (e.g. preprocess errors caused by the compiler
assuming it was C not C++ code and so not defining __cplusplus, local
includes are now resolved properly, etc.)
Doing it this way does exposes other problems like the one fixed in the
previous commit (headers with no context defined, which worked previously
only because they used the context of the preceding `cat`'ed file.)
We now also remove the .pre file after collecting the catkeys.
Otherwise, Clang warns that we haven't set an architecture on ARM,
which is set in CCFLAGS. Since these might also contain other flags
that affect the preprocessor, there isn't any good reason to not
pass it through, so do that.
It seems that at on some platforms at least, Clang uses @define instead
of #define, but with functionally identical syntax, so use sed to
process it as such.
We lost these tunings when I moved us away from board focused
builds. I feel like most of our ARM interest is around ARMv7+
Change-Id: Ie301d275a74d48ee3d0c4c7dc7d6cdd635288a7b
This requires a trunk build of Clang (the flag was only implemented
& introduced 12 days ago), but at present, full builds will fail
due to an unrelated Clang bug: https://bugs.llvm.org/show_bug.cgi?id=38356
* __NO_INLINE__ fixes the cross-build on some glibc-based systems with
newer compilers, as it prevents glibc from declaring functions inline
that we override in libroot_build.
* We can now enable tree-vrp as long as no-delete-null-pointer-checks
goes where it used to.
The lowest model number supported by this driver is "3160", but that's just
Intel's insanity: the 7260 was released the quarter before it. So following
our naming convention strictly, "7260" is the correct name for this driver.
The firmware situation for this one is also a little different. Unlike past
instances where Intel has released mostly nonsubstantial firmware updates,
allowing us to just copy a recent-ish version from the iwlwifi archives,
the firmware is more closely tied to the driver in this series. As a result,
some of this firmware is not even used by Linux yet (they're a few versions
behind it seems), so the firmware packages included here come from FreeBSD.
One major hardware feature - RX of multiple frames at a time - is disabled
in this commit, as it depends on mbuf reference-counting, according to the
FreeBSD developers I asked, which we do not implement yet. I'll hopefully
get to looking at that in the next few weeks.
And with that, I finally have WiFi on my primary laptop, my original reason
for setting out on this quest last year. This commit was pushed through it,
even :)
This was accomplished by adding some pretty nasty hacks to the FFmpeg recipe
so that we can compile it for the GCC2 ABI using GCC7. This works because
GCC's C ABI has not changed between GCC2 and GCC7.
As a consequence of this, pretty much all the longstanding issues of the
ancient-and-still-miscompiled FFmpeg 0.10 are now completely gone.
Fixes#5080, #8461, #12696, #12436, #13981#13410, #13337.
Closes (possibly fixed earlier) #8605, #8511, #6984.
Probably fixes (couldn't test) #13989, #11974.
* Remove WifiFirmwareScriptData; the new mechanism is to use the script
to create a true package, and it also supports the offline downloading
this would have provided.
* Remove "FFMpeg"; never used -- the "ffmpeg" package is actually added
via BuildFeatures.
* Remove Bluetooth; now provided as part of the main Haiku package.
Also add AddHaikuImageSourcePackages invocations for all relevant
(i.e. [L]GPL'ed) packages.
Doesn't truly fix#9990 as PackageKit cannot be used to install source
packages, but this is enough for creating a redistributable image,
so that ticket can be moved out of the beta1 milestone now.
No functional change. Ideally we would create these via ResAttr like we do
the mail-providers, but these have attributes on their directories and not
just the files, so that will be slightly trickier, so for now just keep them
in their zip format.
* The if-case was appending to gccBaseFlags after the rest of the file
was done using it, so it was ineffective. Now we set it with the rest
of the baseFlags.
* We already pass no-integrated-as in configure, no need to do it in
MainBuildRules.
* B_USE_BUILTIN_ATOMIC_FUNCTIONS isn't used anymore, so get rid of it.
Most of the problems with tree-vrp stemmed from its deletion of null-pointer
checks (see linked commit in the source.) Now, GCC has a flag to control that,
and with it enabled I can boot to the desktop even with tree-vrp enabled.
Augustin Cavalier