@orgin

I have been looking at this one some time ago, and because of what I found out, I decided to write distcode myself.

The distcc-bin implementation is only a client implementation for the Amiga, meaning you can use "another computer" to get compiling done for your amiga, and then get back the result.

The other way around (the dist-cc server) is NOT implemented in that package, so the Amiga is not able to accept commands from another computer to start the compilation.

That is the main reason for our approach:
comile on linux.
distribute to amiga.

Regards,

Jeanluc.

We are proud to announce our first little project for all Amiga developers.
Our goal was to develop some tools to get you started with "cross development for Amiga OS4.1".
As we have been working quite some while on it, we noticed the lack of a clean method to produce a cross compiler for the Amiga. For this reason, we created a special script which will build a complete cross compiler toolchain for you.

As an extra, we added our second project "distcode" as freeware.
Distcode will automatically distribute binaries you have written from your Linux box to your Amiga RAM: disk!

Downloads can be obtained at os4depot.net (distcode.lha). Both projects are inside this archive, both documented with readme's.

We wish all developers a happy new year 2010, and good luck with our tools!

check out our sites for regular updates on what we are doing:

www.amiga4u.com (general announcements, which also will be made here)
www.amineat.net (a little supprise for Amiga developers in 2010!)

@broadblues

I am starting to understand the problems now. I use the compiled version of the crosscompiler from zerohero, I did not compile the crosscompiler and binutils myself. It seems the whole cross environment is not updated towards the newest SDK from hyperion (my impression). So I am using binaries which are not compatible with the newest SDK. It all makes sense now.

We have been building a linux script at the end from last year to get the cross tools working, and I remember we had some rough days and nights getting it all together. Building the cross toolchain for linux 64bit was not that easy, and I fear we will run into this nightmare again. I also noticed zerohero has put the cross compiler for AOS4 offline, so I guess he is having the same nightmare as we did last year

I hope there will be a day we have a working script to buil the cross toolchain for at least some standard linux distros.

I personally do my amiga coding on Code::Bench, and then transfer it by tool written by myself to the Amiga (kind of a mini ftp-server on the amiga side).
I will upload this tool in the next couple of days on os4depot.

Anyway thanks for your help, it cleared a lot of things for me. And I am again in for the little nightmare now

JeanLuc

sorry to get back to you this late, but Christmas tends to go with social obilgations ))

@broadblues
Can I sent you the crashlog by mail?
The readelf shows what it should show:

Dynamic section at offset 0x100a4 contains 13 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libstdc++.so]
0x00000001 (NEEDED) Shared library: [libgcc.so]
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000004 (HASH) 0x1000094
0x00000005 (STRTAB) 0x1000210
0x00000006 (SYMTAB) 0x10000f0
0x0000000a (STRSZ) 376 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000007 (RELA) 0x1000388
0x00000008 (RELASZ) 24 (bytes)
0x00000009 (RELAENT) 12 (bytes)
0x6ffffff9 (RELACOUNT) 2
0x00000000 (NULL) 0x0

Does look quite normal to me...

Grim reaper tells me:

Guru Med 80000003
Task 0x... ("") generated an error of type DSI in address 0x...
Redzone was not damaged.
Stackpointer is inside bounds.

The weird thing: I press "more", and "Continue program". And guess what: the program continues and the output makes sense ))

@hans
Thanks for reminding me As I described in my start post, I forgot to add the virtual keyword, and the error occured to me in a piece of code I did not tend to write like I posted it. I know about the use of virtual destructors in classes to be derived, but it is anyway a good reminder for me and all readers here )) Nevertheless, i still wonder why it happens, because as long as the class is not derived from, the construction is correct, the behavior on Amiga is (what I think about it) not...

Hello there!

I have noticed some strange behavior on c++ classes in shared objects, and perhaps someone could help me on this one. I noticed this after long time try, and do not really understand it.

Defining a non virtual destructor in a class in a shared object allways lead to guru meditations trying to call it.
For example:

namespace Amiga
{
class Test
{
public:
Test();
~Test();
};
}

will cause the crash if done in an so-lib.
Doing:

namespace Amiga
{
class Test
{
public:
Test();
virtual ~Test();
};
}

will not cause it to crash, it simply works.
I must admit, in my "crash" code I plain forgot to use "virtual" (the class I am writing will be derived from, so i actually needed the virtual method. But what if I just write a plain class not needed to be derived from, and not in need of a virtual destructor?

I did not test it in a simple c++ program, it was compiled in a lib with -fPIC and -shared, the executioner which loads my lib is done with -use-dynld -lauto.

Anyone has seen this before??? Am I in need of some other compiler/linker flags which I am forgetting?

Thanks in advance for any help!
JeanLuc