text:
Aros/Platforms/Installing on *nix

Introduction
Icaros Desktop distribution now has an option to install itself on Linux, just like any other application.

AxRuntime forum to run AROS apps native on Linux]

Please also see here for git based access for building

The information here maybe old and out of date. Please update with any new findings or discoveries

x64-linux
To follow

i386-linux and i386-freebsd
The latest Ubuntu, OpenSUSE, CentOS seem to be the most popular supported distributions (distros) for AROS development and able to compile hosted AROS on them.

Requirements

 * Debian 9
 * Debian 8
 * Debian 7
 * Debian 6 GimmeAROS works perfectly once you have the installed dependencies.

 * Ubuntu 11.10 -
 * Ubuntu 12.04 -

 * OpenSUSE 11.2 - The default compiler which you get installed does not work well with aros native (it was gcc-4.4.1 but now 6.3). Intel GMA development and test builds of the whole AROS were done with Suse.

 * CentOS/RedHat Enterprise may not have a current enough gnu autoconf available from their package installer, so you'd have to manually install it, so the AROS/configure script works.

 * FreeBSD 8 does not currently build, it can work with a little hack here and there with the source tree.
 * FreeBSD 7 was ever completed as a host platform, not openbsd nor netbsd.

Under *BSD often the system includes conflict with AROS includes, sometimes there were varargs differences in the gcc configurations that broke the build as well. Search for netbsd on aros-exec for the notes.

The current source tree under linux wants any GCC 6.x but previously 4.x version. It been a long while since the AROS source tree could build correctly under linux with the very old 3.x versions of GCC.

Many devs use the linux-hosted version to do their development work

Please do the following:
 * 1) download the ISO
 * 2) extract the ISO to get the files
 * 3) download http://download.aros3d.org/software/linux.tar.gz
 * 4) extract the contents to /Arch, you should end up with Arch/linux directory
 * 5) $ ./Arch/linux/AROSBoostrap

and now you turned your pc-i386 ISO into linux-i386 installation

Does aros linux hosted compile on a 64 bit linux? Yes, but 64-bit Linux-hosted does not work - mmap allocates memory beyond 2GB space. And there's no MAP_32BIT. The 64bit x86 version of hosted AROS is normally built and run on a 64 bit linux. It won't run the "regular" i386 32bit AROS program binaries. You can even compile and run 32bit hosted aros on a 64bit linux. Though, it might depend on the distro, on ubuntu it was easy to get all needed libs in 32bit versions.

FreeBSD doesn't support such a construct either. In fact it looks like mmap by default maps well past the end of the 4GB range. What do *BSD guys do with this? Or the only thing we can do is changing AROS 64-bit code model? At least for some flavors. Something will happen anyway as AROS is a single address space OS. Perhaps the best option is to have everything implemented using the small or medium PIC models (at least for user code).

Make native AROS which builds hosted
The manual instructions were to build a native AROS which builds partly the hosted environment. This has not been tried building under OSX, so not sure of how well that works. Linux is the most used environment. Just running the configure script without target instructions should detect the underlying OS and setup for building a hosted-AROS.

Recommend new developers download the gimmearos.sh script (on aros-archives?) to set up the developer environment by downloading necessary packages and running the config script and make for you, and then download bootaros.sh script for help setting up the linux tap device networking for running linux hosted AROS with functional networking.

For anonymous downloads, The git server repo.or.cz has AROS.git, AROS-Contrib.git, and AROS-Ports.git. You can manually download these as...

git clone git://repo.or.cz/AROS.git git clone git://repo.or.cz/AROS-Contrib.git git clone git://repo.or.cz/AROS-Ports.git

If you don't mind waiting forever for metamake to try to build everything that is configured (and its not all configured to build, like make aros-tcpip-apps-owb must be manually invoked to build owb) you can just mv the contrib and ports directories into AROS, then

mkdir pc-i386 cd pc-i386 ../AROS/configure --target=pc-i386 make

then manually make anything else you want to include on your bootimage that wasn't preconfigured to build and finally make a bootable iso image by.

make bootiso-pc-i386

my script for building different GCC versions instead of using hosted one

build_dir="/home/ubuntu/aros_tools" mkdir -p $build_dir cd $build_dir

wget -nc ftp://ftp.gwdg.de/pub/misc/gcc/releases/gcc-$1/gcc-$1.tar.bz2 tar xvjf gcc-$1.tar.bz2

if [ -d "$build_dir" ]; then rm -rf $build_dir/build fi

mkdir -p $build_dir/build cd build ../gcc-$1/configure --prefix=/usr/bin/gcc-$1 --program-suffix=-$1 --enable-languages=c,c++ --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions

make sudo make install

cd /usr/bin/gcc-$1/bin sudo ln -s gcc-$1 gcc sudo ln -s g++-$1 g++

Here's the script for actually building Aros (i386 ABI_V0)

build_dir="/home/ubuntu/aros_svn/branches/ABI_V0/aros_builds"

if [ -d "$build_dir" ]; then rm -rf $build_dir fi

mkdir $build_dir cd $build_dir

export PATH=/usr/bin/gcc-4.1.2/bin:$PATH

/home/ubuntu/aros_svn/branches/ABI_V0/AROS/configure --target=pc-i386 --with-serial-debug=1 --enable-usb30-code --with-portssources=/home/ubuntu/aros_cache

make

build Aros pc-i386 on 64bit Linux
ABIv0 x86_64 is essentially unmaintained. Use ABIv1 or i386. compiling with—target=linux-i386. Did you delete your build tree after your attempt to build with no specific target (e.g. --target=linux-x86_64 )?

install on Ubuntu 11.10 x86_64: g++, libpng12-dev, gcc-multilib, libx11-dev, ia32-libs, libgl1-mesa-dev

Latest Lubuntu's dependencies to be satisfied before getting to the end: g++ libpng12-dev gcc-multilib libx11-dev ia32-libs libgl1-mesa-dev g++-multilib libX11-dev:i386 These are the packages names for Ubuntu flavours. The last one was especially tricky but google was my friend. Now the compilation completes successfully and now can crosscompile for x86 from my x86_64 distro.

New installed (maybe missing?) packages: libpng12-dev, ia32-libs, g++-multilib compiling takes about 5 minutes 50 seconds, make clean ./configure --target=pc-i386 time make -j 12 bootiso-pc-i386

Errors

Perhaps there is some 64-bit code left over in the tree that causes your last error.

Extracting
Since AROS/i386-linux and AROS/i386-freebsd are hosted flavors of AROS available from aros.org, installation is simple. Simply get the appropriate archives for your platform (Linux / BSD) from the download page and extract them where you want them:

If you downloaded the contrib archive, you may want to extract it too:

Build
Ubuntu building

The generic Debian part is pretty much

locales locales/locales_to_be_generated multiselect    en_GB.UTF-8 UTF-8 locales locales/default_environment_locale     select  en_GB.UTF-8
 * Call debootstrap
 * Feed this or similar to debian-set-selection (debootstrap gives you just POSIX locale by default):
 * apt-get install locales build-essential subversion automake autoconf bison flex netpbm python

There are probably additional packages that'd be useful, but the above is sufficient to build AROS, including contrib if necessary. Planning on wrapping up my script so to keep my current dev environment in one VM and have it prep a new VM every night for additional testing.

The upshot of this, is that PARANOIA_CFLAGS is now gone. If you want to enable a '-Wall -Werror' build, just add '--with-paranoia=yes' to your configure, and the while tree will be built such that any compiler warning stops the build.

