Flex is not needed, and creates some confusion when building the
binutils on Haiku. Just remove all the checks from the configure script,
so it is never used.
This aligns legacy gcc with the changes to gcc4 committed in 4192115 and
the two subsequent commits. It also disables legacy ld's default
behaviour of recursively resolving shared-library dependencies at link
time, preventing missing-library warnings during the build and aligning
ld's behaviour with that of more recent versions.
gcc2:
* CPP_SPEC: Replace non-existent command-line options with valid
equivalents.
* CC1_SPEC: Remove non-existent "no-fpic" option; add "fno-pic" and
"fno-PIC" as options that disable the generation of
position-independent code; use "-fPIC" by default.
* LINK_SPEC: Pass "-shared" to the linker only if it was passed to gcc;
output position-independent executables by default, exporting all
symbols to match the behaviour of "-shared"; when building a
dynamically linked executable, do not recursively add shared libraries
as dependencies but do allow unresolved symbols in them; specify
"-Bsymbolic" only when building a shared library.
* All: Wrap lines at 80 columns; use more compact notation where
available.
ld:
* Do not recursively resolve shared-library dependencies when building
an executable if the "--no-add-needed" and "--allow-shlib-undefined"
options are in effect. This effectively backports binutils commits
8fbb09e and 4706eab.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
* remove all *.info targets so the gcc2 build system doesn't
try to update them, as that doesn't always work because of
apparent incompatibilities with newer makeinfo versions
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@42999 a95241bf-73f2-0310-859d-f6bbb57e9c96
(cherry picked from commit 32fb726909)
using /boot/system, /boot/common and /boot/home/config
as packagefs mount-points)
git-svn-id: file:///srv/svn/repos/haiku/buildtools/branches/package-management@40804 a95241bf-73f2-0310-859d-f6bbb57e9c96
Why did I even consider running the current autotools against almost two
years old code? Of course it wouldn't work.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24518 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Rebuilt the build system using the patched automake/-conf/libtool.
* Didn't touch ltconfig, libtool.m4, and lt-*. They look somehow
obsolete. Need to recheck later.
NOTE: Those changes are untested yet. Don't update!
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24508 a95241bf-73f2-0310-859d-f6bbb57e9c96
except one: the binaries produced by this version of binutils crashes the loader of
BeOS versions BONE, Dano (and probably Zeta, too). That's a pity, but I currently
do not know how to fix this (as the fix available for older versions of binutils
does not work anymore).
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@20192 a95241bf-73f2-0310-859d-f6bbb57e9c96
except one: the binaries produced by this version of binutils crashes the loader of
BeOS versions BONE, Dano (and probably Zeta, too). That's a pity, but I currently
do not know how to fix this (as the fix available for older versions of binutils
does not work anymore).
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@20191 a95241bf-73f2-0310-859d-f6bbb57e9c96
