Description of problem:
With libidn >= 0.4.1 I get the following (wrong!) behaviour, if I 
compile one of the example files (it seems to be the problem at 
all example files) provided with the devel package:

--- snipp ---
# gcc example3.c -o example3 -lidn
# ./example3
Input domain encoded as `ANSI_X3.4-1968': öko.de
Read string (length 6): f6 6b 6f 2e 64 65
ToASCII() failed... 9
#
--- snapp ---

But if I remove the current libidn and install libidn (+ devel) 
0.4.0, I get this (correct!) behaviour:

--- snipp ---
# gcc example3.c -o example3 -lidn
# ./example3
Input domain encoded as `ISO-8859-15': öko.de
Read string (length 6): f6 6b 6f 2e 64 65
ACE label (length 13): 'xn--ko-eka.de'
78 6e 2d 2d 6b 6f 2d 65 6b 61 2e 64 65
#
--- snapp ---

My locale was at _both_ _times_ "de_DE@euro" (ISO-8859-15). But UTF-8 
(Fedora default) didn't matter.

If I compile example3.c with installed libidn 0.5.0, uninstall it and
install libidn 0.4.0 and start the old binary again, it works. So the 
problem is (seen from my eyes) in one of the libidn libraries, the 
executable is linked against.

FYI: My build of libidn 0.4.0 was done using the older sources and 
changed version numbers in the spec file from 0.5.0 - so there are 
the same configure parameters and I also recompiled 0.5.0 myself, 
but it didn't change anything.

Version-Release number of selected component (if applicable):
libidn-0.5.0-1

How reproducible & Steps to Reproduce:
See above.

Actual results:
Non-working idna_to_ascii_lz()

Expected results:
Working idna_to_ascii_lz()

Additional info:
Joe, I think you'll be the default bug owner, so maybe you're able 
to trigger out (or even solve) the problem, but I also send this bug 
report to upstream, because it is a upstream bug and not Fedora or 
Red Hat even related. This bug is more or less only to have this bug
tracked down as a reference...