Bruno van Dooren | 15 Oct 2005 12:05
Picon
Favicon

Re: SMP in Haiku?

Congratulations Axel.
it is good to know that haiku-os has you as an employed developer.

good luck,
    Bruno.

----- Original Message ----- 
From: "Axel Dörfler" <axeld@...>
To: <openbeos@...>
Sent: Tuesday, September 20, 2005 10:33 PM
Subject: [openbeos] Re: SMP in Haiku?

> Joe Bushong <joe.bushong@...> wrote:
>> What is the status of using Haiku on a multi CPU box?
>
> SMP support is currently disabled - Haiku should run on SMP boxes, but
> it will only use the first CPU for now. I'll plan to fix that in the
> upcoming weeks, and it will definitely support SMP in R1.
>
> Bye,
>   Axel.
>
>
> 

Mathew Schofield | 17 Oct 2005 09:51
Picon

Cross Compiling Haiku on Another OS

Hi,

Lately i have been trying to cross compile Haiku on something other then BeOS.

So far i have managed to patch and compile a cross-compiler with BeOS i586 as the target, and FreeBSD i386 as the host.

The compiler *appears* to work, and i have just tested this with a simple "Hello World" program.

However i cannot compile any Haiku components due to errors in the BeOS headers. I don't understand why, but i get wierd errors that dont appear when compiling on BeOS, such as:

"headers/cpp/stl_alloc.h:710: error: expected constructor, destructor, or type conversion before '*' token"

I think this, and most of my problems, is/are due to this error:

cc1plus: warning: command line option "-Wmissing-prototypes" is valid for C/ObjC but not for C++


So,
Does anyone know about this, of this, or otherwise?
Is it related to the fact that my cross compiler is probably shoty/craptacular?
Has anyone built a toolchain for Linux (Or anything else for that matter)?

--
Thank You
Mathew Schofield
mr.skoe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Axel Dörfler | 17 Oct 2005 10:19
Picon

Re: Cross Compiling Haiku on Another OS

Mathew Schofield <mr.skoe@...> wrote:
> Does anyone know about this, of this, or otherwise?
> Is it related to the fact that my cross compiler is probably
> shoty/craptacular?
> Has anyone built a toolchain for Linux (Or anything else for that 
> matter)?

Our current build system was not supposed to work on anything else but 
BeOS. It is currently being revamped by Ingo Weinhold in a separate 
branch - you could either use this version, or wait until Ingo merges 
his changes back. Making Haiku mostly independent from the build 
platform was the main reason for this work.
AFAICT the new build system is pretty advanced already, and Ingo is 
just waiting for me to make his life in merging the changes back a bit 
harder (ie. let me commit more changes).

Bye,
   Axel.

Ingo Weinhold | 17 Oct 2005 12:46
Picon

Re: Cross Compiling Haiku on Another OS


On 2005-10-17 at 10:19:57 [+0200], Axel Dörfler wrote:
> Mathew Schofield <mr.skoe@...> wrote:
> > Does anyone know about this, of this, or otherwise?
> > Is it related to the fact that my cross compiler is probably
> > shoty/craptacular?
> > Has anyone built a toolchain for Linux (Or anything else for that
> > matter)?
> 
> Our current build system was not supposed to work on anything else but
> BeOS. It is currently being revamped by Ingo Weinhold in a separate
> branch - you could either use this version, or wait until Ingo merges
> his changes back. Making Haiku mostly independent from the build
> platform was the main reason for this work.

Yep, if you like, you can check out the branch 
(haiku/branches/team/build/build_system_redesign). It is supposed to be 
able to build a Haiku image from the sources under Linux. There's a script 
included that builds the cross compilation tools from the sources 
(build/scripts/build_cross_tools) and you have to specify them for the 
configure script (--cross-tools-prefix, see --help).

