Windows programs no more running with the new wine-glibc

Vincent Béron vberon at
Sat Nov 15 10:14:17 CST 2003

Le sam 15/11/2003 à 08:07, Mike Hearn a écrit :
> On Fri, 2003-11-14 at 04:24, Vincent Béron wrote:
> > Disabling exec-shield (either via setarch i386 or with the proc thing)
> > works sometimes, depending on the loading addresses assigned to
> > libraries. If something (libc, libm, libdl, etc.) uses that address,
> > nothing Win32 will be usable. When exec-shield is disabled, new
> > libraries will be assigned loading addresses starting at the lower value
> > possible, but already assigned ones (via prelinking) will still keep
> > theirs, hence possibly blocking execution.
> > 
> > I'll test tomorrow disabling prelinking.
> Are you saying prelinking can break wine? If so then this is rather bad,
> prelink is being rolled out on every distro.

Sorry, forgot to come back to say how testing went.

The best workaround I found (from
is to change the default prelinking options, so that the required
address is still free for Win32 apps.

If you're hit by this, in file /etc/sysconfig/prelink, change
PRELINK_OPTS="-mR --no-exec-shield"
The loading addresses chosen will be from 0x40000000, the default value
on Linux systems, rather than trying to put the maximum of libraries
before 0x01000000 (so that the first byte is always 0x00, rendering
string buffer overflows mor difficult to exploit), hence crowding the
area we want to keep free (0x00400000).

So far (little testing only, but still), I haven't had a problem with
those settings, either running Wine or Linux apps.

Further reading in the referenced page shows Alexandre is in contact
with some RedHat people, so hopefully they can come to a solution. RHEL
3 is affected as well, not only Fedora.


More information about the wine-devel mailing list