upstream/opnsense-src
1
0
Fork 0
mirror of https://github.com/opnsense/src.git synced 2026-02-16 17:19:56 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
opnsense-src/gnu/usr.bin/binutils/Makefile.inc0

57 lines
1.3 KiB
Makefile
Raw Normal View History

Add bmakefiles for building binutils from the contrib tree. This finishes up the binutils import. But I am leaving it disabled in "src/gnu/usr.bin/Makefile" for now. It is not used by anything yet, so I'll take this opportunity to run one more round of tests before enabling it.
1998-03-01 18:41:17 -05:00
#
$Id$ -> $FreeBSD$
1999-08-27 19:37:10 -04:00
# $FreeBSD$
Add bmakefiles for building binutils from the contrib tree. This finishes up the binutils import. But I am leaving it disabled in "src/gnu/usr.bin/Makefile" for now. It is not used by anything yet, so I'll take this opportunity to run one more round of tests before enabling it.
1998-03-01 18:41:17 -05:00
#
#
# This is included explicitly at the top of each sub-Makefile. We can't
# use the normal "Makefile.inc" mechanism, because we need some of these
# definitions before the sub-Makefile is processed.
#
Upgrade to Binutils 2.10.1.
2000-11-15 16:29:55 -05:00
VERSION= 2.10.1
s/MACHINE_ARCH/TARGET_ARCH/g The target machine is represented by TARGET_ARCH. MACHINE_ARCH always represents the host machine. When TARGET_ARCH is not defined, it is assumed to be equal to MACHINE_ARCH. This means that we're building a native toolset by default. We're creating cross-compilation tools when MACHINE_ARCH != TARGET_ARCH. TARGET_ARCH is defined when building binutils as part of the bootstrap build and is set to reflect the architecture we're currently cross- building. With this change binutils is ready for cross-building.
1999-12-17 10:50:45 -05:00
TARGET_ARCH?= ${MACHINE_ARCH}
Add bmakefiles for building binutils from the contrib tree. This finishes up the binutils import. But I am leaving it disabled in "src/gnu/usr.bin/Makefile" for now. It is not used by anything yet, so I'll take this opportunity to run one more round of tests before enabling it.
1998-03-01 18:41:17 -05:00
s/MACHINE_ARCH/TARGET_ARCH/g The target machine is represented by TARGET_ARCH. MACHINE_ARCH always represents the host machine. When TARGET_ARCH is not defined, it is assumed to be equal to MACHINE_ARCH. This means that we're building a native toolset by default. We're creating cross-compilation tools when MACHINE_ARCH != TARGET_ARCH. TARGET_ARCH is defined when building binutils as part of the bootstrap build and is set to reflect the architecture we're currently cross- building. With this change binutils is ready for cross-building.
1999-12-17 10:50:45 -05:00
.if ${TARGET_ARCH} == "mipsel" || ${TARGET_ARCH} == "mipseb"
Add TARGET_ARCH=mipsel and TARGET_ARCH=mipseb as a valid targets. Unlike the unisex architecutres we've had so far, mips is bisexual. These tools can produce either byte sex, and the compiler/make determines the proper gender to use. Otherwise, we'd have to have had mipsel and mipseb in all the places that we have just mips. And there are other complications with doing that (binutils doesn't like to build mips tools without both byte genders, it seems). Introduced BINUTIL_ARCH so that other bisexual architectures can a generic mechanism. We cannot just define MACHINE_ARCH as mips because we need to differentiate big and little endian types of binaries. Discussions on freebsd-arch have hashed out this issue (and the parallel libc issues). NetBSD is moving towards mipsel and mipseb for their two flavors of mips ports (in time for 1.4, if this change hasn't already been accomplished). I've been building i386 worlds with this tree for a three months with these files in place with no ill effects.
1999-02-28 23:01:57 -05:00
BINUTIL_ARCH=mips
.else
s/MACHINE_ARCH/TARGET_ARCH/g The target machine is represented by TARGET_ARCH. MACHINE_ARCH always represents the host machine. When TARGET_ARCH is not defined, it is assumed to be equal to MACHINE_ARCH. This means that we're building a native toolset by default. We're creating cross-compilation tools when MACHINE_ARCH != TARGET_ARCH. TARGET_ARCH is defined when building binutils as part of the bootstrap build and is set to reflect the architecture we're currently cross- building. With this change binutils is ready for cross-building.
1999-12-17 10:50:45 -05:00
BINUTIL_ARCH=${TARGET_ARCH}
Add TARGET_ARCH=mipsel and TARGET_ARCH=mipseb as a valid targets. Unlike the unisex architecutres we've had so far, mips is bisexual. These tools can produce either byte sex, and the compiler/make determines the proper gender to use. Otherwise, we'd have to have had mipsel and mipseb in all the places that we have just mips. And there are other complications with doing that (binutils doesn't like to build mips tools without both byte genders, it seems). Introduced BINUTIL_ARCH so that other bisexual architectures can a generic mechanism. We cannot just define MACHINE_ARCH as mips because we need to differentiate big and little endian types of binaries. Discussions on freebsd-arch have hashed out this issue (and the parallel libc issues). NetBSD is moving towards mipsel and mipseb for their two flavors of mips ports (in time for 1.4, if this change hasn't already been accomplished). I've been building i386 worlds with this tree for a three months with these files in place with no ill effects.
1999-02-28 23:01:57 -05:00
.endif
Add bmakefiles for building binutils from the contrib tree. This finishes up the binutils import. But I am leaving it disabled in "src/gnu/usr.bin/Makefile" for now. It is not used by anything yet, so I'll take this opportunity to run one more round of tests before enabling it.
1998-03-01 18:41:17 -05:00
# RELTOP is the relative path to this point in the source or object
# tree, from any subdirectory of same. It gets extra "../" prefixes
# added to it as we descend into subdirectories.
RELTOP:= ..
Correct the Bintuils src path from the debugging version I accidently committed.
2000-11-15 17:05:00 -05:00
RELSRC= ${RELTOP}/../../../contrib/binutils
Add bmakefiles for building binutils from the contrib tree. This finishes up the binutils import. But I am leaving it disabled in "src/gnu/usr.bin/Makefile" for now. It is not used by anything yet, so I'll take this opportunity to run one more round of tests before enabling it.
1998-03-01 18:41:17 -05:00
SRCDIR= ${.CURDIR}/${RELSRC}
CFLAGS+= -D_GNU_SOURCE
# We use "-I-" because without it our yacc-generated parser tries to
# use GNU's bison-generated header files.
Restructure the binutils hierarchy somewhat in order to better support building it for variant architectures. It was already becoming clear that the former structure was too rigid and didn't scale well. The usual sort of makefile magic arranges to .include an architecture specific makefile "Makefile.${MACHINE_ARCH}" in each directory where it exists. Also, sources will be found in each subdirectory "${MACHINE_ARCH}" that exists. This is all taken care of automatically by the top level "Makefile.inc0". This all seems to work right for the i386 now. I have also converted those alpha pieces already present to the new schema as best I could. Also: change the BINDIR on the i386 to /usr/libexec/elf for "ar" and "ranlib". They are not object format independent enough to put into /usr/bin.
1998-03-11 21:55:43 -05:00
CFLAGS+= -I- -I.
Add TARGET_ARCH=mipsel and TARGET_ARCH=mipseb as a valid targets. Unlike the unisex architecutres we've had so far, mips is bisexual. These tools can produce either byte sex, and the compiler/make determines the proper gender to use. Otherwise, we'd have to have had mipsel and mipseb in all the places that we have just mips. And there are other complications with doing that (binutils doesn't like to build mips tools without both byte genders, it seems). Introduced BINUTIL_ARCH so that other bisexual architectures can a generic mechanism. We cannot just define MACHINE_ARCH as mips because we need to differentiate big and little endian types of binaries. Discussions on freebsd-arch have hashed out this issue (and the parallel libc issues). NetBSD is moving towards mipsel and mipseb for their two flavors of mips ports (in time for 1.4, if this change hasn't already been accomplished). I've been building i386 worlds with this tree for a three months with these files in place with no ill effects.
1999-02-28 23:01:57 -05:00
.if exists(${.CURDIR}/${BINUTIL_ARCH})
CFLAGS+= -I${.CURDIR}/${BINUTIL_ARCH}
Restructure the binutils hierarchy somewhat in order to better support building it for variant architectures. It was already becoming clear that the former structure was too rigid and didn't scale well. The usual sort of makefile magic arranges to .include an architecture specific makefile "Makefile.${MACHINE_ARCH}" in each directory where it exists. Also, sources will be found in each subdirectory "${MACHINE_ARCH}" that exists. This is all taken care of automatically by the top level "Makefile.inc0". This all seems to work right for the i386 now. I have also converted those alpha pieces already present to the new schema as best I could. Also: change the BINDIR on the i386 to /usr/libexec/elf for "ar" and "ranlib". They are not object format independent enough to put into /usr/bin.
1998-03-11 21:55:43 -05:00
.endif
CFLAGS+= -I${.CURDIR}
Add TARGET_ARCH=mipsel and TARGET_ARCH=mipseb as a valid targets. Unlike the unisex architecutres we've had so far, mips is bisexual. These tools can produce either byte sex, and the compiler/make determines the proper gender to use. Otherwise, we'd have to have had mipsel and mipseb in all the places that we have just mips. And there are other complications with doing that (binutils doesn't like to build mips tools without both byte genders, it seems). Introduced BINUTIL_ARCH so that other bisexual architectures can a generic mechanism. We cannot just define MACHINE_ARCH as mips because we need to differentiate big and little endian types of binaries. Discussions on freebsd-arch have hashed out this issue (and the parallel libc issues). NetBSD is moving towards mipsel and mipseb for their two flavors of mips ports (in time for 1.4, if this change hasn't already been accomplished). I've been building i386 worlds with this tree for a three months with these files in place with no ill effects.
1999-02-28 23:01:57 -05:00
CFLAGS+= -I${.CURDIR}/${RELTOP}/libbfd/${BINUTIL_ARCH}
Add bmakefiles for building binutils from the contrib tree. This finishes up the binutils import. But I am leaving it disabled in "src/gnu/usr.bin/Makefile" for now. It is not used by anything yet, so I'll take this opportunity to run one more round of tests before enabling it.
1998-03-01 18:41:17 -05:00
CFLAGS+= -I${SRCDIR}/include
Restructure the binutils hierarchy somewhat in order to better support building it for variant architectures. It was already becoming clear that the former structure was too rigid and didn't scale well. The usual sort of makefile magic arranges to .include an architecture specific makefile "Makefile.${MACHINE_ARCH}" in each directory where it exists. Also, sources will be found in each subdirectory "${MACHINE_ARCH}" that exists. This is all taken care of automatically by the top level "Makefile.inc0". This all seems to work right for the i386 now. I have also converted those alpha pieces already present to the new schema as best I could. Also: change the BINDIR on the i386 to /usr/libexec/elf for "ar" and "ranlib". They are not object format independent enough to put into /usr/bin.
1998-03-11 21:55:43 -05:00
Add TARGET_ARCH=mipsel and TARGET_ARCH=mipseb as a valid targets. Unlike the unisex architecutres we've had so far, mips is bisexual. These tools can produce either byte sex, and the compiler/make determines the proper gender to use. Otherwise, we'd have to have had mipsel and mipseb in all the places that we have just mips. And there are other complications with doing that (binutils doesn't like to build mips tools without both byte genders, it seems). Introduced BINUTIL_ARCH so that other bisexual architectures can a generic mechanism. We cannot just define MACHINE_ARCH as mips because we need to differentiate big and little endian types of binaries. Discussions on freebsd-arch have hashed out this issue (and the parallel libc issues). NetBSD is moving towards mipsel and mipseb for their two flavors of mips ports (in time for 1.4, if this change hasn't already been accomplished). I've been building i386 worlds with this tree for a three months with these files in place with no ill effects.
1999-02-28 23:01:57 -05:00
.if exists(${.CURDIR}/${BINUTIL_ARCH})
.PATH: ${.CURDIR}/${BINUTIL_ARCH}
Restructure the binutils hierarchy somewhat in order to better support building it for variant architectures. It was already becoming clear that the former structure was too rigid and didn't scale well. The usual sort of makefile magic arranges to .include an architecture specific makefile "Makefile.${MACHINE_ARCH}" in each directory where it exists. Also, sources will be found in each subdirectory "${MACHINE_ARCH}" that exists. This is all taken care of automatically by the top level "Makefile.inc0". This all seems to work right for the i386 now. I have also converted those alpha pieces already present to the new schema as best I could. Also: change the BINDIR on the i386 to /usr/libexec/elf for "ar" and "ranlib". They are not object format independent enough to put into /usr/bin.
1998-03-11 21:55:43 -05:00
.endif
Change CROSS_TOOLS to CROSS_ARCH because that makes more sense. Allow for the case where the host architecture might also be listed in CROSS_ARCH, so don't do things twice. This situation can arise if you want NT support in binutils (CROSS_ARCH=i386 CROSS_FORMAT=winnt).
1999-11-06 16:13:47 -05:00
ARCHS= ${BINUTIL_ARCH}
.for _arch in ${CROSS_ARCH}
.if (${ARCHS:R:M${_arch:R}} == "")
ARCHS+=$(_arch)
.endif
.endfor
Add makefile support for cross-architectures. Allow CROSS_TOOLS to be defined (in /etc/make.conf, say) and set to the additional architectures that need to be compiled in. So on alpha I set CROSS_TOOLS = i386. On i386 you can't build alpha due to lack of 64-bit support on 32-bit architectures, but that's a GNU problem. This change relies on makefiles in the binutils sub-directories having the extension defined in the CROSS_TOOLS, instead of those makefiles being selected based on the host architecture.
1998-05-04 17:10:56 -04:00
.for _arch in ${ARCHS}
.if exists(${.CURDIR}/Makefile.${_arch})
.include "${.CURDIR}/Makefile.${_arch}"
Restructure the binutils hierarchy somewhat in order to better support building it for variant architectures. It was already becoming clear that the former structure was too rigid and didn't scale well. The usual sort of makefile magic arranges to .include an architecture specific makefile "Makefile.${MACHINE_ARCH}" in each directory where it exists. Also, sources will be found in each subdirectory "${MACHINE_ARCH}" that exists. This is all taken care of automatically by the top level "Makefile.inc0". This all seems to work right for the i386 now. I have also converted those alpha pieces already present to the new schema as best I could. Also: change the BINDIR on the i386 to /usr/libexec/elf for "ar" and "ranlib". They are not object format independent enough to put into /usr/bin.
1998-03-11 21:55:43 -05:00
.endif
Add makefile support for cross-architectures. Allow CROSS_TOOLS to be defined (in /etc/make.conf, say) and set to the additional architectures that need to be compiled in. So on alpha I set CROSS_TOOLS = i386. On i386 you can't build alpha due to lack of 64-bit support on 32-bit architectures, but that's a GNU problem. This change relies on makefiles in the binutils sub-directories having the extension defined in the CROSS_TOOLS, instead of those makefiles being selected based on the host architecture.
1998-05-04 17:10:56 -04:00
.endfor
Reference in a new issue Copy permalink