Saturday, December 05, 2009

Qt 4.6.0 on AVR32 and it’s bugs: Error: symbol `.L987' is already defined

Qt 4.6.0 is out – there is only one source archive now, “-everywhere-“, which includes the linux embedded version also. I tried to build it for the avr32 embedded system; but, a nice compiler error prohibited it.

Error: Symbol `.L987' is already defined

compiling painting/qbrush.cpp
{standard input}: Assembler messages:
{standard input}:5426: Error: symbol `.L987' is already defined
{standard input}:5544: Error: symbol `.L1012' is already defined
{standard input}:6236: Error: symbol `.L1129' is already defined
{standard input}:6353: Error: symbol `.L1154' is already defined
make: *** [.obj/release-shared-emb-avr32/qbrush.o] Fehler 1

Googling it

This error is usually based on using “inline” and “asm” statements in combination – see http://archives.devshed.com/forums/development-94/new-assembler-message-symbol-is-already-defined-1269938.html, e.g. It looks like an internal compiler error, but is usually a coding error.

“This is not a gcc bug, you cannot declare a label in an inline-asm that is going to be exposed.”

“Is there a reference of some sort? I was unable to find one with google.”
”No, just a general rule as inline-asms will be copied when inlined or cloned. What is happening here is clon(n)ing is happening so we generate two copies of that function.”

So, there is some inline method that contains assembler code – the code is duplicated b/c of the inline interpretation – and thus, the assembler labels are duplicated.

Different Compiler?

I do not think that Nokia explicitly inserted the inline+asm-combination. It is probably some gcc optimization. Unfortunately, it is not possibly to use a different compiler than the one provided by atmel in “buildroot-avr32-2.3.0” (http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4401)

Using built-in specs. Target: avr32-linux-uclibc Configured with: /avr32/buildroot-avr32-v2.3.0/toolchain_build_avr32/gcc-4.2.2/configure --prefix=/avr32/buildroot-avr32-v2.3.0/build_avr32/staging_dir --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=avr32-linux-uclibc --enable-languages=c,c++ --enable-__cxa_atexit --enable-target-optspace --with-gnu-ld --with-gmp=/avr32/buildroot-avr32-v2.3.0/toolchain_build_avr32/gmp --with-mpfr=/avr32/buildroot-avr32-v2.3.0/toolchain_build_avr32/mpfr --enable-shared --disable-nls --enable-threads --disable-multilib --enable-sjlj-exceptions --disable-libmudflap --disable-libssp --with-build-time-tools=/avr32/buildroot-avr32-v2.3.0/build_avr32/staging_dir//bin Thread model: posix gcc version 4.2.2-atmel.1.1.3.buildroot.1

Change Optimisation Level

So, we have to find a way to avoid the above error. If it is an optimization problem, let’s just use some other one.

goto src/gui, patch Makefile, add –O to the end of CXXFLAGS, call make .obj/release-shared-emb-avr32/qbrush.o, and it runs through – now, you can remove the –O again, and compile the rest of it.

Alternatively, remove the @ in the beginning of CXX = …, call make, get the avr32-linux-uclibc-g++ statement, and add –O there.

Using –O3 does not work – then, the inlining is done even more often, resulting in triple definitions (or rather duplicate errors about duplicate defintions).

No idea where the error stems from, but at least, Qt 4.6.0 now compiles.

package/qtopia4/qtopia4.mk

Btw … to get that far, a few more changes are necessary. Those are, in short, in package/qtopia/qtopia4.mk:

QTOPIA4_VERSION:=4.6.0
QTOPIA4_CAT:=zcat
QTOPIA4_SOURCE:=qt-everywhere-opensource-src-$(QTOPIA4_VERSION).tar.gz
QTOPIA4_TARGET_DIR:=$(BUILD_DIR)/qt-everywhere-opensource-src-$(QTOPIA4_VERSION)
and you have to remove all the mouse driver statements – I have no idea how those are configured, now … most of them compile automatically, I may still be missing the tslib driver
### Mouse drivers
# remove all of them for Qt460
ifeq ($(BR2_PACKAGE_QTOPIA4_MOUSE_PC),y)
[...]
QTOPIA4_CONFIGURE += -no-mouse-qvfb
endif

Fixing 4.5.x Colour Depths