Make
Our build relies on packages downloaded from Internet - it always worked this way. The minimal requirement (when just building core AROS) is binutils and gcc. If you build contrib as well, you need many more packages to be downloaded. That doesn't take away from the fact that it's still a rather curious step in the build.

We don't host the whole binutils and other packages like that in our repository, we only host patches to the mainline (no patches, in case of binutils). You see the build fetching binutils from the gnu repository. If the build fails, it must be sometimes later, unless you are not connected to the internet. :-) There is a configure switch which might help a bit. If you specify—with-portssources=/somedir/someotherdir/aros_sources on the configure command line fetched packages will be put to the directory given. Later builds (even from scratch ones) will look at this location first before downloading anything. You also copy needed stuff before starting make.

CC="gcc-4.3 -m32" ./configure—target=linux-i386—enable-debug=all—with-portssources=/home/mazze/projects/ports-src/ --enable-crosstools

export CC=/usr/bin/gcc46 export PYTHON=/usr/bin/python2.7 /mnt/NAS/PC/AROS/trunk/configure --target=pc-i386 --with-serial-debug --enable-ccache --with-bootloader=grub2 --with-theme=Xstream --with-portssources=/mnt/NAS/PC/portssources

We require build tools to be pre-installed. Only software that runs on AROS is fetched and built, with the exception of the AROS-targeted GCC and binutils (because they aren't commonly available as binaries).

There is a script called GimmeAROS somewhere that downloads the necessary host packages for certain Linux flavours.

--with-crosstools used to be both the source and target of AROS crosstools - now it is only the source of the kernel tools, and implied—disable-crosstools—with-kernel-tool-prefix=... is required for some architectures if—disable-crosstools is selected. ./configure should tell you.

Hosted archs, if being cross-compiled (ie linux-arm on x86), will require—with-kernel-tool-prefix= even if building crosstools, since it needs to know where to find the Linux ARM toolchain for building AROSBootstrap. The error in ./configure for this is pretty bad right now (failure to find dlopen).

Will be adding back something like '--with-target-tool-path=' for specifying where to build the target crosstools to, ie for SDK builds, but I want to make sure non-SDK builds work first.

 * Linux 32bit (best if going to use Icaros or AspireOS setups) linux-i386-system or 64bit linux-x86_64-system
 * VM is another option but slower

Treat as any archive and unarchive in your user area or /usr/local depending on Linux GNU distro used.

Read more here and here

Binaries
Recent Distros (2011+) have dispensed with the backingstore option and we are looking at alternatives at the moment.

A configured and working X server (for example XFree86 or X.org) with backingstore. If you are running XFree86 4.0 or later, you might notice that the windows containing AROS screens do not refresh properly (for example when a different window passes over them). This is due to the fact that AROS uses the "backingstore" functionality of X, which is turned off by default in XFree86 4.0 and later. If you are starting X with the startx command, you can enable it again by passing the +bs option

If you start X by some other means (e.g. with XDM), you can instead add the following line to the device section of your graphics card in the X configuration file (commonly named /etc/X11/XF86Config or /etc/X11/XF86Config-4):

Option "backingstore"

A complete device section might then look like this:

Some newer distros allow Xorg's backingstore to be enabled for AROS hosted, by creating a small config file in the directory /usr/lib/X11/xorg.conf.d named 05-backingstore with the following:

Raspbian (ARMv6 armhf build of Debian Wheezy and others?) sudo leafpad /etc/x11/xinit/xserverrc add +bs after usr/bin/X and save exit

To start AROS

-h -m -M -t --help --memsize --mapsysbase

There are also the following files:

 * aros-base - base kickstart module (architecture-independent libraries).
 * aros-strap-hosted - boot code (bootloader.resource and dosboot.resource)
 * aros-bsp-linux - board support package (architecture-dependent parts).

The first and the second parts are interchangeable between Windows-hosted port. In future the base kickstart will be interchangeable between all ports.

--hostmem argument is gone. In future this is going to be implemented in other way. Michal Schulz is working on a new memory manager. If someone really misses it, i can bring it back, however.

--tickrate argument is also gone. Instead you have two new arguments:

vblank=xx - set VBlank frequency to xx Hz. Default is 50.

eclock=xx - set master timer frequency to xx Hz. If you specify eclock=100 you'll get the same as what you had before.

In near future, ability to specify arguments in AROSBootstrap.conf file, so there will be no wrapper scripts needed. Hosted serial and parallel ports are missing. They will be back after some time.

If it does not go well

 * 1) make sure the logs end up in the emails sent to the AROS mailing list
 * 2) Send to the mailing list your ./configure line, the ./configure output, and the config.log file if it fails
 * 3) make -s query if you can get past configure

Building ISO
If you have network access, the anonymous git repo is much better to use. It eliminates all the date coded directories and any future updates are just a "git pull" command away. You can locally branch off whatever way you want and create diffs to submit for others to look at.

Figure out where you want to build locally (maybe a directory named src), cd there and git clone git://repo.or.cz/AROS.git cd AROS git clone git://repo.or.cz/AROS-Contrib.git

./configure make

[ DISCLAIMER: This is just **how I made it** it's not meant to be a perfect or bullet-proof guide, so: no warranties ;) ]

1. Install subversion

in a terminal window write:

> sudo apt-get install subversion

2. Get the AROS and Contrib sources: (here I use SVN, but you might just download sources from www.aros.org)

in a terminal, from your home path write:

> svn checkout https://svn.aros.org/svn/aros/trunk/AROS

> cd AROS

> svn checkout https://svn.aros.org/svn/aros/trunk/contrib

3. Install GCC 4.xx (examples use 4.2)

In a terminal window write:

> sudo apt-get install gcc-4.2

4. Install Automake1.9, Bison, Flex, netpbm, patch:

> sudo apt-get install automake1.9

> sudo apt-get install bison

> sudo apt-get install flex

> sudo apt-get install netpbm

> sudo apt-get install patch

5. Set your compiler with GCC-4.2:

> export CC="gcc-4.2"

6. Launch configure with—target=pc-i386 parameter:

> ./configure—target=pc-i386

or you can compile with some optimizations:

> ./configure --target=pc-i686

> AROS_TARGET_ARCH=pc > AROS_TARGET_CPU=i686

7. Compile launching make

> make

8. Create an .ISO file with

> make bootiso-pc-i386

the .iso will be created in "~/AROS/distfiles/" directory

if you still needed to make kernel-kernel because the compile fails, at this bucomm.c

Clean the build Go to workbench/libs/mesa/src/mesa Edit mmakefile.src Find the line #MM- workbench-libs : workbench-libs-mesa Put # before the whole line (it disables the dependency)

configure make ... you will get fail make kernel-kernel ... you will get fail make ... now it should compile till the end

NOTE: You should have the following sources: From main aros source package - all sources in directory AROS From contrib aros source package - only contrib/necessary in directory AROS/contrib/necessary (copy not link!)

What you might be interested is a compiler. You can find it in bin/linux-i386/tool/i386-linux-aros-gcc

Sound on Hosted
It was the case that OSS was only supported but now there is an ALSA audio driver

OSS seems to not work with Ubuntu 11.04 either. OSS was supported in 10.4 (and older releases).

 * 1) apt-get install alsa-oss
 * 2) modprobe snd_pcm_oss
 * 3) modprobe snd_mixer_oss

