Tag Archives: bug

Cross-compiling a PowerPC64 LE kernel and hitting a GCC bug

Leave a Reply

Being new at OzLabs I’m dipping my toes into various projects and having a play with PowerPC and so I thought I’d cross-compile the Linux kernel on Fedora. Traditionally PowerPC has been big endian, however it also supports little endian so I wanted to build all the things.

Fedora uses a single cross toolchain that can build all four variants, whereas Debian/Ubuntu splits this out into two different toolchains (a BE and an LE one).

Install dependencies in Fedora:
$ sudo dnf install gcc make binutils-powerpc64-linux-gnu gcc-powerpc64-linux-gnu gcc-c++-powerpc64-linux-gnu bc ncurses-devel

Get the v4.2 kernel:
$ git clone https://github.com/torvalds/linux.git --branch v4.2 --depth 1 && cd linux

Successful big endian build of the kernel, using the default config for pseries:
$ ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- make pseries_defconfig
$ ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- make -j$(nproc)
# clean after success
$ ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- make clean
$ ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- make mrproper

Building a little endian kernel however, resulted in a linker problem:
$ ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- make pseries_defconfig
$ ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- make menuconfig
# change architecture to little endian:
# Endianness selection (Build big endian kernel) --->
# (X) Build little endian kernel
$ ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- make V=1

Here was the result:
powerpc64-linux-gnu-gcc -mlittle-endian -mno-strict-align -m64 -Wp,-MD,arch/powerpc/kernel/vdso64/.vdso64.so.dbg.d -nostdinc -isystem /usr/lib/gcc/powerpc64-linux-gnu/5.2.1/include -I./arch/powerpc/include -Iarch/powerpc/include/generated/uapi -Iarch/powerpc/include/generated -Iinclude -I./arch/powerpc/include/uapi -Iarch/powerpc/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -Iarch/powerpc -DHAVE_AS_ATHIGH=1 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -msoft-float -pipe -Iarch/powerpc -mtraceback=no -mabi=elfv2 -mcmodel=medium -mno-pointers-to-nested-functions -mcpu=power7 -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -Wa,-maltivec -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -fno-var-tracking-assignments -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO -Werror -shared -fno-common -fno-builtin -nostdlib -Wl,-soname=linux-vdso64.so.1 -Wl,--hash-style=sysv -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vdso64.so)" -D"KBUILD_MODNAME=KBUILD_STR(vdso64.so)" -Wl,-T arch/powerpc/kernel/vdso64/vdso64.lds arch/powerpc/kernel/vdso64/sigtramp.o arch/powerpc/kernel/vdso64/gettimeofday.o arch/powerpc/kernel/vdso64/datapage.o arch/powerpc/kernel/vdso64/cacheflush.o arch/powerpc/kernel/vdso64/note.o arch/powerpc/kernel/vdso64/getcpu.o -o arch/powerpc/kernel/vdso64/vdso64.so.dbg
/usr/bin/powerpc64-linux-gnu-ld: arch/powerpc/kernel/vdso64/sigtramp.o: file class ELFCLASS64 incompatible with ELFCLASS32
/usr/bin/powerpc64-linux-gnu-ld: final link failed: File in wrong format
collect2: error: ld returned 1 exit status
arch/powerpc/kernel/vdso64/Makefile:26: recipe for target 'arch/powerpc/kernel/vdso64/vdso64.so.dbg' failed
make[2]: *** [arch/powerpc/kernel/vdso64/vdso64.so.dbg] Error 1
scripts/Makefile.build:403: recipe for target 'arch/powerpc/kernel/vdso64' failed
make[1]: *** [arch/powerpc/kernel/vdso64] Error 2
Makefile:949: recipe for target 'arch/powerpc/kernel' failed
make: *** [arch/powerpc/kernel] Error 2

All those files were 64bit, however:
arch/powerpc/kernel/vdso64/cacheflush.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), not stripped
arch/powerpc/kernel/vdso64/datapage.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), not stripped
arch/powerpc/kernel/vdso64/getcpu.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), not stripped
arch/powerpc/kernel/vdso64/gettimeofday.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), not stripped
arch/powerpc/kernel/vdso64/note.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), not stripped
arch/powerpc/kernel/vdso64/sigtramp.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), not stripped

