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.
On GCC 7.3, it conflicts with our definition of 'fork'. The documentation
states that disabling builtins has no effect on versions where they
do not exist, so we don't need to check for GCC7 here.
Previously they just silently continued, which meant that if part of the
cross-tools build failed, you would have to scroll back pretty far to
see what the failure was.
* The ram_disk driver was missing in the bootstrap images. Adding
it will allow the ramdisk command to work. And with a modified
haikuports.conf one might even use a ramdisk TREE_PATH.
* The virtio_net driver will probably be handy in some situations.
git_svn needs alien_svn, but we don't include this in the build repos.
Remove it from the preinstalled software, it is available in the depot
if people need it.
John's revert of my removal commit dragged back a bunch of cygwin/sunos
cruft, as well as re-adding RegExp.cpp to the host libshared, that we don't
need.
Instead, remove this and add libgnuregex_build to just the tools/keymap
link alongside the FreeBSD gnuregex case.
Following recent changes to use libroot_build on Haiku also, it is now
actually impossible to build Haiku components on non-Haiku platforms
(BeOS R5, Dan0, BONE, Zeta), so we can remove any logic related to this.
This is only the first part; still to be removed are:
* SetSubDirSupportedPlatformsBeOSCompatible
* HOST_PLATFORM_BEOS_COMPATIBLE
* TARGET_PLATFORM_BEOS_COMPATIBLE
To quote jscipione (from 95e8362c52),
"Let me tell you a story about a bug" -- though this tale spans a much
lesser time than that one did.
In 5e19679ea3, I enabled libroot_build for
Haiku, instead of using the system libroot as we had before. There were
a number of bugs introduced along with this that I hadn't fixed (and there
may be more after this), but most of the obvious ones (crashes on x86_64...)
were fixed shortly enough.
Attribute usage, though, was a different story. Unlike most of the POSIX
calls in libroot, which were aliasing system functions no matter what the
platform, the attribute calls were not, as they are specific to Haiku.
Initially I had completely forgot about them, and it wasn't until a few days
later when I noticed that I had an "attributes" directory in my generated
that I realized that the "generic" attribute layer was being used on Haiku.
I attempted a fix for this in 5e19679ea3,
thinking that would clear the problem up, but I didn't actually run a test
beyond seeing that my BuildConfig had been updated properly. In fact,
BuildSetup was hard-wired to not even pass that definition through on
Haiku, and so that commit had in effect caused nothing.
My initial "fix" of just changing BuildSetup then caused a build failure,
as while libroot_build itself compiled, it ran into errors whenever attributes
were used, because in letting the real libroot's attribute calls shine
through, I had bypassed libroot_build's FD emulation/shim layer.
Then I tried and failed at three separate attempts to solve this with code:
- a version of the "fs_attr_...h" interface for Haiku. This proved possible
in theory, but in practice I would need to reimplement a lot of attribute
handling code in it, because all I had access to from there was syscalls.
- a version of "fs_attr_untyped" that bypassed its reimplementations of
the "fs*attr" functions for the libroot ones, only using the FD shim layer.
This proved possibly not even theoretically possible because it would have
caused preprocessor hell in some of the build headers, and also assumptions
about how attributes are read were totally different.
- a completely new "fs_attr_haiku" that was a completely new interface to
the fs*attr functions. This proved practically impossible because of the
need to include structures from the system libroot to call out to readdir,
etc. that attempts to solve would also have caused preprocessor hell.
Then I realized that the Linux xattr emulation library, which I'd used
as a reference when attempting the first solution, was shipped by default
as a system library in all builds of Haiku ... and so I could just tell
fs_attr_untyped to use the Linux xattr handler, and then link against libgnu.
So that is how I arrived at this strange and decidedly unorthodox solution
to a problem of my own creation.
Per #10267, "Most (ported) third-party software should be removed
from the Haiku source repository."
Since HaikuPorts already has the ncompress package, this file
should no longer exist.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Original patch missed modifying the "minimum" definition and the
src/bin/Jamfile, so I took care of that.
- Recent changes to the build system appear to make the assumption
that the GNU regex APIs are universally available. This isn't the
case on FreeBSD, which requires libgnuregex to provide that
functionality. This broke the host keymap build.
gnuefi package was replaced by gnu_efi_kernel, but build
was not updated. This is guesswork, as I couldn't track down what changed.
It finds headers, headers_arch and lib and works so should be ok.
It was needed on macOS for a time when BUrl used regexes for parsing.
Now it does not, and so we can remove libshared's RegExp from build
libshared, and thus also libgnuregex.
I wrote this back in 2010 as my first driver project.
Reasons to remove it:
* The license is GPL
* Current WiMAX hardware is generally WIFI based.
* It controlled the hardware, but never worked
for network access since we need SSL certs and stuff
which vendors weren't too open with.
* WiMAX kind of died (at least in the US)
I left the wwan directory, it would be a nice spot
for CDMA / GSM dongle drivers.
Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)
The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.
Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
Previously --update was kind of a hack, as it just dumped all
the variables from BuildConfig back into ./configure and attempted
to rerun from there.
Instead, now we store all of the variables and environs configure
was invoked with in the top of BuildConfig and re-call it using them.
This is much more robust, as configure will actually recompute
all of the values from the BuildConfig.
As a side effect, if configure was originally invoked to build crosstools,
it would have done so again, so instead add a check to see if they
exist, and skip them if they do. It's easy enough to delete the
directory if you want to force a crosstools rebuild.
Briefly discussed with mmlr on IRC.
Instead build the one in-tree from src/data/package_infos/. Fixes the
"HaikuPorts repos have wrong URL" problem that has occured since the
switch to buildmaster repos.
When compiling with GCC, these headers get pulled in from the
gcc_syslibs_devel package, but we cannot do something similar
for Clang as Clang adds/removes internal builtins used by
the headers nearly every version. So instead we just copy
all the intrinsics headers from current Clang into generated,
and make sure this directory is included before any others.
* Actually locate the clang executable, and allow user overrides
* Properly preserve arguments in get_build_tool_path
* Fix get_build_tool_path for commands with dashes (e.g. "clang-5.0")
* Update repository file to hardlink_packages modified one.
* Add some basic process overview to directory.
* We don't normally document in paths, but this stuff is complex.
* Documentation improvements welcome.