works for debian wheezy and squeeze 6

Another alternative is to use alternative kernel - Liqourix, Debian testing/unstable, AVLinux, Aptosid (not sure if Aptosid supports oss)

Liquorix on Debian and Ubuntu, its repository offers also wine 1.5, some libs and firmware/drivers (wifi,ethernet)

 * 1) LIQUORIX HOW-TO:

sudo nano /etc/apt/sources.list

 * 1) ADD LINE:

deb http://liquorix.net/debian sid main

 * 1) CTRL+O, ENTER, CTRL+X (save,exit)

sudo apt-get update

sudo apt-get install '^liquorix-([^-]+-)?keyring.?'

sudo apt-get update

sudo apt-get install linux-image-3.7.0-8.dmz.1-liquorix-686

 * 1) REBOOT

 * 1) I have intel 2200 wireless card so:

sudo apt-get install firmware-ipw2x00

The Liquorix kernel can be installed by way of meta-packages. This will guarantee that the latest kernel is installed on every upgrade.

All packages in the liquorix repository are signed. Run the command below to install the keyring package for liquorix.net.

apt-get install liquorix-keyring

32-bit without PAE (HIGHMEM4G):

apt-get install linux-image-liquorix-686 linux-headers-liquorix-686

32-bit with PAE (HIGHMEM64G):

apt-get install linux-image-liquorix-686-pae linux-headers-liquorix-686-pae

64-bit:

apt-get install linux-image-liquorix-amd64 linux-headers-liquorix-amd64

Configuring host network for AROS hosted

 * 1) !/bin/sh

NETON=`ifconfig | grep aros0`

if [ "$NETON" = "" ]; then echo "Installing bridge network... (sudo access required)" sudo tunctl -b -u "$USER" -t aros0 sudo ifconfig aros0 192.168.166.1 sudo iptables -t nat -A POSTROUTING -o eth0 -s 192.168.166.0/2 -j MASQUERADE sudo iptables -t nat -A POSTROUTING -o wlan0 -s 192.168.166.0/2 -j MASQUERADE sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" fi echo "Set your AROS config to:" echo " device        : tap.device" echo " IP            : 192.168.166.2" echo " Mask          : 255.255.255.0" echo " Gateway       : 192.168.166.1" echo " Primary DNS   : 8.8.4.4" echo " Secondary DNS : 208.67.222.222"

Networking is done differently on Arch than in other distros, notably the lack of the UML tools which are normally used for creating TAP/TUN devices.

tap_ip=192.168.254.254 iface="aros0" masq_iface="enp2s0" sudo ip tuntap add name $iface mode tap echo "Created tap device: $iface" echo "Setting $iface to IP adress $tap_ip and bringing it UP" sudo ifconfig $iface $tap_ip up   sudo chmod 666 /dev/net/tun
 * 1) !/bin/bash
 * 2) tap unit number. This should match the UNIT= parameter in
 * 3) AROSTCP/db/interfaces
 * 4) IP address for the tap interface. Inside AROS, this will be your default gateway.
 * 5) NOTE: Make sure it is in a different network than your Linux host.
 * 1) create the interface
 * 2) iface=$(sudo ip tuntap add name aros$tap_unit mode tap)
 * 1) bring it up
 * 1) turn on NAT
 * 2) (NOTE: make sure that the network interface you are using is named "eth0".
 * 3) Otherwise adjust the following line to your needs.)

echo "Configuring NAT routing from interface $masq_iface" sudo iptables -t nat -A POSTROUTING -o $masq_iface -j MASQUERADE sudo sysctl net.ipv4.ip_forward=1 cd ~/AROS ./Arch/linux/AROSBootstrap sudo ip link delete $iface sudo sysctl net.ipv4.ip_forward=0
 * 1) Turn on IP forwarding
 * 1) start AROS
 * 1) aros has finished, so kill the interface
 * 1) maybe turning off routing is a good idea as well

How to mount some device or directory (for example a dvd-drive) as a drive under aros hosted?
Add this to Devs/Mountlist

WORK: FileSystem    = emul.handler Device        = WORK:/home/mazze/arosdev LowCyl        = 0 HighCyl       = 0 Surfaces      = 1 BlocksPerTrack = 1 DOSType       = 0x454D5500 Activate      = 1

and add e.g. mount work: to s:user-startup

HOST: FileSystem    = emul-handler Device        = Host:/ LowCyl	      = 0 HighCyl	      = 0 Surfaces      = 1 BlocksPerTrack = 1 DOSType	      = 0x454D5500 Activate      = 1

HOME: FileSystem    = emul-handler Device        = Home:~ LowCyl	      = 0 HighCyl	      = 0 Surfaces      = 1 BlocksPerTrack = 1 DOSType	      = 0x454D5500 Activate      = 1

CD2: FileSystem    = emul-handler Device        = CD2:/media/label_of_drive/some_directory/Some_subdirectory LowCyl        = 0 HighCyl       = 0 Surfaces      = 1 BlocksPerTrack = 1 DOSType       = 0x454D5500 Activate      = 1

Usually, if a CD or DVD is inserted, Linux will see them under /dev/cdrom. You won't be able to view the contents from that location directly such as by doing cd /dev/cdrom or ls.

You can mount this CD by creating a mount point or using the existing mount point such as /media

run the following command

sudo mount /dev/cdrom /media
 * 1) you can use your custom mount point as well if this is on your desktop or somewhere else e.e. /media/cdrom

Copying and Configuring Icaros 1.xx
an updated guide for Icaros 1.26 (on Debian / Ubuntu):

Put keycode2rawkey.table in Devs/Keymaps/X11

 * Install the tunctl command on your host:

sudo apt-get install uml-utilities

 * Copy the Icaros CD to a folder named "AROS" in your home directory
 * Copy over the following files from a Linux hosted nightly archive:

