Aros/Platforms/Installing on *nix
Introduction
editIcaros 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
editTo follow
i386-linux and i386-freebsd
editThe 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
edit- 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 [1] [2] [3].
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:
- download the ISO
- extract the ISO to get the files
- download http://download.aros3d.org/software/linux.tar.gz
- extract the contents to /Arch, you should end up with Arch/linux directory
- $ ./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).
Build System(s)
editMake native AROS which builds hosted
editThe 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
editABIv0 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.
Building
editExtracting
editSince 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:
> tar -vxjf AROS-<version>-i386-<platform>-system.tar.bz2
If you downloaded the contrib archive, you may want to extract it too:
> tar -vxjf AROS-<version>-i386-all-contrib.tar.bz2
Build
editUbuntu building
The generic Debian part is pretty much
- Call debootstrap
- Feed this or similar to debian-set-selection (debootstrap gives you just POSIX locale by default):
locales locales/locales_to_be_generated multiselect en_GB.UTF-8 UTF-8 locales locales/default_environment_locale select en_GB.UTF-8
- 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
edit./configure
make
./configure --enable-debug=all --enable-crosstools
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.
Binaries
editRecent 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
> startx -- +bs
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:
Section "Device"
Identifier "Matrox G450"
Driver "mga"
BusID "PCI:1:0:0"
Option "backingstore"
EndSection
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:
Section "Device"
Identifier "Default device"
Option "Backingstore"
EndSection
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
> cd AROS
> boot/AROSBootstrap --fullscreen -m 256
-h -m <size> -M -t <value> --help --memsize <size> --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
- make sure the logs end up in the emails sent to the AROS mailing list
- Send to the mailing list your ./configure line, the ./configure output, and the config.log file if it fails
- make -s query if you can get past configure
Building ISO
editIf 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
Configuring
editSound on Hosted
editIt 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).
- apt-get install alsa-oss
- modprobe snd_pcm_oss
- 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)
# LIQUORIX HOW-TO: sudo nano /etc/apt/sources.list # ADD LINE: deb http://liquorix.net/debian sid main # 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 # REBOOT # 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
edit#!/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.
#!/bin/bash # tap unit number. This should match the UNIT= parameter in # AROSTCP/db/interfaces # IP address for the tap interface. Inside AROS, this will be your default gateway. # NOTE: Make sure it is in a different network than your Linux host. tap_ip=192.168.254.254 # create the interface #iface=$(sudo ip tuntap add name aros$tap_unit mode tap) iface="aros0" masq_iface="enp2s0" sudo ip tuntap add name $iface mode tap echo "Created tap device: $iface" # bring it up echo "Setting $iface to IP adress $tap_ip and bringing it UP" sudo ifconfig $iface $tap_ip up sudo chmod 666 /dev/net/tun # turn on NAT # (NOTE: make sure that the network interface you are using is named "eth0". # 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 # Turn on IP forwarding sudo sysctl net.ipv4.ip_forward=1 # start AROS cd ~/AROS ./Arch/linux/AROSBootstrap # aros has finished, so kill the interface sudo ip link delete $iface # maybe turning off routing is a good idea as well sudo sysctl net.ipv4.ip_forward=0
How to mount some device or directory (for example a dvd-drive) as a drive under aros hosted?
editAdd 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 #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
editan 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:
#!/bin/bash # tap unit number. This should match the UNIT= parameter in # AROSTCP/db/interfaces tap_unit=0 # IP address for the tap interface. Inside AROS, this will be your default gateway. # NOTE: Make sure it is in a different network than your Linux host. tap_ip=192.168.254.254 # create the interface iface=$(sudo tunctl -b -u `whoami` -t aros$tap_unit) # bring it up sudo ifconfig $iface $tap_ip up sudo chmod 666 /dev/net/tun # turn on NAT # (NOTE: make sure that the network interface you are using is named "eth0". # Otherwise adjust the following line to your needs.) sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Turn on IP forwarding sudo sysctl -w net.ipv4.ip_forward=1 # start AROS cd ~/AROS ./boot/AROSBootstrap # aros has finished, so kill the interface sudo tunctl -d $iface &> /dev/null # maybe turning off routing is a good idea aswell sudo sysctl -w net.ipv4.ip_forward=0
- 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
Android and others rPi
editx86
editARM
editPowerPPC
editIn 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.
References
editThe ELF Header starts off grand, with the x7f magic and 16-bytes including null terminated "ELF" marker. From there, it seems to deteriorate as the ELF header lacks a program header which indicates the modules are 'relocatable' and in need of link-edit then "loading". Ignoring this to look for section headers we use the shoffset entry and it points to 0x36bd4 (offset line 0x0020), but after a (OS X) "hexdump -C" of the aros-bsp-darwin module, this seek-offset into the file doesn't seem to follow the expected ELF Section Header format.
- AROS kickstart modules are relocatable. There's no boot.img.
- MorphOS kickstart is loaded at some specific address. You can't do this on hosted, and there's no need to do this on native.
- Relocation is performed by the bootstrap. See its ELF loader code. It's the same as InternalLoadSeg_ELF(). The ELF has ET_REL type, this is enough to see it's relocatable.
Linux hosted exec
editSC_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>/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
editAROS 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
editThis 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. #0 0x00007ffff76c509f in ?? () #1 0x00007fffffffdfc0 in ?? () #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 AllocMem()ed 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
editThis 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 AllocMem()ed from a known memory region. The memory was never AllocMem()ed 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
editFor 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
edit/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
editcomplains 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
editI 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
editAfter 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 */