The previous version(s), 4.5.x, had a bug concerning a code optimisation that relied on non-aligned access – OK for i386 and followers, not OK for many other systems. Some were explicitly excluded, avr32 was not. The bug triggered when converting bitmaps between 24 and 16 bit colour depth, e.g., when connecting via vnc, or when using certain display depths directly.
See http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=79740 about fixing qt_blend_argb24_on_rgb16() in qblendfunctions.cpp.
Seems that fix is in 4.6.0, at least.

PS: QtScript

I get a compile error in QtScript – some problem with pthread_getattr_np:

compiling ../3rdparty/javascriptcore/JavaScriptCore/runtime/Collector.cpp
../3rdparty/javascriptcore/JavaScriptCore/runtime/Collector.cpp: In function 'void* QTJSC::currentThreadStackBase()':
../3rdparty/javascriptcore/JavaScriptCore/runtime/Collector.cpp:682: error: 'pthread_getattr_np' was not declared in this scope


Interestingly, the code does take care of uclibc 0.9.xx:

#if defined(__UCLIBC__)
// versions of uClibc 0.9.28 and below do not have
// pthread_getattr_np or pthread_attr_getstack.
#if __UCLIBC_MAJOR__ == 0 && \
(__UCLIBC_MINOR__ < 9 || \
(__UCLIBC_MINOR__ == 9 && __UCLIBC_SUBLEVEL__ <= 30))
#define UCLIBC_USE_PROC_SELF_MAPS 1
#include <stdio_ext.h>
extern int *__libc_stack_end;
#endif
#endif

Oops, there are two different Collector.cpp:
3rdparty/webkit/JavaScriptCore/runtime/Collector.cpp
3rdparty/javascriptcore/JavaScriptCore/runtime/Collector.cpp

One does define UCLIBC_USE_PROC_SELF_MAPS etc. as a workaround for uclibc 0.9.30, the other doesn’t – another bugreport to Nokia.

Just add -no-script to the configure options, for the moment.

Just a short note - I published both problems as Qt bug reports: QTBUG-6550 and QTBUG-6551

Have fun with it …
Sebastian

Friday, September 18, 2009

Single to Dual/Multi Core with Windows XP (ACPI HAL)

Introduction

Sometimes, people have the problem that their Windows XP is running as a “single core” system, only, although there are two or more cores installed. This can usually be seen in the task manager, where performance shows only a single graph, although “one diagram per CPU” is selected.
I talk about cores here, the same applies to multiple processors. Those are usually used on servers, though, where few people would start “fixing” the HAL.

Hardware Abstraction Layer – HAL

The reason is usually, that the normal ACPI HAL (Hardware Abstraction Layer) has been installed which does not support more than one core. In theory, XP recognises when a new CPU is installed, re-checks, and installs the correct hal. This does not always work, though.
The usual HALs are
  • Standard PC
  • ACPI PC
  • ACPI Uni-Processor (UP)
  • ACPI Multi-Processor (MP)
  • MPS Multi-Processor (APIC)