AROS.boot boot/* Devs/AHI/aros.audio Devs/AudioModes/AROS Devs/Drivers/unixio.hidd Devs/keymaps/X11 Devs/Monitors/X11 Devs/Networks/tap.device Libs/oss.library Devs/timer.device

 * Delete Devs/Monitors/Nvidia
 * Edit boot/AROSBootstrap.conf to suit your needs (e.g. add "memory 256" to assign 256 MB RAM to AROS)
 * In S/icaros-sequence, remove the line "assign system: sys:"
 * Create the script bootaros.sh in the AROS folder, make sure you read the comments. Adjust where necessary:

tap_unit=0 tap_ip=192.168.254.254 iface=$(sudo tunctl -b -u `whoami` -t aros$tap_unit) sudo ifconfig $iface $tap_ip up   sudo chmod 666 /dev/net/tun sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE sudo sysctl -w net.ipv4.ip_forward=1 cd ~/AROS ./boot/AROSBootstrap sudo tunctl -d $iface &> /dev/null sudo sysctl -w net.ipv4.ip_forward=0
 * 1) !/bin/bash
 * 2) tap unit number. This should match the UNIT= parameter in
 * 3) AROSTCP/db/interfaces
 * 1) IP address for the tap interface. Inside AROS, this will be your default gateway.
 * 2) NOTE: Make sure it is in a different network than your Linux host.
 * 1) create the interface
 * 1) bring it up
 * 1) turn on NAT
 * 2) (NOTE: make sure that the network interface you are using is named "eth0".
 * 3) Otherwise adjust the following line to your needs.)
 * 1) Turn on IP forwarding
 * 1) start AROS
 * 1) aros has finished, so kill the interface
 * 1) maybe turning off routing is a good idea aswell

 * Make the script executable:

chmod u+x bootaros.sh

 * Start the script from a shell:

cd ~/AROS ./bootaros.sh

 * Inside AROS, the network settings will have to be configured like this:

Device: tap.device IP address: 192.168.254.1 Gateway: 192.168.254.254 DNS1: The IP of the name server that is also used by your Linux host DNS2: The IP of the name server that is also used by your Linux host

PowerPPC
In fact the usage  of  variant was a continuation as Michal Schulz' usage  for Efika port. There variant is a "sub-architecture". Stuff in arch-cpu can  be  overriden  by arch-cpu-variant. This way there is generic ppc-chrp code and ppc-chrp-efika code. This is what was used for the Android and iOS ports. Was even sure that Michal introduced variant for this purpose. Some time  ago, came to a need of versioning some components, to be able  to  verify  that  they match. For example, disk-based tap.device needs to know that it really runs on system it was built for. This need  originates  from  the  fact  that  many  things  are source-compatible but not binary-compatible across various UNIXes. For example, the  same  tap.device code can be built for Linux and Darwin. They will  use  the same host OS calls, but parameters passed to them are  not  binary-compatible. Darwin version of tap.device won't run on Linux-hosted AROS and vice versa. In order to prevent crashes that are hard to explain, introduced runtime versioning of these components.

The following modules are taking part in it:

 * kernel.resource, being  the primary architecture-dependent part, carries  architecture  name  in  the  form  of  arch-cpu.  For example "linux-i386".  It  can  be  queried using KrnGetSystemAttr function.
 * Bootstrap. It supplies the same string in its HostInterface. These strings must match, otherwise the kernel will refuse to start up. You can't errorneously launch Linux kernel on Darwin system.
 * unixio.hidd carries the same string inside it. When it starts up, it verifies itself with kernel.resource, ensuring match. When some external  module  opens  unixio.hidd,  it  can supply Architecture attribute.  unixio.hidd  will  compare the given string with its own such  string. In case of mismatch Intuition requester will pop up, and HIDD will refuse to instantiate its object.

Now, after  introduction  of  Android build, it became apparent that Android  is  not  Linux. Android's libc is not really binary-compatible with glibc. In order  to  distinguish  between them, introduced a rule: variant-ed system is different from variant-less one. If a variant is specified, arch-cpu  is  replaced  with variant-cpu. One exception is 'pc' architecture for legacy reasons. Introduced AROS_TARGET_PLATFORM  make variable which carries this designation. It is  also  included  into  version  string  of  all architecture-specific  modules,  so that the user can easily determine which version he has using Version FULL command. This is  what  actually  made  variant  bad for specifying just some descriptive  build name. If you for example build Linux-hosted distro, and use  variant as distro name, your modules will be compatible only with  other  your  modules. A user  of  your distro won't be able to upgrade,  for  example,  oss.library, from trunk. It will not work and will say "Incompatible architecture".

For now  this  does not affect native systems, but... Who knows what happens  in  future. Using variant  as  distro  name  this way would introduce  ambiguity. Distro's modules  will  be  versioned  as "arosmax-i386"  (for  example)  while  trunk ones will be versioned as "pc-i386".

Didn't know that variant was not originally meant for the purposes for which  i  use it. Described the usage well here. Can reimplement definition of AROS_TARGET_PLATFORM in such a  way  that  variant  name  won't  be  always used for platform designation, instead platform name will be explicitly set by configure script. But—enable-target-variant will still be used for selecting Android, iOS  and  Efika targets. And you won't be able to use it, will want to build Android-hosted distro.

introduced ELF  wrapper last year. It is used when AROS-targetted gcc is used for AROS. This is the default case for building on Windows and MacOS (since native host's compiler can't produce ELF files). This wrapper does a similar thing which AROS wrapper does with Linux gcc,  just  in  reverse  way. AROS wrapper makes Linux gcc generating relocatable binaries, and ELF wrapper makes AROS gcc generating static binaries. The purpose  is  to  get  rid  of  one  more ELF-targetted toolchain to be used as $KERNEL_CC.

Linux hosted exec
SC_ENABLE/SC_DISABLE is there to make sure the new task continues running in either Disable or Enabled state, depending on which state it was when it was last switched away. For example internally Wait causes task switch while in disabled state and when task is run again it must be in Disabled state.

SC_DISABLE and SC_ENABLE poke the "old signal mask" of Unix signal handler (context) used by kernel. So when the Unix signal handler "returns" the blocked Unix signals are set to that value.

The old code in arch/all-unix/exec/switch.c manually makes sure that SIGUSR1 is not blocked:

sigset_t temp_sig_int_mask; sigemptyset(&temp_sig_int_mask); sigaddset( &temp_sig_int_mask, SIGUSR1); sigprocmask(SIG_UNBLOCK, &temp_sig_int_mask, NULL); SysBase->AttnResched |= 0x8000; kill(getpid, SIGUSR1); sigprocmask(SIG_BLOCK, &temp_sig_int_mask, NULL);

There are probably ways to avoid this, if one really wanted.

A a small test which plays with enabling/disabling signals and prints out oldmask contents. One of discoveries was is that it's not used on PPC. I studied Linux includes and notices that there's another sigset_t in ucontext structure. In fact it was similar to x86-64 (i found that in sigcore.h.x86_64.src). And it should be used instead of oldmask.

So, actually PPC Linux port was broken. And i fixed it. After the fix i got similar freezes! I changed SC_DISABLE macro from:

sigfillset(&uc->uc_sigmask) to: uc->uc_sigmask = PD(KernelBase).sig_int.mask

And everything worked fine!

PD(KernelBase).sig_int_mask contains signals set which actually should be disabled by KrnCli. They do not include SIGUSRs, SIGINT and traps. So i disable only what really should be disabled. Everything is okay now.

Another nice testcase is cold reboot function. execvp'ed program inherits current signal mask, so if some of SIGUSRs appears disabled, another copy of AROS will freeze. This works especially well if combined with stackcheck test. stackcheck testcase causes stack check failure, which ends up in supervisor-mode Alert, which ends up in ShutdownA(SD_ACTION_COLDREBOOT). If something is wrong, AROS will freeze on restart.

We have -quick targets if we want to omit these large sets of dependencies. For example you can rebuild just dos by using "make kernel-dos-kobj-quick". Then "make kernel-link-base-quick" just relinks the kernel package (this is implemented by me for newstyle packaging, currently only Windows-hosted uses it).

If the hosted kernel now uses SIGUSR2, too, tell gdb to ignore it like SIGUSR1. In the .gdbinit file or manually at the gdb prompt.

handle SIGUSR2 pass noprint nostop

Hostlib_init is empty on UNIX because currently UNIX-hosted is modular and there's no HostInterface.

If it does not use libstdc++, then .cpp file scan be compiled by the standard gcc as it recognize C++ files extensions. ... Errrm, it surely need the new & delete functions... I did a small lib to compile TeXlive without using separate g++ compiler.

Restructure sams kernel code according to rom/kernel, i.e. there will be files like createcontext.c etc. If possible > code from rom/kernel will be used. The code  in rom/kernel was designed to be reusable as far as possible. Please also throw away arch/ppc-sam440/dos directory. Custom versions of  InternalLoadSeg_ELF  and  InternalUnloadSeg  are  there  only because   KrnRegisterModule   and   KrnUnregisterModule  have  old definitions and differ from their final versions. Custom runprocess.c is very old and needs to be removed, the job should be done by generic runprocess.c which relies on exec.library/NewStackSwap. I just didn't do it because  i  could  not  test  NewStackSwap on PPC (it's based on runprocess.c code so should work fine). Generic  runprocess.c  is  known  to  work  because  it works on all i386 ports and other UNIX-hosted ports.

Added some  more debug output to pci.hidd. Now it will report the result of CreatePool. Also changed some things in the implementation. Perhaps new build will even work. In fact it behaves very close to the original. Can you  tell  me  what  GURU  happens? Would be nice if you enable debugging in createpool.c and memory.c and send me crash log. Just to be sure. Can you enter bootmenu? Can you boot without startup sequence? Can you  boot  in  VGA/VESA mode? I committed video driver automatic selection  (worked  on  my  netbook). Answer, forgot that native ports use own exec_init.c, and PageSize was uninitialized there.

All hosted ports. On non-Linux OSes it's impossible to acquire address 4 at all. After hitting problem with entry point i introduced a new macro, AROS_ENTRY, to mitigate this.

There is  40KB minimum of stack space!!! This  is   defined   in   aros/ /cpu.h   (AROS_STACKSIZE). And task creation routines make sure that task's stack size is not less than this value. Such a  big  digit  comes from hosted AROS. UNIX signal handlers and X11 are stack-hungry. However this parameters appears to be hardcoded. May be  this should be adjusted on per-system basis? I would suggest to add  a kernel attribute (for KrnGetSystemAttr which would return this value). So it would not be that big for native OS. In some ways it could be tuned specifically for m68k needs. 40KB stack is actually way to small considering majority of our software comes from unix world. AFAIK native g++ requires *at least* 256 KB stack and any 3D game requires *at least* 512KB stack.

*nix 'Hosted' Environments
AROS Shares common hardware and driver support for Linux and BSD.

There is  no  more  boot/aros-unix file. There is boot/AROSBootstrap instead which you should run.

Keyboard / Mouse:

Currently the driver instantiation is done during x11gfx.hidd initialization, which  happens  before  dosboot makes its assigns, so DEVS: simply does not exist (even SYS: does not exist). Disk-based part was created for DEVS:Monitors, similar to GDI driver. It is responsible for loading X11 keymap now. Improvement: now you may specify any keymap file name in icon tooltypes. Of course it will look up DEVS:Keymaps/X11/keycode2rawkey.table by default if you don't specify anything. The basic idea was to move keymap buffer and presence flag into librarybase. Disk-resident part  simply  opens the driver library and loads keymap file right into its base. Also disk-based part contains code for creating additional displays, but  it's  expected not to work because of bad driver design. The call is commented out with notes.

GFX Chipsets:
 * x11.hidd: x11 accelerated graphics driver.

Audio Chipsets:
 * oss.audio: plays audio through the hosts OSS drivers.

In theory oss.library's funcs.c would need to be compiled in such a way that the O_WRONLY, O_NONBLOCK, etc. are taken from the host (Unix) includes, not from AROS includes. Otherwise it depends on luck (O_ defines having similar value on AROS and the Unix OS in question, or not) if it works or not. IMHO this should only be done via configure/mmakefile's passing the necessary info in.

At what rate does VERTB interrupt happen now?

50 or 60 Hz. User-specified (by vblank=NN command line argument). In fact you can specify any value.

How it used to be:

VERTB: always 50 Hz TIMERTICK: 100 Hz (default, could be changed with "-t" argument when starting AROS)

Some things like that AHI driver do not work well if it only happens at a rate of 50 Hz. Also a general timer precision of 50 Hz is bad. That's what the TIMERTICK hack fixed.

 * Instead of  TIMERTICK  hack there's kernel.resource API now. And timer  still  can  be  set to 100 Hz. Just run AROS with 'eclock=100' command line argument.
 * This solution is not future-proof. In fact timer.device needs to be  rewritten  to measure actual intervals, similar to native drivers. In this case timer interrupt will not have stable frequency at all. In order to be future-proof i'll further rewrite the driver. It needs own timerequest,  set  to  1/1000 sec for example. This will cause current timer.device  to  reply  in  a  minimum  interval (specified by eclock argument), and future timer.device will really reply in 1/1000 sec.

It makes sense to implement 'arguments' keyword in bootstrap's config  file. For now you can write small script which runs AROS with eclock=100 argument if you need to. I would suggest  more clean solution. Modify configure.in to supply -nostdinc with  $(KERNEL_INCLUDES) (where compiler's include path is detected). Anyway $(KERNEL_INCLUDES) is used together with -nostdinc everywhere,  this  way  you  would  kill  two  rabbits in one shot. If$(KERNEL_INCLUDES) is empty, -nostdinc will also not be supplied.

Network Chipsets:

 * tap.device: networks through tap.

It seem pci.hidd is no longer present in linux-i386. The following code used to work about 4 month ago: if (!OOPBase_DRM) {       if ((OOPBase_DRM = OpenLibrary("oop.library", 0)) == NULL) {           /* Failure */ return -1; }   }

