VirtualBox 3.2.6 – can’t install Windows 7 64bit (Status: 0xc000022
I couldn’t install 64-bit Windows 7 on VirtualBox 3.2.6 (running on Fedora 12).
I was getting “Status: 0xc000022″.
The solution was to enable both IO APIC and PAE/NX.
Hope this will help you.
Apache .htaccess automatic redirection to www subdomain (301 moved permanently)
The easiest way to make automatic redirection (301 moved permanently) from sites without specified subdomain to www subdomain is to use .htaccess file (using Apache server of course).
Options +FollowSymLinks <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_HOST} ^v-teq.com$ [NC] RewriteRule ^(.*)$ http://www.v-teq.com/$1 [R=301,L,QSA] </IfModule>
It converts URL requests without subdomain to URLs with www subdomain. It handles even request with specific site location or some script-like ?id=10&q=search.. stuff. For example:
http://v-teq.com ⇒ http://www.v-teq.com
http://v-teq.com/2009-06-05/… ⇒ http://www.v-teq.com/2009-06-05/…
http://v-teq.com/?action=test ⇒ http://www.v-teq.com/?action=test
Google Earth 5.0, Ubuntu 9.04 (Jaunty Jackalope) – symbol lookup error: libssl.so.0.9.8, undefined symbol: EVP_idea_cbc, libcrypto.so.0.9.8 bug
I have tried to install Google Earth on Ubuntu 9.04 (Jaunty Jackalope) today and I came across a simple bug.
After installation, Google Earth was not able to communicate using SSL. It gave me this error message:
/usr/lib/googleearth/googleearth-bin: symbol lookup error: /usr/lib/googleearth/libssl.so.0.9.8: undefined symbol: EVP_idea_cbc
The simple bug-fix is to rename/copy libcrypto.so.0.9.8 shared library into libcrypto.0.9.8, as I have found only on some French websites.
Use sudo if you’re not logged in as root. You can also probably use mv instead of cp. You can run for example these commands:
root@v-teq-laptop:~$ cd /usr/lib/googleearth/ root@v-teq-laptop:/usr/lib/googleearth$ cp libcrypto.so.0.9.8 libcrypto.0.9.8
Everything should run now, just enjoy Google Earth 
DDD (gdb): No source: ../sysdeps/x86_64/elf/start.S: No such file bug; Missing XKeysymDB file bug
I came across a strange bug, or better said, strange behavior of ddd today. I have tried to debug my program and I have got this error dialogue:
DDD: No source
/home/v-teq/…/sysdeps/x86_64/elf/start.S: No such file or directory
Missing XKeysymDB file
I have tried to find out where was the problem:
v-teq@v-teq-laptop:~$ ddd --check-configuration Checking for XKeysymDB... (none) Warning: The `XKeysymDB' file is not in the default X file search path. If ddd was not compiled on this machine, ddd may not run properly (lots of warnings for unknown keysym names). and install it into your X project root (typically `/usr/lib/X11') or have the XKEYSYMDB environment variable point at it.
But as you can see, I found another error message that was ddd printing out – it couldn’t find XKeysymDB file. The solution was quite easy – only to find the XKeysymDB file in my /usr directory, because default /usr/lib/X11 path doesn’t exist anymore on my Debian based machine.
v-teq@v-teq-laptop:~$ find /usr -name XKeysymDB /usr/share/X11/XKeysymDB
So the answer was /usr/share/X11/XKeysymDB in my case.
Now it’s easy to set environment variable and get ddd working again:
v-teq@v-teq-laptop:~$ XKEYSYMDB=/usr/share/X11/XKeysymDB ddd --check-configuration Checking for XKeysymDB... /usr/share/X11/XKeysymDB
You can set variable pernamently of course (or you can echo this line into your ~/.bashrc or such file).
For sh, ksh or bash:
export XKEYSYMDB="/usr/share/X11/XKeysymDB"
For csh:
setenv XKEYSYMDB "/usr/share/X11/XKeysymDB"DDD: No source: ../sysdeps/x86_64/elf/start.S
Now back to the first problem – error dialogue that said I didn’t compiled debugging information to my executables, so debuggers (ddd, gdb) weren’t able to use symbols from source files.
Take care if you have compiled your binary files (executables or libraries) really with debugging information (eg. -g option in gcc). My problem was, that my Makefile created executables from libraries with -g option, but libraries themselves were compiled without this option automatically (there was no rule to make *.o files in Makefile).
So my advice is to double check your Makefile, or command line if you’re compiling project manually, if you have really set the -g option. For example:
gcc -g -o main main.c
Or if you want to create *.o file before linking to final executable, don’t forget to check -g option in both cases:
gcc -g -c -o main.o main.c gcc -g -o main main.o
You can also add something like that to your Makefile to compile *.o files with -g debugging option automatically:
CC=gcc CFLAGS=-g %.o: %.c $(CC) $(CFLAGS) -c $< -o $@
Emerge Portage – Multiple package instances within a single package resulting slot conflict
As usual at least once a month, I came across a bug in The Portage Tree of Gentoo Linux.
root@v-teq-laptop $ emerge -Dup world # --deep --update --pretend !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: sys-libs/readline:0 ('ebuild', '/', 'sys-libs/readline-5.2_p13', 'merge') pulled in by =sys-libs/readline-5* required by ('ebuild', '/', 'dev-lang/ghc-6.8.2', 'merge') (and 16 more) ('installed', '/', 'sys-libs/readline-6.0', 'nomerge') pulled in by sys-libs/readline:0 required by world sys-libs/readline required by system sys-libs/readline required by world (and 13 more) It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook.
To get rid of such package conflict you have to add package name into package.mask file. And even better is to put there only one version of those conflicted packages.
There you can see example solution of this kind of bug:
echo ">=sys-libs/readline-6.0" >> /etc/portage/package.mask