The build system won't work on *BSDs yet, mainly because they haven't been 
added as target yet. If you want to give it a try you can grep the 
configure script and the build system files in build/jam/* for "linux" and 
add respective stuff for your favorite *BSD.

> AFAICT the new build system is pretty advanced already, and Ingo is
> just waiting for me to make his life in merging the changes back a bit
> harder (ie. let me commit more changes).

Er, not quite. :-) There are still a few things to be done, which otherwise 
would annoy some of our contributors, and ATM real life is interfering a 
bit...

CU, Ingo

Mathew Schofield | 18 Oct 2005 03:02
Picon

Re: Cross Compiling Haiku on Another OS

Yep, if you like, you can check out the branch
(haiku/branches/team/build/build_system_redesign). It is supposed to be
able to build a Haiku image from the sources under Linux. There's a script
included that builds the cross compilation tools from the sources
(build/scripts/build_cross_tools) and you have to specify them for the
configure script (--cross-tools-prefix, see --help).
The build system won't work on *BSDs yet, mainly because they haven't been
added as target yet. If you want to give it a try you can grep the
configure script and the build system files in build/jam/* for "linux" and
add respective stuff for your favorite *BSD.

Thanks, I'll have to give it a try, anyway.
 
Should i copy the contents of the new build system into the trunk folder, or should i just run it from where it is?

--
Thank You
Mathew Schofield
mr.skoe <at> gmail.com
Jonas Sundström | 18 Oct 2005 08:56
Picon

Re: Cross Compiling Haiku on Another OS

Ingo Weinhold <bonefish@...> wrote:
 ...
> Yep, if you like, you can check out the branch 
> (haiku/branches/team/build/build_system_redesign).
> It is supposed to be able to build a Haiku image 
> from the sources under Linux.

Are you planning to support cross-compiling to AMD64,
PPC64/CELL, etc?

(I do realize there's an Eiffel Tower of work there.)

Anyway. You guys rock. 

*re-lurks*

/Jonas Sundström.              www.kirilla.com

To lurk or to lurch. Decisions, decisions.

Axel Dörfler | 18 Oct 2005 10:18
Picon

Re: Cross Compiling Haiku on Another OS

Mathew Schofield <mr.skoe@...> wrote:
> > Yep, if you like, you can check out the branch
> > (haiku/branches/team/build/build_system_redesign). It is supposed 
> > to be
[...]
>  Should i copy the contents of the new build system into the trunk 
> folder,
> or should i just run it from where it is?

Have a look at:
http://svnbook.red-bean.com/en/1.1/ch04s05.html

When working with branches, you "just" exchange the SVN repository 
location - and then an ordinary update will download the branch.

Bye,
   Axel.

Zenja Solaja | 23 Oct 2005 05:01
Picon

Performance question - BList vs STL list

Hi.  Just a quick question about possible performance issues for a project I'm working on.  Given a choice between the SupportKits BList and the STL list (or vector), are there any reasons why I would want to select one over the other?  The application is only intended for BeOS family.

I'm only interested in hearing performance related feedback (memory and speed).

Thanks.


Graham Gilmore | 23 Oct 2005 07:18
Picon

Re: Performance question - BList vs STL list

Zenja Solaja wrote:
> Hi.  Just a quick question about possible performance issues for a 
> project I'm working on.  Given a choice between the SupportKits BList 
> and the STL list (or vector), are there any reasons why I would want to 
> select one over the other?  The application is only intended for BeOS 
> family.
> 
> I'm only interested in hearing performance related feedback (memory and 
> speed).
> 
> Thanks.

	It partly depends on your use case, although in general I would lean 
towards the STL containers as more performant.  If you're simply looking 
for a container to hold things that you will later iterate through from 
first to last, a vector is your best choice as there is considerably 
less overhead (both speed and memory wise).  If you plan to modify your 
data set a lot with additions and deletions which are not the first or 
last elements, you might consider using a list instead as it's a lot 
faster to insert or remove elements from the middle of a list, although 
it does use more memory.

	Graham

Zenja Solaja | 23 Oct 2005 11:29
Picon

Re: Performance question - BList vs STL list

Well, I've stumbled onto a bug in BList (SortItems).  Examine the following code:



/*    FILE:            list.cpp
    PROJECT:        Experiment
    AUTHOR:            Zenja Solaja
    CREATION DATE:    23 November 2005
    DESCRIPTION:    BList vs STL list comparison
                    The lists are of integer type   
*/
   
#include <StorageKit.h>    // BList
#include <list>            // STL list
#include "stdio.h"

/*    Local Data    */
const int size = 10;
int sample_data[size] = {10,9,8,7,6,5,4,3,2,1};
   
/*    FUNCTION:        int_sort
    ARGUMENTS:        a, b
    RETURN:            -1 if a < b
                    0 if a = b
                    1 if a > b
    DESCRIPTION:    Basic sort function
*/
int int_sort(const void *a, const void *b)
{
    int *c = (int *) a;
    int *d = (int *) d;
   
    if (*c < *d)
        return -1;
    else if (*c > *d)
        return 1;
    else
        return 0;
}

/*    FUNCTION:        print_BList
    ARGUMENTS:        list       
    RETURN:            none
    DESCRIPTION:    Print all items of a list
*/
void print_BList(BList alist)
{
    for (int i=0; i < alist.CountItems(); i++)
    {
        int *p = (int *)alist.ItemAt(i);   
        printf("%d,", *p);
    }
    printf("\n");
}

/*    FUNCTION:        print_BList
    ARGUMENTS:        list       
    RETURN:            none
    DESCRIPTION:    Print all items of a list
*/
void print_STL_list(list <int *> alist)
{
    list<int *>::iterator p = alist.begin();
    while (p != alist.end())
    {
        printf("%d,", *(*p));
        p++;
    }
    printf("\n");
}

/*    FUNCTION:        main
    ARGUMENTS:       
    RETURN:            exit code
    DESCRIPTION:    "If it compiles, ship it..."
*/
int main()
{
    int i;
   
    //    BList test
    BList b_list;
    for (i=0; i < size; i++)
        b_list.AddItem(&sample_data[i]);
    printf("BList before sort:\n");
    print_BList(b_list);
    //    Sort
    b_list.SortItems(int_sort);
    printf("BList after sort:\n");
    print_BList(b_list);
   
    // STL test
    list <int *> stl_list;
    for (i=0; i < size; i++)
        stl_list.push_back(&sample_data[i]);
    printf("\nSTL list before sort:\n");
    print_STL_list(stl_list);
    //    Sort
    stl_list.sort(int_sort);
    printf("STL list after sort:\n");
    print_STL_list(stl_list);
   
    return 0;
}


And it's output:

/boot/home/test/List>BeApp
BList before sort:
10,9,8,7,6,5,4,3,2,1,
BList after sort:
10,9,8,7,6,5,4,3,2,1,

STL list before sort:
10,9,8,7,6,5,4,3,2,1,
STL list after sort:
1,2,3,4,5,6,7,8,9,10,
/boot/home/test/List>  



It seems that the BList SortItems() function is b0rken (Zeta R1.1).  I've spent all afternoon chasing this bug, and always puzzled why the sorting function never sorted when using BList.  I've switched the algorithm to STL, and it works.  For the life of me, I cannot see anything wrong at my end.

Anyone got any ideas?



Gmane