bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base w


From: Óscar Fuentes
Subject: bug#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host
Date: Wed, 19 Nov 2014 21:27:50 +0100

Building 32 bit Emacs `master' on MSYS2 64 bits on a Windows 64 bit host
creates an invalid temacs.exe.

What follows is the analysis made by an MSYS2 user (David Macek) on the
MSYS2 mailing list:

Few notes first. Running the binary directly from Windows shell causes
appinfo to display an "app can't run on your PC" error, which is
common for architecture mismatches (like when running x64 binary on
x86 system). Running "strace ./temacs" confirmed it by displaying
error code 193 (ERROR_BAD_EXE_FORMAT, "... is not a valid Win32
application").

The command that links temacs.exe on i686:

> gcc -std=gnu99 -Demacs -I. -I. -I../lib -I../lib -mtune=generic
> -pthread -mms-bitfields
> -ID:/applications/msys2.x64/mingw32/include/librsvg-2.0
> -ID:/applications/msys2.x64/mingw32/include/gdk-pixbuf-2.0
> -ID:/applications/msys2.x64/mingw32/include/libpng16
> -ID:/applications/msys2.x64/mingw32/include/cairo
> -ID:/applications/msys2.x64/mingw32/include/glib-2.0
> -ID:/applications/msys2.x64/mingw32/lib/glib-2.0/include
> -ID:/applications/msys2.x64/mingw32/include/pixman-1
> -ID:/applications/msys2.x64/mingw32/include -I/mingw32/include
> -I/mingw32/include/freetype2 -I/mingw32/include
> -I/mingw32/include/libpng16 -I/mingw32/include/harfbuzz
> -ID:/applications/msys2.x64/mingw32/include
> -ID:/applications/msys2.x64/mingw32/include/freetype2
> -ID:/applications/msys2.x64/mingw32/include
> -ID:/applications/msys2.x64/mingw32/include/harfbuzz
> -ID:/applications/msys2.x64/mingw32/include/libpng16 -fopenmp
> -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -D_DLL
> -D_MT -fopenmp -DMAGICKCORE_HDR
I_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -D_DLL -D_MT
-ID:/applications/msys2.x64/mingw32/include/ImageMagick-6
-ID:/applications/msys2.x64/mingw32/include/libxml2
-ID:/applications/msys2.x64/mingw32/include/dbus-1.0
-ID:/applications/msys2.x64/mingw32/lib/dbus-1.0/include -MMD -MF
deps/.d -MP -ID:/applications/msys2.x64/mingw32/include
-ID:/applications/msys2.x64/mingw32/include/p11-kit-1
-ID:/applications/msys2.x64/mingw32/include -g3 -O2 -gdwarf-2
-Wl,-stack,0x00800000 -Wl,-heap,0x00100000 -Wl,-image-base,0x400000000
-Wl,-entry,__start -Wl,-Map,./temacs.map -o temacs firstfile.o
dispnew.o frame.o scroll.o xdisp.o menu.o window.o charset.o coding.o
category.o ccl.o character.o chartab.o bidi.o term.o terminal.o
xfaces.o dbusbind.o emacs.o keyboard.o macros.o keymap.o sysdep.o
buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o
cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o
data.o doc.o editfns.o callint.o eval.o floatfns.o
fns.o font.o print.o lread.o syntax.o unexw32.o bytecode.o process.o
gnutls.o callproc.o region-cache.o sound.o atimer.o doprnt.o
intervals.o textprop.o composite.o xml.o w32notify.o profiler.o
decompress.o w32fns.o w32menu.o w32reg.o w32font.o w32term.o w32xfns.o
w32select.o w32uniscribe.o w32.o w32console.o w32heap.o w32inevt.o
w32proc.o fontset.o fringe.o image.o tparam.o lastfile.o
../lib/libgnu.a emacs.res -lwinmm -lgdi32 -lcomdlg32 -lmpr -lwinspool
-lole32 -lcomctl32 -lusp10 -LD:/applications/msys2.x64/mingw32/lib
-lMagickWand-6.Q16HDRI -lMagickCore-6.Q16HDRI
-LD:/applications/msys2.x64/mingw32/lib -ldbus-1

The offending argument is "-Wl,-image-base,0x400000000", which sets
the executable to instruct Windows loader to load the executable at
the 16 GiB mark or higher in virtual memory, which is ridiculous for a
32-bit program. So although the error message is not very clear, it's
justified, this binary can't be loaded.

I found the declaration in configure.ac in a case starting at line
4911. The linker argument is added there when building on 64-bit
mingw, probably in an attempt to improve performance and/or
compatibility. The problem is that even on i686, the $canonical
triplet is "x86_64-pc-mingw32". I have not tried to find out why the
triplet is wrong. The PKGBUILD doesn't have this problem because it
always passes correct "--build=${MINGW_CHOST}" to configure.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]