| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Fixes:
gpg: assuming signed data in 'gcc-8.3.0.tar.xz'
|
| |
|
| |
|
| |
|
|
|
|
| |
Upstream no longer offers bzip2.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
In a control file, a "#" character only begins a comment at the start of
a line.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
They should be enabled again sometime after the first two architecture
ports are bootstrapped.
|
| |
|
| |
|
|
|
|
| |
These take a rather long time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was causing errors due to an unquoted argument to the test utility:
Checking multilib configuration for libgcc...
/bin/bash: line 0: test: !=: unary operator expected
make[5]: Entering directory `/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/obj-core-linux-eglibc/x86_64-unknown-linux-gnu/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/obj-core-linux-eglibc/./gcc/xgcc -B/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/obj-core-linux-eglibc/./gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/lib/ -isystem /usr/x86_64-unknown-linux-gnu/include -isystem /usr/x86_64-unknown-linux-gnu/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -I. -I. -I../.././gcc -I/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/src/libgcc -I/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/src/libgcc/. -I/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/src/libgcc/../gcc -I/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/src/libgcc/../include -I/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/src/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/src/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/include/features.h:341:0,
from /usr/include/stdio.h:27,
from /root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/src/libgcc/../gcc/tsystem.h:88,
from /root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/src/libgcc/libgcc2.c:29:
/usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory
compilation terminated.
make[5]: *** [_muldi3.o] Error 1
make[5]: Leaving directory `/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/obj-core-linux-eglibc/x86_64-unknown-linux-gnu/libgcc'
make[4]: *** [all-stage1-target-libgcc] Error 2
make[4]: Leaving directory `/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/obj-core-linux-eglibc'
make[3]: *** [stage1-bubble] Error 2
make[3]: Leaving directory `/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/obj-core-linux-eglibc'
make[2]: *** [bootstrap-lean] Error 2
make[2]: Leaving directory `/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp/obj-core-linux-eglibc'
make[1]: *** [buildnative-core-linux-eglibc] Error 2
make[1]: Leaving directory `/root/ports/core-linux-eglibc_2013-12-07/pkg/gcc-4.7/tmp'
make: *** [build-core-linux-eglibc] Error 2
Command exited with non-zero status 1
The "unary operator expected" error seems to be caused by this line
(libgcc/Makefile.in:291):
MULTIOSSUBDIR := $(shell if test $(MULTIOSDIR) != .; then echo /$(MULTIOSDIR); fi)
|
| |
|
|
|
|
| |
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.
|