HiddPCIDeviceAttrBase = OOP_ObtainAttrBase(IID_Hidd_PCIDevice);

if (!pciBus) {       pciBus = OOP_NewObject(NULL, CLID_Hidd_PCI, NULL); if (!pciBus) return -1; }

Now, the call to OOP_NewObject(NULL, CLID_Hidd_PCI, NULL) returns NULL. The liblist command also does not list pci.hidd anymore. Now they  are  disk-based modules. You can either load them manually using  LoadResource   command   or   add   to   kickstart   list   in AROSBootstrap.conf.

Remember   that    you   need  not  only  base  pci.hidd,  but  also pcilinux.hidd which is the driver itself. I do  not include them by default because Linux PCI driver is a hack by nature and it's easy to screw up the system using it (by attempt to use the hardware which is already in use by Linux).

All hosted ports. On non-Linux OSes it's impossible to acquire address 4 at all. After hitting problem with entry point i introduced a new macro, AROS_ENTRY, to mitigate this.

Segmentation fault
This is the log:

[Bootstrap] entering kernel@0x7f6.... Segmentation fault

The debugger doesn't tell much, but addresses like 0x00007ffff76c509f are strange because I have only 4GB RAM.

gdb) run [Bootstrap] entering kernel@0x7ffff76c5000...

Program received signal SIGSEGV, Segmentation fault. 0x00007ffff76c509f in ?? (gdb) findaddr 0x00007ffff76c509f Searching in the loaded modules... Searching in the resident list... No struct type named Resident.

 * 1) 0 0x00007ffff76c509f in ??
 * 2) 1 0x00007fffffffdfc0 in ??
 * 3) 2 0x0000000000000000 in ??

Virtual addresses have nothing to do with real amount of physical memory!

The problem is, AROS x86_64 kernel is compiled without -mcmodel flag set, therefore it defaults to -mcmodel=small. It means, all code and data has to reside within first 2GB of address space. This is not the case here, so it crashes/segfaults or does any other strange things.

There are two solutions - either, compile whole x86_64 aros with - mcmodel=large and suffer from small speed penalty. Large model allows both code and data to reside *anywhere* within the address space, some PC-relative addressing cannot be used in that case. Gcc will make all branches 64-bit large and, therefore, a bit slower.

Tried (gcc-4.3 -m64 -mcmodel=large). No change.

mcmodel=large generates more traffic on CPU's bus lines and consumes much more cache.

