Re: [gentoo-dev] freebsd.eclass change
On Mon, 02 Jul 2012 14:09:26 -0400
Richard Yao r...@gentoo.org wrote:
On 07/02/2012 02:02 PM, Mike Frysinger wrote:
On Monday 02 July 2012 13:37:53 Richard Yao wrote:
On 07/02/2012 10:54 AM, Alexis Ballier wrote:
hu? yes, as already pointed out, uname is not reliable when
cross-compiling. You should use CHOST, and then you get
tc-arch-kernel. See freebsd-lib ebuild for how it is handled.
In that case, it should be 'local arch=$(tc-arch-kernel)'. Using
tc-arch-kernel by itself causes problems when building on Linux,
because x86 can be passed, which FreeBSD's build system does not
understand.
the function specifically handles freebsd in this case. why isn't
that code sufficient ?
Also, this function is not meant for cross compilation.
then it doesn't really belong in the tree. native builds are just
a special case of cross-compiling.
-mike
The idea is to use this to assist in building parts of FreeBSD on
Linux for Linux (or on Prefix for whatever platform it runs). Anyway,
I will keep this in ebuilds until it has several ebuilds using it.
Then we can revisit it.
you probably want something like:
tc-arch-kernel ${CHOST%%-*}-gentoo-freebsd9.0
then
we do not really care about the version suffix in tc-arch functions, so
you can also omit it.
A.
Re: [gentoo-dev] freebsd.eclass change
On Sun, 1 Jul 2012 19:48:58 -0400
Richard Yao r...@cs.stonybrook.edu wrote:
I want to add freebsd_get_cpuarch() to freebsd.eclass. This will give
us a platform-independent way of generating MACHINE_CPUARCH, which
will make building FreeBSD components on other platforms (i.e. Linux
and Prefix) easier.
--- freebsd.eclass.old 2012-07-01 19:15:56.157277000 -0400
+++ freebsd.eclass 2012-07-01 19:44:08.093698000 -0400
@@ -58,6 +58,24 @@ freebsd_get_bmake() {
echo ${bmake}
}
+freebsd_get_cpuarch() {
+ local arch=$(uname -m)
+ case $(uname -m) in
+ x86_64)
+ return 'amd64';;
+ arm*)
+ return 'arm';;
+ i?86)
+ return 'i386';;
+ ppc*)
+ return 'powerpc';;
+ mips*)
+ return 'mips';;
+ sparc*)
+ return 'sparc';;
+ *)
+ return arch;
+ esac
+}
+
freebsd_do_patches() {
if [[ ${#PATCHES[@]} -gt 1 ]] ; then
for x in ${PATCHES[@]}; do
Does anyone have any objections?
hu? yes, as already pointed out, uname is not reliable when
cross-compiling. You should use CHOST, and then you get tc-arch-kernel.
See freebsd-lib ebuild for how it is handled.
A.
Re: [gentoo-dev] freebsd.eclass change
On 07/02/2012 10:54 AM, Alexis Ballier wrote: hu? yes, as already pointed out, uname is not reliable when cross-compiling. You should use CHOST, and then you get tc-arch-kernel. See freebsd-lib ebuild for how it is handled. A. In that case, it should be 'local arch=$(tc-arch-kernel)'. Using tc-arch-kernel by itself causes problems when building on Linux, because x86 can be passed, which FreeBSD's build system does not understand. Also, this function is not meant for cross compilation. I have been working on building sys-freebsd/boot0 on Linux, which is one place where this is useful. Once it builds properly, I plan to patch it so that it can boot Linux and then have a discussion to decide how these changes will be merged into the main tree (i.e. as sys-freebsd/boot0-r1 or as sys-boot/boot0-linux). Being able to get the appropriate MACHINE_ARCH/MACHINE_CPUARCH values is part of that. It seemed useful enough that I felt it belonged in the eclass. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] freebsd.eclass change
On Monday 02 July 2012 13:37:53 Richard Yao wrote: On 07/02/2012 10:54 AM, Alexis Ballier wrote: hu? yes, as already pointed out, uname is not reliable when cross-compiling. You should use CHOST, and then you get tc-arch-kernel. See freebsd-lib ebuild for how it is handled. In that case, it should be 'local arch=$(tc-arch-kernel)'. Using tc-arch-kernel by itself causes problems when building on Linux, because x86 can be passed, which FreeBSD's build system does not understand. the function specifically handles freebsd in this case. why isn't that code sufficient ? Also, this function is not meant for cross compilation. then it doesn't really belong in the tree. native builds are just a special case of cross-compiling. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] freebsd.eclass change
On 07/02/2012 02:02 PM, Mike Frysinger wrote: On Monday 02 July 2012 13:37:53 Richard Yao wrote: On 07/02/2012 10:54 AM, Alexis Ballier wrote: hu? yes, as already pointed out, uname is not reliable when cross-compiling. You should use CHOST, and then you get tc-arch-kernel. See freebsd-lib ebuild for how it is handled. In that case, it should be 'local arch=$(tc-arch-kernel)'. Using tc-arch-kernel by itself causes problems when building on Linux, because x86 can be passed, which FreeBSD's build system does not understand. the function specifically handles freebsd in this case. why isn't that code sufficient ? Also, this function is not meant for cross compilation. then it doesn't really belong in the tree. native builds are just a special case of cross-compiling. -mike The idea is to use this to assist in building parts of FreeBSD on Linux for Linux (or on Prefix for whatever platform it runs). Anyway, I will keep this in ebuilds until it has several ebuilds using it. Then we can revisit it. signature.asc Description: OpenPGP digital signature
[gentoo-dev] freebsd.eclass change
I want to add freebsd_get_cpuarch() to freebsd.eclass. This will give us
a platform-independent way of generating MACHINE_CPUARCH, which will
make building FreeBSD components on other platforms (i.e. Linux and
Prefix) easier.
--- freebsd.eclass.old 2012-07-01 19:15:56.157277000 -0400
+++ freebsd.eclass 2012-07-01 19:44:08.093698000 -0400
@@ -58,6 +58,24 @@ freebsd_get_bmake() {
echo ${bmake}
}
+freebsd_get_cpuarch() {
+ local arch=$(uname -m)
+ case $(uname -m) in
+ x86_64)
+ return 'amd64';;
+ arm*)
+ return 'arm';;
+ i?86)
+ return 'i386';;
+ ppc*)
+ return 'powerpc';;
+ mips*)
+ return 'mips';;
+ sparc*)
+ return 'sparc';;
+ *)
+ return arch;
+ esac
+}
+
freebsd_do_patches() {
if [[ ${#PATCHES[@]} -gt 1 ]] ; then
for x in ${PATCHES[@]}; do
Does anyone have any objections?
signature.asc
Description: OpenPGP digital signature