An strace of the failing powerpc64-linux-gnu-gcc command above showed that collect2 (and ld) were being called with an option setting the format to 32bit:
24904 execve("/usr/libexec/gcc/powerpc64-linux-gnu/5.2.1/collect2", ["/usr/libexec/gcc/powerpc64-linux"..., "-plugin", "/usr/libexec/gcc/powerpc64-linux"..., "-plugin-opt=/usr/libexec/gcc/pow"..., "-plugin-opt=-fresolution=/tmp/cc"..., "--sysroot=/usr/powerpc64-linux-g"..., "--build-id", "--no-add-needed", "--eh-frame-hdr", "--hash-style=gnu", "-shared", "--oformat", "elf32-powerpcle", "-m", "elf64lppc", "-o", ...], [/* 66 vars */]

Alan Modra tracked it down to some 32bit hard-coded entries in GCC sysv4.h and sysv4le.h and submitted a patch to the GCC mailing list (Red Hat bug).

I re-built the Fedora cross-gcc package with his patch and it solved the linker problem for me. Hurrah!

Bug: Korora 18 KDE installer sometimes not loading

6 Replies

Update: Try running the installer from the command line with two commands, like so:
xhost +
liveinst

A couple of users have reported that running the installer under the KDE live image does not do any thing, i.e. the loading cursor appears run but no program loads. This does not appear to affect GNOME.

If you run it from the terminal you get a error about X and GTK.

[liveuser@localhost ~]$ liveinst
No protocol specified
xhost: unable to open display ":0"
Starting installer, one moment...
anaconda 18.37.11 for Fedora 18 started.
No protocol specified
** (anaconda:1940): WARNING **: Could not open X display
No protocol specified
Traceback (most recent call last):
File "/sbin/anaconda", line 923, in
setupDisplay(anaconda, opts)
File "/sbin/anaconda", line 585, in setupDisplay
anaconda.initInterface()
File "/usr/lib64/python2.7/site-packages/pyanaconda/__init__.py", line 213, in initInterface
from pyanaconda.ui.gui import GraphicalUserInterface
File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/__init__.py", line 22, in
import meh.ui.gui
File "/usr/lib/python2.7/site-packages/meh/ui/gui.py", line 23, in
from gi.repository import Gtk
File "/usr/lib64/python2.7/site-packages/gi/importer.py", line 76, in load_module
dynamic_module._load()
File "/usr/lib64/python2.7/site-packages/gi/module.py", line 244, in _load
overrides_modules = __import__('gi.overrides', fromlist=[self._namespace])
File "/usr/lib64/python2.7/site-packages/gi/overrides/Gtk.py", line 1624, in
raise RuntimeError("Gtk couldn't be initialized")
RuntimeError: Gtk couldn't be initialized

We think this might be this upstream bug, however nothing concrete has been discovered.

Please try booting again after a power-cycle with your network cable either plugged in or out, the opposite of what it was when it wasn’t working. Please let us know how you go with this, especially if anyone finds something repeatable.

Update: Try running the installer from the command line with two commands, like so:
xhost +
liveinst

Kororaa 15 beta bug – X not starting

Leave a Reply

Some users have reported that X (graphical interface) doesn’t start when booting the Live DVD.

Symptoms:
The Live DVD boots to a black screen and the login manager doesn’t display.

Expected results:
The Live DVD boots to the login manager and then to the desktop.

Work around:
When the computer arrives as the black screen you can switch terminals, log in as root and start the appropriate login manager (whether GNOME or KDE).

GNOME:
Alt + F2
root
gdm

KDE:
Alt + F2
root
kdm

I have not yet been able to reproduce this error, so I’m not sure why it’s happening. If you have further information or make any discoveries, please let us know on the forums.

Sorry for the trouble!

Thanks,
Chris

Kororaa 14 Beta3 – Remove KDE themed Firefox in GNOME

Leave a Reply

I accidentally included the KDE Oxygen theme for the GNOME version of Beta3 (it was correct in Beta2). This means that GNOME users of Kororaa will get a KDE themed Firefox – not quite what I had in mind! KDE users don’t need to do anything, and should have a nice, pretty Firefox.

So, thanks to Arv3n for posting it in the forums, I have fixed it for the next release, but you can also fix it yourself in Beta3. Here’s how.

System wide (for any new accounts created):
sudo rm -Rf /usr/lib*/firefox-3.6/defaults/profile/extensions/\{C1F83B1E-D6EE-11DE-B441-1AD556D89593\}
sudo rm -Rf /usr/lib*/firefox-3.6/defaults/profile/extensions/plasmanotify@andreas-demmer.de
sudo sed -i '/.*oxygen.*/d' /usr/lib*/firefox-3.6/defaults/profile/prefs.js

Your account, close Firefox and run:
rm -Rf ~/.mozilla/firefox/*/extensions/\{C1F83B1E-D6EE-11DE-B441-1AD556D89593\}
rm -Rf ~/.mozilla/firefox/*/extensions/plasmanotify@andreas-demmer.de
sed -i '/.*oxygen.*/d' ~/.mozilla/firefox/*/prefs.js

Sorry about that!!!

-c

Kororaa Beta2 bug fixes

Leave a Reply

If you’re running Kororaa Beta2, there are a few bugs which require fixing.

Yum
Firstly, the KDE version incorrectly included Yum from Rawhide (development) tree (GNOME version does not have this issue). This means you are running an untested version of Yum, the system’s default package manager.

To fix this, disable the repo (or remove the repository file for it), then downgrade yum to the stable version.
sudo sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/fedora-yum-rawhide.repo
sudo yum downgrade yum

Livna
The Livna repository, which is configured out of the box, seems to be having lots of problems with availability. This will be fixed in the next release, but in the mean time, you can disable or remove that repository.
sudo sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/livna.repo

If you find any more issues, please let us know!

Eclipse eGit push bug – SOLVED

6 Replies

After upgrading to Helios and therefore eGit 0.8.4, I could no-longer push to git repos using pre-configured remotes. Adding the same remote manually at time of push works, but is annoying. This is a known bug and is fixed in the code, but won’t be pushed out for the current 0.8 series (for some reason). The bug report has a simple work-around which fixes the problem. Simply edit your repo’s .git/config file and copy the url line and change it to pushurl – problem solved.

Update: Thanks to J Bruni’s comment, if you have a pushurl but not a url entry, do the reverse of above – copy pushurl and rename to url.

Bugging bugs with Firefox #1

2 Replies

I love Firefox, it’s a great web browser. But there are two things which have annoyed me forever and it’s about time I did something about it.

Numero Uno:
The first is the in relation to the ability to save tabs for the next time Firefox starts. I love this feature. When you have multiple tabs open and you close your last main window it prompts you to “Save and Quit”. When you open Firefox next time, it will automatically open the same pages in the same tabs.

But this doesn’t happen if you have another main browsing window open. Fair enough, I guess. The thing that bugs me is that it doesn’t prompt you if you only have the “Downloads” window open, for example. I get why this is the case – Firefox is still running. In fact, if you close the main browsing window and leave the downloads window up, Firefox is still running, just without any windows present.

What I’d like to see is for Firefox to prompt you to save your tabs if all you have open is the downloads window. It’s annoying to have to cancel the close quit request, go and close the download window, then come back and close Firefox again. Hell, close the download tab too if you like, I don’t mind!

I’m assuming the way it’s coded to work is to check if it’s the last “Firefox” window open, and is so, prompt if there are multiple tabs open. If not, then just quit. Changing the way it works might require a considerable re-write of the code and also open some new case bugs like what to do when the user is still downloading, but hey.

Try it yourself. Open a few tabs, quit Firefox and note the option to “Save and Quit”. Then open the download window (CTRL+Shift+Y on Linux) and try again. No option to “Save and Quit”.

Does this bug anyone else?

-c