Every loading of data (mov %reg,addr) is replaced by movabs %reg,addr, increasing the instruction size by four bytes. PC-relative access to sections other than current one is not existing anymore and replaced by absolute movabs instruction. Every single call to any subroutine (call function) is replaced by a pair movabsq %reg,function; call *%reg. But, as you have mentioned, the cpu fetches most things from its cache(s) - so the implication that we will "suffer" because of using it is at best misleading imho, and also a bit scare-mongering (speed wise of course - obviously binary size will increase).

In general I have nothing against compiling whole AROS with mcmodel=large, which is anyway the only sane way for 64-bit system with single address space for all processes. I just warn about the consequences :)

Another solution is to allocate the memory for AROS within first 2GB of address space. It can be done with anonymous mmap and flag MAP_32BIT. Please check, i added the flag. Sorry for dropping it, i didn't know why it was there. P.S. Fix for gdb support is on the way. Infrastructure is ready, need only to update _gdbinit script.

since the new genmodule inlines don't know how to handle the RA/RB idiom for 64-bit parameters. Actually I implemented this patch a long time ago (before your m68k QUAD fixes) after discussion on the maillist to solve two things:
 * In compile warnings/errors during a library call no clear function name was present so it was difficult for programmers to find out what is wrong.
 * On i386 libbase is passed as first argument causing a argument number in compile warnings and errors was of by one, confusing programmers even more.

fixed them by modifying Exec/Init to strap to an AllocMemed area for its stack, but sonic removed that common code. UNIX-hosted kernel should add its stack area to memory lists now.

If a clean build of linux-i386, still get the same asserts:

/data/deadwood/tAROS/AROS/rom/oop/./setattrs.c, 71: bad pointer: attrList = $bface5fc /data/deadwood/tAROS/AROS/compiler/alib/./coercemethod.c, 59: bad pointer: message = $bface6a8 /data/deadwood/tAROS/AROS/rom/oop/./setattrs.c, 71: bad pointer: attrList = $bface600 /data/deadwood/tAROS/AROS/compiler/alib/./domethod.c, 60: bad pointer: message = $bface6a8 /data/deadwood/tAROS/AROS/compiler/alib/./coercemethod.c, 59: bad pointer: message = $bface658 /data/deadwood/tAROS/AROS/compiler/alib/./coercemethod.c, 59: bad pointer: message = $bface658 /data/deadwood/tAROS/AROS/rom/exec/./doio.c, 54: bad pointer: iORequest = $bface64c /data/deadwood/tAROS/AROS/rom/exec/./putmsg.c, 56: bad pointer: message = $bface64c /data/deadwood/tAROS/AROS/rom/exec/./getmsg.c:65: bad pointer: msg = $bface64c /data/deadwood/tAROS/AROS/rom/exec/./doio.c, 54: bad pointer: iORequest = $bface64c /data/deadwood/tAROS/AROS/rom/exec/./putmsg.c, 56: bad pointer: message = $bface64c /data/deadwood/tAROS/AROS/rom/exec/./getmsg.c:65: bad pointer: msg = $bface64c

You configured AROS with—enable-debug=messages. This is why you get these additional assertions. Can you  run  ShowConfig  and tell me its output (together with some assertions  from  the same run)? Perhaps 3K is simply not enough.

Other
AMD [http://www.woodmann.com/collaborative/knowledge/index.php/Super-secret_debug_capabilities_of_AMD_processors_! debugging] and here.

This means  i  need  to get rid of static linking with UNIX libraries in all AROS modules.

Currently i've  almost  done  it  in  all  AROS  core modules except exec.ibrary  and  kernel.resource (they will be the last ones, because doing  this  actually  means  switching  to  modular  kickstart). I've rewritten emul.handler and oss.library, and i'm also going to do this with tap.device.

However i don't have much time and i plan to leave out the following (at least temporarily):

1. uxser.hidd (unix-hosted serial port HIDD) 2. uxpar.hidd (unix-hosted parallel port HIDD) 3. lxpci.hidd (PCI bus driver) 4. linuxfb.hidd - Linux framebuffer driver. 5. unixio.hidd - the component for handling async I/O.

First, I think unixio.hidd should be deprecated. Kernel.resource has IRQ API which allows to process SIGIO in a  very clean way. This makes unixio.hidd redundant. emul.handler SIGIO  code  may  serve  as  an example. I dislike  unixio.hidd  because  it  drops  performance  by gathering all requests in a single place, and introduces a timer-based polling  loop  on  Linux  (i  believe  not  all devices actually issue SIGIO).

I thought  for  a  while,  but  i  didn't  find  any reason to leave unixio.hidd. First i  thought  that  it  could be a nice abstraction layer,   but  it  was  a  wrong  suggestion. After comparing  several UNIX-alike  OSes  i  came  to a conslucion that this will not give any abstraction. This happens  because  all structures values  which  needed to be supplied  to  operations  like  ioctl,  and even host error codes, are strictly  dependent  on  current host. Different UNIXes are not binary compatible, so  we  still need to have a personal version of a driver (for example  oss.library) for all hosts we run on. It's not possible to interchange them.

So i suggest just to remove unixio.hidd. Is there anyone against?

Other mentioned  components  require at least reengineering. linuxfb hidd does  not work on my system (just crashes), and looks like noone tested  it,  so i consider it abandonware. Of course i will not delete it from the tree, just someone needs to pick it up and take care about it. PCI driver will be fixed very soon, it's very easy to do. Just i believe noone is actively using it at the moment and it can wait. Serial and  parallel  drivers also will not be dropped. I'll rewrite them, just  i  consider this a low priority task. So this is why i am asking -  is  there  anyone actively using these drivers? Will anyone suffer if for some time they will stop working?

The 'bad pointer' addresses are due to TypeOfMem(ptr) in the ASSERT_VALID_PTR macro returning 0. TypeOfMem is return 0 because the memory was never AllocMemed from a known memory region. The memory was never AllocMemed because it is on the stack of the AROS Bootstrap's main. Solution is have whoever is maintaining AROS Bootstrap add a MemHeader for the strap's stack to the kernel as an unallocable memory segment.

Just running ./boot/AROSBootstrap of linux-i386. These assertions appear before the: [DOS] DosInit: InitCode(RTF_AFTERDOS) Perhaps you  have some debugging options enabled. Well, doesn't matter, the  problem  should  go  away now. I backported adding boot stack region to memory list.

I think there are still some problems with gdb support in the new linux-i386. In some applications (for example ScreenMode preferences) if I put asm("int3") in the code and the try to loadseg the symbols, gdb does not complain in any way but the symbols are not resolved (I just see function name with no line number). On the other hand, other things like muimaster or intuition have their symbols loaded correctly. Check kernel modules with objdump, perhaps dwarf2 information gets stripped away during relinking. Are modules listed correctly (with paths) in modlist output?

Keyboard mapping changing on Linux hosted when switching desktops, running Linux hosted on Ubuntu, and my laptop doesn't work well with the default keymap (cursor keys don't work for starters), so I've made a custom keycode2rawkey.table file, and that works great. Until I change desktops and change back to AROS. When I change back, the default keymap is used instead of the one I've copied to Devs/Keymaps/X11/keycode2rawkey.table

loadseg however fails to load information. "modlist" lists the DISK based modules which were loaded so far. AFAIK the ROM modules were always available "out of the box" with debug information. Has something changed? Now they  are  also  loaded  from  disk by the bootstrap. They are not linked statically any more. But there are two lists now instead of one.

