FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-01-2012, 11:48 PM
Richard Yao
 
Default 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?
 
Old 07-02-2012, 12:21 AM
Richard Yao
 
Default freebsd.eclass change

There is a small error in this. It should be 's/return/echo/'.

On 07/01/2012 07:48 PM, Richard Yao 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?
>
 
Old 07-02-2012, 08:41 AM
Sergei Trofimovich
 
Default freebsd.eclass change

On Sun, 01 Jul 2012 20:21:00 -0400
Richard Yao <ryao@gentoo.org> wrote:

> > + local arch=$(uname -m)
> > + case $(uname -m) in

I guess you have created 'local arch=' for a reason.

[no idea where you plan to use it, but] 'uname -m'
is fragile in croscompiler environments which you
seem to have touched in description.

'uname -m' usually breaks when you chroot to 32bits
on amd64 and don't use 'linux32 chroot'.

But again, I have no idea what MACHINE_CPUARCH is.
Switch based on ${ARCH} or ${CHOST} and overridable
by ${CTARGET} might fit you more.

--

Sergei
 
Old 07-02-2012, 02:54 PM
Alexis Ballier
 
Default freebsd.eclass change

On Sun, 1 Jul 2012 19:48:58 -0400
Richard Yao <ryao@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.
 
Old 07-02-2012, 05:37 PM
Richard Yao
 
Default 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.
 
Old 07-02-2012, 06:02 PM
Mike Frysinger
 
Default 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
 
Old 07-02-2012, 06:09 PM
Richard Yao
 
Default 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.
 
Old 07-03-2012, 09:48 PM
Alexis Ballier
 
Default freebsd.eclass change

On Mon, 02 Jul 2012 14:09:26 -0400
Richard Yao <ryao@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.
 

Thread Tools




All times are GMT. The time now is 06:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org