| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
The issue is fixed in busybox.
|
| |
|
|
|
|
| |
gcc_gxx_include_dir loses its preceding slash if a non-null sysroot is set.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently, some indentation changed between versions 4.7.2 and 4.7.3 of GCC.
BusyBox patch "does not use the location information, but instead treats a hunk
as a sort of regex" (BusyBox 1.21.0 editors/patch.c:209). It ignores line
numbers and relies on context matching to find hunks to patch. Therefore,
changes to the context in the original file cause BusyBox patch to fail to apply
a hunk. Fuzz is fatal.
A patch needs to be refreshed when a new upstream version modifies its context.
Before:
/usr/src/gcc-4.7_4.7.3+sip1-1/tmp/src # patch -N -p 1 -u -i ../../patches/01_allow-more-dirs-to-be-configured.patch
patching file gcc/gcc.c
Hunk 2 FAILED 3688/3690.
PREFIX_PRIORITY_LAST, 0, 0);
}
+ add_prefix (&exec_prefixes,
+ concat (user_tooldir_prefix, dir_separator_str, NULL),
+ 0, PREFIX_PRIORITY_LAST, 0, 0);
+ add_prefix (&startfile_prefixes,
+ concat (user_tooldir_prefix, dir_separator_str, NULL),
+ 0, PREFIX_PRIORITY_LAST, 0, 0);
+ add_prefix (&include_prefixes,
+ concat (user_tooldir_prefix, dir_separator_str, NULL),
+ 0, PREFIX_PRIORITY_LAST, 0, 0);
+
/* COMPILER_PATH and LIBRARY_PATH have values
that are lists of directory names with colons. */
patching file gcc/Makefile.in
patching file libmudflap/Makefile.am
patching file libmudflap/Makefile.in
patching file libquadmath/Makefile.am
patching file libquadmath/Makefile.in
patching file libssp/Makefile.am
patching file libssp/Makefile.in
patching file libstdc++-v3/Makefile.am
patching file libstdc++-v3/Makefile.in
patching file Makefile.def
patching file Makefile.in
After:
/usr/src/gcc-4.7_4.7.3+sip1-1/tmp/src # patch -N -p 1 -u -i ../../patches/01_allow-more-dirs-to-be-configured.patch
patching file gcc/gcc.c
patching file gcc/Makefile.in
patching file libmudflap/Makefile.am
patching file libmudflap/Makefile.in
patching file libquadmath/Makefile.am
patching file libquadmath/Makefile.in
patching file libssp/Makefile.am
patching file libssp/Makefile.in
patching file libstdc++-v3/Makefile.am
patching file libstdc++-v3/Makefile.in
patching file Makefile.def
patching file Makefile.in
|
|
|
|
|
|
|
|
|
|
|
|
| |
GNU Patch can handle spaces between file names and dates, but BusyBox patch
requires tabs.
Fixes:
ob-applypatches: Applying patch "01_allow-more-dirs-to-be-configured.patch"...
patching file gcc/gcc.c 2013-04-25 21:16:04.893780032 -0400
patch: can't open 'gcc/gcc.c 2013-04-25 21:16:04.893780032 -0400': No such file or directory
ob-applypatches: Error: Can't apply patch "01_allow-more-dirs-to-be-configured.patch"
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GCC Internals manual (gcc/doc/fragments.texi) says:
> For configurations that support both multilib and multiarch,
> MULTILIB_OSDIRNAMES also encodes the multiarch name, thus subsuming
> MULTIARCH_DIRNAME.
>
[...]
>
> MULTIARCH_DIRNAME is not used for configurations that support both multilib
> and multiarch. In that case, multiarch names are encoded in
> MULTILIB_OSDIRNAMES instead.
This sounds like the makefile macro used depends on the build-time user
configuration; that is, the options --disable-multilib and --enable-multiarch
should cause MULTIARCH_DIRNAME to be used.
Instead, it seems MULTILIB_OSDIRNAMES is used, even if multilib is disabled. So
apparently, "configurations that support both" means GCC target configurations
that support both features, not build-time user configurations that enable them.
|
|
|
|
| |
This should add /usr/include/<target> to the include search list.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
For some reason, the --with-boot-ldflags option causes NEEDED references to
libstdc++.so.6 and libgcc_s.so.1 to be added to the DYNAMIC sections of gcc,
cpp, cc1, etc.
These options are only useful during the first stage of the bootstrap of the
first ProteanOS port, anyway, and they aren't strictly necessary even then.
|
|
|
|
| |
This is necessary for cross compilers, at least.
|
| |
|
|
|
|
| |
It's a development file, not a critical system file.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is a library to support Fortran programs, and we don't (yet?) build a
Fortran compiler.
|
| |
|
| |
|
|
|
|
| |
This unset the x bits in the modes of all of the shared objects.
|
| |
|
| |
|