As far as I remember for emulation to work, your driver needs to be a frambuffer one (aHidd_Gfx_NoFrameBuffer = FALSE) and you need to implement Show method to call super method.

This information is obsolete. The limitation was removed  since  that  time, now emulation works with NoFrameBuffer drivers too (was needed by VESA).

I'm wondering because I'm compiling for AROS using the Linux cross-compiler from the AROS SDK and my app is heavily using multi-threading and calls functions like malloc and free from lots of different threads. However, everything is working fine.... shouldn't it crash pretty soon if the C runtime is not thread-safe!? In Linux, if you compile with -pthread then a thread-safe version of malloc will be put instead of the standard one (which is not thread-safe). I don't know if this applies to AROS also... There is no PThread library for AROS. However, parts of the C runtime library are in shared libraries which, by nature, are reentrant code. Only the parts of the C runtimes that are statically linked only can be thread-unsafe, if I'm not mistaken.

Every time i check out AROS svn asks me for my login and password. Additionally it warns me that credentials will be stored unencrypted. How do  AROS  nightly  build machines work automatically? Do we have some predefined read-only account in our SVN? Some svn client remembers user and password. I think older svn clients store unencrypted. SVN on Mac OS X will make use of Keychain which works automagically from the graphical UI. If you want to make use of the Keychain from ssh then you first need to unlock Keychain, with the following command: security unlock-keychain ~/Library/Keychains/login.keychain

And how  will  my machine upload binaries? I believe i need some ssh certificate for it? You have to create a ssh key pair on your machine and enter your public key inside your sourceforge user account. You probably need to search a bit on sf.net to find more details about how all this works. You also need to provide your sourceforge user name to the nightly build configuration file. IRC you also need to create a link inside your home directory on sourceforge server like this:

aros -> /home/groups/a/ar/aros

UNIX-hosted kernel should add its stack area to memory lists now.

Does anyone  know  what's  wrong? I just added i386-darwin build to download-descriptions. I see that binaries are uploaded ok. Even more strange is  that for example German page failed too, however i didn't change it. Can anyone help? I'm not familiar with how our web site works. The page is repaired. Each time you add a new package, the page needs to be rebuild. I'm doing the rebuilds, since automatic rebuilds are long dead. If you add a new package, just mail me to be sure I rebuild the webpage.

I hit the same problem as 64-bit Linux-hosted - mmap allocates memory beyoun 2GB space. And - there's no MAP_32BIT. Does anyone know what to do? Is there any workaround/replacement for MAP_32BIT on Darwin and BSD ? I studied  Darwin  documentation,  they use small PIC code model for x86-64  binaries. Looks like this saves them from this problem, and they don't need explicit low memory? What *BSD guys do with this? Or the only thing we can do is changing AROS 64-bit code model? At least for some flavors. I know, this is not good, however perhaps there's no way round.

Memory Pooling
For such  architectures you could specify small fictional page size. Perhaps  they  could  also  use  another  implementation  of  kernel allocator   (similar   to   current   AllocMem/FreeMem). Current implementation will  have increased memory usage with small pages (it uses  one UBYTE per page for memory map). Alternate implementation can store  administrative  information  in  the  managed  memory itself. I didn't do  this  in my implementation because it allows to completely disable access to all unallocated pages.

If the kernel returns page size of 0, MMU is assumed to be missing. exec then falls back to MEMCHUNK_TOTAL chunks. I hope this is acceptable. With this setting new pools implementation behaves EXACTLY  in  the  same  way  as  old  one  with threshSize == puddleSize. I hope  it's  not  a big loss. I can tweak it further to handle threshSize,  just  i think it's not really needed.

Also i  expect  performance boost in FreePooled. Can you benchmark this?

The rest  will be done in kernel.resource. It will have two versions of memory  manager:  MMU-aware and MMU-less. MMU-less version will be old AllocMem/FreeMem  implementations from exec. Don't bother for now, i  already  have an idea and i'll do it myself.

I suggest  you to have both versions in m68k port (unless you really want  to save ROM space). Amiga can have 68030 or better, in this case AROS will be able to detect it and make use of it.

This is still open to the discussion. I intentionally committed only pools. If you  look  carefully, you'll see they still work on top of AllocMem/FreeMem. Kernel's allocator  is  ready  and even works, however i wanted to emerge it all step-by-step. I agree that on such a low level it's rather simple to break something.

The idea  behind  the  new  system:  puddle  size  is always integer multiple  of page size. The rest of changes are explained in the code, i commented it carefully. I hope you'll like some of ideas. It should be faster than the old implementation.

This is  done because after this we can assign protection attributes to   pools. There  can   be   for  example  executable  pools  and non-executable pools.

Puddle  size   is   integer   multiple   of  page  size. New kernel.resource allocator is page-based.

As to badly  behaved software, perhaps there can be some way to handle  this  in  early  startup  control. Yes, it can be difficult. Still open  to  experiments. MMU is good, it's not a good idea just to throw it away.

Missing Zune class Application.mui but it's inside our muimaster.library. Check workbench/libs/muimaster/classes/application.c. its a built-in class.

BSD sockets
/master-linux-i386/bin/linux-i386/AROS/Development/include/sys/socket.h:288: error: expected specifier-qualifier-list before ‘u_short’

I fear that the same thing will happen for all network software. Can we reconsider this change? I would prefer it that default is only POSIX and other legacy UNIX has to be enable by defines. I agree that network code should be able to compile without defining __BSD_VISIBLE if no legacy features are used. But it should be done by making our net includes POSIX compliant.

The software code I worked with actually uses u_char/u_short types. If we remove them completely the code will stop compiling at all. Code using u_char/u_short should need __BSD_VISIBLE define to make it work to indicate it needs to be made modern. But it should be properly documented in some porting HOWTO.

I think it would be beneficial for 3rd party devs to have their software compiled without modifications instead of having to search through our headers to learn how to make networking work.

During my split of I did more separation so it would help if you could wait until that is ported. I did not do much on the net includes yet though. This is put on the TODO as I think it does not have an ABI impact; only compilation impact. BTW: half of the remaining compiling errors with test/cplusplus/headertest.cpp (can be build with make test-cxx) are coming from the net headers or sys/types.

Can we re-enable defining __BSD_VISIBLE for now until your work is brought to trunk? I would vote at least for V0 branch as it will never be "fixed" by your ABI work. I can live with enabling again only on V0.

I think it should normally be provided by the 'compile' environment and not in some kind of header file. That's one of the reasons I would like to stick to -D__BSD_VISIBLE. You could try sys/types.h

Errors
complains about video and throws and error. [Bootstrap] entering kernel at 0xf73e6000...

DisplayPlanes = 24 DefaultDepth = 24

BITS PER PIXEL = 24

[I2C] Init [ATI] Init [drm(INFO)] Failed detecting card for VendorID: 0x10de [KRN] Trap signal 11, SysBase f43e71f0, KernelBase f43e7f18 SP=f4cfe4ac FP=f4cfe4f8 PC=00000000 R0=f43e71f0 R1=00000000 R2=00000000 R3=00000006 R4=f460e720 R5=f4d14f20 FELSunxi DoMethodA ConfigChangedEvent bash-4.2$

to remove the native drivers, getting a little closer, copying the drivers from the nightly gets it looking a little more normal but now I get a Software failure in X11.

