Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Inkus]

Originally posted by lfroen
Too bad. Your compiler is broken (word "your" is emphasized). Why don't you go and fix it or replaced with better one ? I never compiled gcc in my life - binary distributions are already invented, you know.

I know. I will try gcc 3.4 in the end. I heard 3.4 is considered very stable. If it does not help, looks like I'll have to forget about amule. HP have stopped supporting HP-UX 11.0 in their packaged software archive, so there is no binary distribution I could use.

You welcomed to change what you want, document it and place patch in wiki. No change going into code. We applied patch for ARM because people actually buy those devices, and running amule(d) there make sence, considering their design and purpose. This is not the case with all proprietary Unix'es out there like AIX, HPUX, QNX and others: very expansive hardware used by goverment/academic/coprs for very specific purposes. Not ever intended for private use.

BTW: given the cost of average HPUX machine I doubt that you own one. Did you asked permission to run amule there ? In places where I say such machines, you would need permission even to compile such thing.

This machine is very old and very slow one.It was used in production environment long long time ago. HP have stopped supporting HP-UX 11.0 (its about 1.5 year from that time), so you can compare it to a machine running win98 or even win95 on the hardware of that time.

[Inkus]

I have compiled amuled with gcc 4.0.2 successfully, however, when run, get bus error.  The same goes to ameweb also. amulecmd starts fine. My blind guess is the byte ordering(hp parisc is bigendian). Did anyone try amule(d) on any bigendian architecture?

What should be the normal size of amuled (with debug symbols included)? my amuled binary is ~70MB of size 8o (with debug symbols, dynamically linked).

I am still thinking of trying gcc 3.4, but the more I think, the less I have desire to do it.

[stefanero]

works fine on power mac which is also big endian....

[lfroen]

HP have stopped supporting HP-UX 11.0

This machine is very old and very slow one

Now I see what's going on You've got yourself aged out machine which eventually have quite rate architecture and OS. Now you entertaining yourself with attempts to do something usefull with it. It must be real fun (seriously) and nothing wrong with that.
Unfortunatly, some modern software is not comptible with it. SOYL, deal with it any way you want. It is not reasonable to adapt software for machines outaged years ago.

[Kry]

lfroen, can you stop being an annoying nitpicker? If he just needs waitpid instead of wait4, it's cool for me. We try to support *as much as we can* without breaking functionality. this is a good example.

[Inkus]

Originally posted by lfroen
Now I see what's going on You've got yourself aged out machine which eventually have quite rate architecture and OS. Now you entertaining yourself with attempts to do something usefull with it. It must be real fun (seriously) and nothing wrong with that.

Exactly.  

Originally posted by lfroen
Unfortunatly, some modern software is not comptible with it. SOYL, deal with it any way you want. It is not reasonable to adapt software for machines outaged years ago.

I wouldn't call it is despairingly outaged. Actually, amule is the first software I could not run at all on that machine because of bus errors. Maybe that's because most of software I have compiled was GNU soft or very popular and  developed for a long time. Maybe my compiler is not working correctly, or maybe I am doing something wrong, or just am out of luck.  ;(

Originally posted by Kry
If he just needs waitpid instead of wait4, it's cool for me. We try to support *as much as we can* without breaking functionality. this is a good example.

I agree with Kry here. If I am not wrong, wait4 does not exist on some AIX versions too. Modern HP-UX (and I guess AIX) OS versions do have wait4 available. But the fact, that waitpid is implemented as wait4 with last argument equal null, does not mean, that wait4 should be used instead. If you gain more compatibility using generic versions of a function, IMO that's the way to go.  

[Kry]

Specially if we just use latter param as null.

BTW, what about using gdb to show us where the bus error happens?

[Inkus]

I get internal error in gdb, because gdb is out of memory

[phoenix]

Originally posted by lfroen
...

n aMule source I needed only one change yet : aMule.cpp - to change wait4 call to waitpid, since there is no wait4 on hp-ux 11.0

Too bad again.
You welcomed to change what you want, document it and place patch in wiki. No change going into code. We applied patch for ARM because people actually buy those devices, and running amule(d) there make sence, considering their design and purpose. This is not the case with all proprietary Unix'es out there like AIX, HPUX, QNX and others: very expansive hardware used by goverment/academic/coprs for very specific purposes. Not ever intended for private use.

Sorry, but I seem to be missing something here. Why isn't the change going into code? I have asked all the devs in a previous post if there was any objections, but when I do that, I expect to read objective reasons not to include this change. Like Kry said, it has always been a policy of the project to support as many platforms as we can, damn, we even support windoze! So unless you have a very good reason not to do it, something like "it breaks platform X", I vote for including this change in the code.

[Kry]

Why is it not even commited yet? DO I have to do everything?

[phoenix]

Committed.