Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
2 user(s) are online (2 user(s) are browsing Forum)

Members: 1
Guests: 1

GreenNight, more...
   All Posts (michalsc)


« 1 (2) 3 4 5 ... 40 »


Re: Unable to build AROS Core source

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 404
Offline
Quote:

kjanz1899 wrote:
Trying to build the core source after downloading the 23-June version from the nightly site. I'm running Debian 8 64-bit and issued these commands

./configure --target=linux-i386
make
[...]
checking for suffix of object files... configure: error: in `/home/kevin/AROS/AROS-20150623-source/bin/linux-x86_64/gen/tools/crosstools/gcc/i386-aros/libgcc':
configure: error: cannot compute suffix of object files: cannot compile


Your 64-bit Debian is missing support to compile 32-bit binaries (and since you're building linux-i386 target you need 32-bit support). Install missing packages and it should work.

Posted on: 2015/7/28 23:16
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: lsusb -> "Please use c:loadresource"

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 404
Offline
Quote:

serk118uk wrote:
Hi ppl,

lsusb should display connected devices right? but i get "Please use c:loadresource"

whats the correct way of using "lsusb" on aros?

thanks.


lsusb was part of my old USB stack used in AROS until it was removed and replaced by Poseidon. I don't know if poseidon has similar tool for command line.

Edit: Here is the last svn revision with this tool in AROS tree:
https://trac.aros.org/trac/browser/ARO ... ls/lsusb/main.c?rev=36079

Posted on: 2015/4/24 3:51
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: A week in AROS...

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 404
Offline
Quote:

deadwood wrote:

- AROS kernel for ARM architecture is now able to detect the number of existing process cores (mschulz)


should be

- AROS kernel for ARM architecture is now able to detect the number of existing process cores (Kalamatee)

:)

Posted on: 2015/4/13 3:20
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: Aros Abi v1 x86_64

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 404
Offline
Quote:

cdimauro wrote:

But even talking generally, a 64-bit system/platform can have sizeof(void *)) = 4. Take x32, for example: http://en.wikipedia.org/wiki/X32_ABI


It's not a full 64-bit system in such case ;)

Quote:

For the 3.0 version of the Amiga o.s., I remember that sizeof(unsigned long) was 4. AROS is 3.0-compliant, so it should be the same, whatever is the architecture used.


the size of types used in C compilers have never a fixed size, they may change with architecture or even change with the compiler. That's why C standard provides types of fixed size (stdint.h include and the types it provides). In case of AROS we guarantee that the Amiga-like data types such as BYTE/WORD/LONG and their unsigned versions have a fixed sizes of 1, 2 and 4 bytes, respectively. The size is the same on every platform AROS supports.

Quote:

The only problem with the software is with the size of pointers, but I think that assuming a size of 4 for them can be classified as "bad coding", even talking about the old 3.0 version of Amiga o.s..


You will find quite a lot of that in amiga software, unfortunately. First and quite common example are the TagLists. There, coders tend to cast pointers to ULONG type when writing to ti_Data field.

Posted on: 2015/1/1 6:39
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: Aros Abi v1 x86_64

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 404
Offline
Quote:

Kalamatee wrote:

The problem isnt that they assume sizeof(APTR) == 4, its that they often dont use APTR, and use ULONG to store pointers exclusively. If the code used APTR/IPTR as it should - most of the "problems" wouldn't exist.


It would also help if people would start using variadic arguments properly. Many coders do assumptions which shall never be made. Instead, they should consider using stdarg.h file and all the va_* functions :)

Posted on: 2014/12/31 2:46
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: Aros Abi v1 x86_64

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 404
Offline
Quote:

BSzili wrote:
What about all the non-64-bit-clean software?


Chicken and egg issue again. Not a single person will care about fixing those non-64-bit clean stuff until it fails to compile/run on a 64bit distro...

It's a bit sorry, since we have the 64-bit AROS for something like 5 or 6 years already, and still most people don't care.. First when MOS or OS4 will go 64bit there will be a huge discussion about it.

just my 2 cents, ignore me ;)

Posted on: 2014/12/16 5:57
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: Aros 64 bit

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 404
Offline
Quote:

GreenNight wrote:

I understood the problems you described (int_64 != int_32) maybe it might a good time to design an ArosNG API before it it becomes inevitable.



1. 64-bit AROS does not use int32_t type to report allocation errors. We do provide IPTR (or it's equivalent intptr_t type) on purpose.

2. 64-bit AROS has been already tested with configurations having more than 4GB of RAM. AFAIR it was tested up to a 24GB configuration with TLSF allocator, but I might be wrong here, I have tested it with 16GB though.

3. All 64-bit AROS apps are compiled using -mcmodel=large option which means they can reside anywhere in the 64-bit address space.

4. The use of most significant bit in a 32-bit types used commonly in AmigaOS has been changed to use the least significant bit. This bit was not used anyway in the aforementioned cases due to alignment constraints.

any other issues I forgot?

Posted on: 2014/11/12 3:35
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: vbcc

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 404
Offline
Quote:

ncafferkey wrote:
BTW, I tried simply using the strip command on i386 AROS C commands, and it made a big difference to size (simple commands such as EndCLI were almost halved in size). However, the one downside was that the commands no longer worked


most likely because strip removed also whole relocation info (since it stripped the symbols apparently).

Long time ago I wrote a tool which basically re-linked AROS executables and adjusted all relocations to be section-based instead of symbol-based. This way it was possible to remove all symbols from the executables and to keep all section-relative relocations in place. Depending on the binary and amount of symbols in it, it was able to save something between 10 and 20% of file sizes.

For some reason which I don't remember now, none was interested :)

Posted on: 2014/11/5 1:19
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: Get AROS m68k to run over QEMU(qemu-system-m68k)

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 404
Offline
Quote:

phoenixkonsole wrote:
I would like to see qemu usermode working on aros i386. This way we could run 68k apps on i386 aros and mixed libs.


In addition to what Ezrec said, as far as I know qemu user mode does not allow to use mixed libraries. E.g. if you run a PPC program with qemu-powerpc, you will need all the ppc libraries it requires. The qemu in this case translates the syscalls to the linux kernel, only.

Such mixed libraries are even not really feasible within one architecture. Think about all the x86_64 linux distributions which contain nearly all libraries in two versions - 32 bit and 64 bit. Think about the %SystemRoot%\SysWOW64 directory on windows, where 32bit libraries (or at least lightweight wrappers, if feasible) are stored...

Posted on: 2013/12/9 11:26
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: bug in arix hosted

Joined:
2004/3/30 23:19
From Clausthal-Zellerfeld, Germany
Group:
Member
Posts: 404
Offline
Quote:

phoenixkonsole wrote:
It is impossible to mount host fs in arix hosted. If you find time to fix this please do also for aros hosted armhf build. ; p


Ahem, what host fs would you like to access on ARIX? and why?

Posted on: 2013/11/22 9:03
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer



 Top
« 1 (2) 3 4 5 ... 40 »




Search
Top Posters
1 paolone
paolone
4239
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3883
4 nikolaos
nikolaos
3651
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2532
7 mazze
mazze
2200
8 clusteruk
clusteruk
2055
9 Kalamatee
Kalamatee
1986
10 damocles
damocles
1789
© 2004-2014 AROS Exec