* Uses newer revision of buildtools
* Fetches a tarball now instead of checking out from Git
-> Should be faster
-> Allows verification of the download
This allows gcc to pass response files directly to LD, allowing to build
WebKit libraries using them without hitting command-line length limit.
Also REQUIRES binutils at the proper version, as using binutils 2.17 with
gcc4 isn't working (as doesn't understand some directives).
* Use current source revision.
* Copy and paste error in INSTALL(): installDir was used instead of
gccInstallDir. Notsure why the bootstrap recipe and this one use
different variable names.
* Fix stdc++ library symlink when built for secondary architecture.
The directory layout has changed similarly to that of the gcc 2 couple,
i.e. we install in develop/tools[/<arch>] instead of separate
subdirectories, so gcc finds the matching gas and ld.
Only tested the secondary architecture build so far.
* The files are no longer installed in a separate develop/tools
subdirectory for binutils and one for gcc. Instead we install
directly in develop/tools[/<arch>]. This allows gcc to find gas and
ld via its built-in search instead of via PATH only. In a hybrid
setup this makes a difference, when the gcc that is not the first in
PATH is invoked directly (e.g. via absolute path).
* Add support for building for the secondary architecture. Not tested
yet.
* Fix incorrect gccDate.
* For the source package only export legacy/gcc.
* architecture -> targetArchitecture
* Add missing provides for c++filt and i586-pc-haiku-gcc.
* strip debug info from all binaries
* based on architecture, decide whether or not to link the tools into
the default path
* use relative symlinks instead of absolute ones, as the latter won't work
when building gcc with itself (in which case the .self-symlink in the
/packages folder will point to the packaging path, where no binaries
exist yet)
available via standard paths. This makes only sense for the default compiler,
but we currently can't tell haikuporter if the one being built is such a
beast.
I suppose we need some kind of feature mechanism for ports in order to be
able to enable/disable stuff like this from the outside.
be declared properly, now
* improve formatting of recipe files for better readability and better
compatibility with showing diffs (when moving specification lines)
* add/improve DESCRIPTION where it was just a copy of SUMMARY
* there's no cmd:binutils, it's just a package
* there's no cmd:texinfo, it's just a package
Later, all the required commands should be put here
instead of requiring packages.
* Also declare a resolvable named like the package, even if
similarly named cmd:* resolvable is declared.
* Add cmd: namespace to resolvables in [BUILD_[PRE]]REQUIRES
where appropriate. For some reason I thought that didn't
work (resulting in an error building the package), but
apparently I was mistaken.
* A few smaller fixes in [BUILD_[PRE]]REQUIRES.
Oliver Tappe