Icaros desktop is based on ABI-v0-on-trunk but, it would require abi v0 hosted.

Debugging
I tested only modList command, seems to work correctly. Please check  and fix (if needed) the rest. I hope the code is clear enough. Testing with ROM and DISK modules work. modlist lists them, codes lines are resolved, global and local variables are resolved.

If you talk about PIC and GOT, will this also mean we can have shared objects?

We may be able to, but please please don't. Don't copy bad design decisions from OS4. OS4 programs using shared objects have the same startup slowness as on other OSes (Linux, Windows, ...).

+1, I would really prefer not to mix .so concept with native AROS .library concept.

Yes, small model assumes both code and data are in the lowest 2GB area. In such case, memory loads and jumps are done as PC-relative, with +-2GB offset from current instruction pointer.

Yes, the other models are:

 * medium - code and data resides in lowest memory region, large data may be *anywhere* in the address space
 * large - code and data may reside anywhere in the address space
 * kernel - code and data reside in topmost 2GB of address space

Please note the code and data location refers to the sections of ELF file. All allocations made by the code itself, as well as stack pointer, may be anywhere in address space for all models.

I also would like to get an idea of the implications on code size, stack usage, speed etc. of the different code models.

Additionally i  can  make  use  of ELFOSABI_AROS definition (ELF ABI number reserved    for    AROS). However  this   will  impose  a requirement to use AROS version of binutils for linking, Linux ld will not do any more.

I always would have liked to make AROS programs real ELF programs (with relocation info still present though) but I also think this should be something for ABI V1.

Ah, come on! We could extend the internalloadseg_elf with ease :-D

+1 for real executables :)

Sure I do ! This was one of the big things I have done in the ABI_V1 branch. The data is stored in an AVL tree. Is this soft of "handled in shared module per caller task storage". If so, could you point me to the codes in SVN?

It's done in genmodule. You can have different options for a library. If you don't specify only one libbase is generate and it is returned for each OpenLibrary call. If you specify peropenerbase you get a base for each OpenLibrary call. If you specify peridbase a separate base for each task. It takes the Task pointer together with the return addr as id to decide if it needs to generate a new libbase (Like how arosc.library did it before). It is called peridbase because you could overload the macro that returns an id. I may removed this feature and just name the option pertaskbase when I merge it in the main branch.

when I click on "Residents" in Scout it crashes. Unfortunately, add-symbol-file doesn't work, so I can't provide a back-trace. (Tested on linux-i386). Scout is build using build_program macro which as I mentioned earlier has problem with providing debugging symbols.

What you can do is:

 * place TARGET_STRIP := $(STRIP) before the build_program macro line
 * once in gdb, first do a loadseg on an address at bottom of stack which will load debugging symbols for kernel then do bt and again try loading debugging symbols for top of stack. I noticed that this procedure is sometimes needed with executables (while I never had to do it like this with libraries for example)

try changing line 95-:

extraoptions="--bindir=$(CROSSTOOLSDIR)" to extraoptions="--bindir=$(CROSSTOOLSDIR) --with-gmp=$(CROSSTOOLSDIR)"

Trac
After some fighting with Plesk suexec and apache I have now a first setup for trac. You can find it here: http trac stafverhaegen be/trac. You can have a look around. Actually I want to provide it as http trac aros org/trac and you can already to that if you put the IP in your /etc/hosts file (Windows users have find out to do it themselves):

83.169.4.30   trac aros org

Did install a recent version of trac as the default 0.10.something did not like. Currently no login is possible but you can already have a look at the subversion source code browser. This is a static mirror of the main trunk which is not kept in sync ATM. (make a new mirror and sync trac in the future)

Next things want to tackle:

 * Login manager setup so that people can register using the login manager trac plugin. As both trac and svn seem to use normal Apache password files other managers could be used. Anybody any good proposal ?
 * Set up svn server so people can access it.

CD2: FileSystem    = cdrom-handler Device        = Home:~ LowCyl	      = 0 HighCyl	      = 0 Surfaces      = 1 BlocksPerTrack = 1 DOSType	      = 0x454D5500 Activate      = 1

CD0:	FileSystem    = L:cdrom-handler Stacksize     = 10000 Priority      = 5 GlobVec       = -1 Mount         = 1 BufMemType    = 0 Device        = scsi.device Unit          = 1 LowCyl        = 0 HighCyl       = 0 Surfaces      = 1 BlocksPerTrack = 1 DosType       = 0x43444653 Control	      = "ROCKRIDGE LOWERCASE" /* see below */

title: Aros/Platforms/Installing on *nix


text:
Cookbook:MSG

| Basic foodstuffs | Spices and herbs

MSG, or monosodium glutamate, is a controversial salt of sodium and the naturally-occurring amino acid glutamate, refined from naturally occurring glutamate. The natural form of glutamate is found in many foods, and when 'free' (not bound to a protein) it enhances savoury flavours, which is called umami in Japanese. MSG is a chemically refined form of glutamate, bound to salt.

Since MSG is a sodium-containing salt, many of the health concerns associated with table salt also apply to MSG, but many people have reported additional negative experiences. Some of these apparently-MSG-specific problems are experienced as a short-term 'reaction', whereas most concerns about salt are over a longer time frame. Many authorities disclaim health concerns over MSG, and on the other hand, many consumers of the substance claim first-hand experiences which resound widely. It may therefore be inferred that a certain amount of disinformation or misinformation exists regarding this widely-used product. Care should be taken in evaluating the issues surrounding MSG, and sensitivity provided to those who believe their real negative experiences are caused by the substance, whatever may be the technicalities.

Many people with migraine headaches report MSG as a trigger substance.

The use of MSG can also actually reduce total sodium content in food, because the food may not need as much table salt to taste good. A small amount of MSG might typically reduce salt usage by 20% to 45% without loss of flavour, and this might be seen as a health benefit, if no negative effects occur due to MSG.

Glutamate in some form is found naturally in seaweed, in fermented soy products such as miso and soy sauce (1.0%), and especially in yeast extracts like Vegemite (1.4%) and Marmite (2.0%). Small quantities are also present in tomatoes, mushrooms, and Parmesan cheese (1.2%).

A traditional Italian meal with tomato sauce and lots of Parmesan cheese can contain far more glutamate than would normally be added as MSG to Chinese take-out food.

Glutamate being produced for refinement into MSG is most-frequently commercially produced via fermentation; the result of this stage of the production process is 100% identical to the glutamate found naturally in many foods. Another path is by hydrolisis of gluten, e.g. from wheat.

"The crude glutamic acid produced in this process is then filtered, purified and converted by neutralisation into monosodium glutamate. After additional purification, crystallisation, drying and sieving, monosodium glutamate has the form of pure white crystals ready for packing and use."

Food products sometimes show ingredients like "autolysed yeast" and "hydrolysed protein", without necessarily using the word MSG or the recognised numeric codes (E621, HS29224220) on the label. These ingredients may in fact contain MSG, or at least free glutamate. There is some confusion as to whether health concerns correlate with free glutamate as well, or just with MSG. It is unlikely that protein-bound glutamate is problematic for the vast majority of people, as this would be absolutely crippling.

MSG often is used by adds extra flavour to snack foods, frozen dinners, and instant meals, for example the seasoning mixtures for instant noodles.

Like table salt, MSG tends to enhance our perception of other flavours. MSG is widely used in Asian cuisine and in chicken recipes. Usage is a pinch of MSG, much the same as with table salt.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Cookbook:MSG