Tu jsem nasel cosi na netu. Podobny problem jde o nejakou chybu PRELOADERu snazil jsem se to prelouskat ale moc anglicky neumim. Pokud jste na tom lip tak zkuste, nebo mozna nekdo jini pomuze.
5. Preloader Problem on x86_64
(5 posts) Archive Link: "wine_main_preload_info not found, cannot use first
megabyte, *.exe don't work"
Topics: Fixes
People: Pavel Roskin, Mike McCormack
Pavel Roskin ran into a strange problem on a bleeding edge system:
Something strange to happened my Wine installation recently. I'm getting
following messages if I run any program from Wine:
$ winemine
wine_main_preload_info not found
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space,
please report
wine_main_preload_info not found
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space,
please report
The programs still work fine after those for lines are printed. What's worse is
that that Windows PE files don't work at all, including those that come with
Wine:
$ wine winhlp32.exe
wine_main_preload_info not found
wine: could not load L"C:\\windows\\winhlp32.exe": Module not found
I'm using current Wine from git on Fedora Core development (future FC6) for
x86_64, glibc-2.4.90, gcc-4.1.1, Linux 2.6.18-rc2 (actually, the current
version from the wireless-2.6 branch). The CPU is Intel with EM64T. Wine is
compiled with default settings for i386 by the i386 compatibility compiler and
i386 compatibility libraries included in Fedora. I removed ~/.wine to start
with a clean system.
Since I keep updating the kernel and Wine almost every day and I upgraded from
FC5 to Development recently, it's hard to say what's the exact reason.
P.S. I have a 32-bit Ubuntu 6.04 installation on the same machine, so I used
chroot to compile and run Wine under Ubuntu under the same 64-bit kernel. I
also used linux32 to fool uname into thinking it's an i686 machine. The
messages from ELF programs are gone, but PE files still fail:
$ winemine
$ wine winhlp32.exe
wine: could not load L"C:\\windows\\winhlp32.exe": Module not found
Moreover, if I run this Wine on Fedora, the results are the same - no more
messages about wine_main_preload_info and setup_dos_mem. I guess it's a compile
issue. Unfortunately, the difference between config.status in both builds is
quite significant to pinpoint the reason.
Mike McCormack thought the problem was with Wine's preloader:
Looks like the wine-preloader isn't being run, so memory that wine needs isn't
reserved.
Maybe check that configure is setting the EXTRA_BINARIES variable?
mike@black:~/wine$ grep ^EXTRA_BINARIES loader/Makefile
EXTRA_BINARIES = wine-kthread wine-pthread wine-preloader
Pavel did more debugging and noticed something odd:
It is installed and it is run. If I replace wine-preloader with a script that
logs the arguments and runs the renamed wine-preloader, I see it being called
twice when an exe file with run with Wine. For example:
$ wine FarManager170.exe
wine_main_preload_info not found
wine_main_preload_info not found
wine: could not load L"Z:\\home\\proski\\dist\\windows\\FarManager170.exe":
Invalid address
Mike saw a problem there related to the last line:
OK, it seems to be that the preloader can't lookup the ELF symbol
"wine_main_preload_info" in wine-pthread.
That's bad, because the preloader is reserving memory, but has no way to let
wine-pthread know which memory it reserved.
Can you see that symbol exported from wine-pthread?
mike@black:~/wine$ nm loader/wine-pthread | grep wine_main_preload_info
7bf023d8 B wine_main_preload_info
Pavel agreed that was the problem. After digging around more he found a
workaround:
find_symbol() looks for DT_HASH (4) to set symtabend and fails to find it. As I
understand it, we should trick ld into creating the DT_HASH tag or use some
other way to locate wine_main_preload_info.
The 6ffffef5 tag is DT_GNU_HASH - that may be a good alternative to DT_HASH.
Adding -Wl,--hash-style=sysv to the gcc flags when linking wine-pthread solves
the problem!!!
I think adding support for DT_GNU_HASH would be a good idea anyway.
Mike thought that was reasonable:
Great work! There's some information on DT_GNU_HASH here:
http://sourceware.org/ml/binutils/2006-06/msg00418.html (http://
sourceware.org/ml/binutils/2006-06/msg00418.html)
Looks like we don't actually use the hash table to look up the symbol, just to
find the last entry in the symbol table.
I agree with you the best way to solve the problem would be to handle
DT_GNU_HASH.
Téma: Pharaoh (Přečteno 7912 krát)