(http://support.microsoft.com/?scid=kb%3Ben-us%3B309283&x=10&y=9)
Especially in the context of virtual machines running under SUN VirtualBox, this does not work. When a windows XP system is installed with only one core active, and more core(s) is/are added later on, the CPU “id” does not change … no redetection is done, the other cores are not recognised. Another reason may be that the “ACPI PC” is not the same as “ACPI UP”, and only ACPI UP is able to support, and thus detect, more than one CPU. In the case of VirtualBox, the situation may also be caused on the IO-APIC not being enabled on install. According to SUN, XP Uniprocessor with IO-APIC is slower than without.
Officially, there is no way to upgrade the HAL. You can downgrade it, though, which is not a good idea … there is no way back.

Using devcon.exe: Forced HAL Upgrade

I found a very interesting post about the “devcon.exe”, a tool provided by MS as “the command line version of the device manager”, and its application to the HAL switch problem.
The important stuff:
Just execute the following commands in a cmd.exe shell …
devcon sethwid @ROOT\ACPI_HAL\0000 := +acpiapic_mp !acpiapic_up
devcon update c:\windows\inf\hal.inf acpiapic_mp

Of course, this may completely break your system. Make backups, find out beforehand how to restore, etc. Using a virtual box system, this is easy, just make a snapshot and restore if the upgrade does not work.
After running devcon, you reboot the system; after the reboot, XP re-detects all hardware, and the requests another reboot. This may change some of the hardware names, especially the LAN connection may get the number 2.

Hidden Devices

You can use the show-hidden trick of the device manager to display the old devices and remove them: http://support.microsoft.com/?scid=kb%3Ben-us%3B315539&x=14&y=11
set devmgr_show_nonpresent_devices=1
start devmgmt.msc

Switching the HAL

Once you get a ACPI MP hal, you can switch it to whatever you like using the device manager. Just select “new driver” for the “Computer” device.

Doing it manually

Before I found the post by “hedrums” above, I tried to do it manually. Interestingly, none of the files is locked by windows. They are loaded so early and completely in the boot process that they are no longer “needed” (used) in a running system, and can just be replaced.Yet, I never managed to copy and rename the files correctly.
Afterwards, by comparing the file sizes between the used versions (in system32) and the restore/backup versions (in ServicePackFiles\i386), I recognised the following:
• ntoskrnl.exe == ntkrnlmp.exe (2,04MB)
• ntkrnlpa.exe == ntkrpamp.exe (1,93MB)
• hal.dll == halmacpi.dll (131kB)
So, by copying the three files ntkrnlmp.exe, ntkrnlmp.exe and halmacpi.dll to system32 and renaming them to ntoskrnl.exe, ntkrnlpa.exe and hal.dll, respectively, you may be running an ACPI MP hal. I have not tried this, though.
Alternatively, using the correct ACPI UP files (whichever they are), you may get a UP system that, in turn, is automatically able to detect the multicore and again, install the correct drivers …
ACPI

Hardware.Info

I now found a tool that does the same stuff, a bit more comfortable:
http://www.hardware.info/en-US/news/ym2cmZqYwp2a/Problems_updating_to_a_dualcore_CPU_Not_anymore/

Saturday, September 12, 2009

Ubuntu Display Manager


Just some notes about the display manager(s) on Ubuntu I found out over time, and about their startup settings.
The display manager – that’s usually gdm, the gnome d.m.; alternatively kdm on kubuntu/kde, or even the good old xdm when using a lightweight desktop. In any case, it’s usually started to show a user login screen ;)

Text mode

It is often practical to boot into text only mode – at least, when you know a bit about linux. I’m not talking about removing gdm forever (apt-get remove gdm or update-rc.d -f gdm remove do this), but to use text mode in certain situations – including when you know your Xorg or gdm setup to be broken. Or, when you really want to save battery power ;)
The gdm startup allows this by putting text into the kernel command line. If this parameter is found, /etc/init.d/gdm just exits again. This can be achieved by:
  • stop the bootup in the grub menu, then

    • press “e” to edit the wanted entry
    • use the cursor keys to select the “kernel” line
    • press “e” again to edit the line
    • go to the end of the line and add “text”
    • press return to leave the line editing
    • press “b” to boot the edited entry
  • create a grub entry for text mode

    • sudo gedit /boot/grub/menu.lst
    • copy the first real boot entry (that starts with “title”) into another one below
    • change the title – append “text mode” or such
    • add “text” to the end of the “kernel” line
    • next time you boot the system, you can select the text mode and have tun.
This also disallows to start the gdm via the init script later on, because the entry is part of the kernel command line that cannot be changed. Yet, starting gdm directly achieves the same result.
By the way: I have not hardly anything about this on the web. Of course, you just need to look into /etc/init.d/gdm … the only post I found referring to this is https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/294980

gdm, kdm and xdm

Ever wondered how the various display managers that can be installed on (k)ubuntu stay out of each others hair?
  • each of them may be added to the runlevels
  • when starting, they each check whether they are the “preferred display manager” via /etc/defaults
  • if no, they exit; if yes, the one that should starts.
This way, it should not be possible to start more than one display manager – which you usually don’t want to. Opensuse, on the other hand, uses just one rc-script which decides which dm to start.

sysv-rc-conf

As a side note – I never know how to edit the /etc/rc.d?/scripts. This changed over time, mainly because of the linux standard base (LSB), I believe. The current command-line tool is update-rc.d which is not really nice to use.
But, the package sysv-rc-conf contains a textmode ui tool of the same name which seems to be usable, at least.

There is also chkconfig and insserv as I know from opensuse; yet, their packages refuse to install on Jaunty due to some sysv-init package conflicts. Probably because ubuntu migrated from sysvutils to sysvinit-utils. Or rather to upstart, where sysvinit-utils only contains some utilities.