Re: Executing wine over make segfaults.
> > Please open a bug and discuss this problem via bugzilla, rather than on > wine-devel. > OK. Bug #6622 has been registered. Let's move our efforts to bugzilla. Regards, Pavel
Re: Executing wine over make segfaults.
Pavel Troller wrote: It is usuyally generated from wine-pthread gdb wine-pthread core.19668 Please open a bug and discuss this problem via bugzilla, rather than on wine-devel. Mike
Re: Executing wine over make segfaults.
Hi! > It is usuyally generated from wine-pthread > > gdb wine-pthread core.19668 > bt It showed the following: [EMAIL PROTECTED]:~$ gdb wine-pthread core.19668 GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". warning: core file may not match specified executable file. warning: Can't read pathname for load map: Input/output error. Reading symbols from /opt/wine/lib/libwine.so.1...done. Loaded symbols for /opt/wine/bin/../lib/libwine.so.1 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 ... and many similar lines for every library involved Reading symbols from /opt/wine/lib/wine/urlmon.dll.so...done. Loaded symbols for /opt/wine/bin/../lib/wine/urlmon.dll.so Core was generated by `/mnt/cd/100_prazskych_zajimavosti.exe '. Program terminated with signal 11, Segmentation fault. #0 0x00876440 in ?? () (gdb) > > If it still does not show a backtrace, try: No it doesn't, the backtrace is just as dummy as before. > > x /i $eip > info registers > > to show the current instruction + registers. OK, particular success: (gdb) x /i $eip 0x876440: Cannot access memory at address 0x876440 (gdb) info registers eax0x33f5cc 3405260 ecx0x0 0 edx0x3904a2 3736738 ebx0x33f9ff 3406335 esp0x7ffddc80 0x7ffddc80 ebp0x33f634 0x33f634 esi0x3904a0 3736736 edi0x1 1 eip0x876440 0x876440 eflags 0x210206 [ PF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x33 51 gs 0x3b 59 (gdb) > > Ciao, Marcus > With regards, Pavel Troller
Re: Executing wine over make segfaults.
On Tue, Nov 07, 2006 at 06:44:31AM +0100, Pavel Troller wrote: > > > > We just have to find out _why_ it breaks. Should not be too hard > > with some backtraces or similar. > > > Hi! > Today I tried to generate a backtrace. However, I simply failed. > I've recompiled wine with full debug, and reinstalled. Then I > installed the newest gdb (6.5), because my older one (6.4) seemed > a bit unstable. Then, I did the following: > 1) > [EMAIL PROTECTED]:/mnt/cd$ gdb wine > GNU gdb 6.5 > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db > library "/lib/libthread_db.so.1". > > (gdb) run 100_prazskych_zajimavosti.exe > Starting program: /opt/wine/bin/wine 100_prazskych_zajimavosti.exe > Failed to read a valid object file image from memory. > [Thread debugging using libthread_db enabled] > [New Thread -1208980992 (LWP 19254)] > [New Thread -1208984688 (LWP 19257)] > [Thread -1208984688 (LWP 19257) exited] > Cannot find user-level thread for LWP 19254: generic error > > gdb then hung and had to be killed. > It should be noted that gdb works with standard Linux binaries normally. > > 2) > [EMAIL PROTECTED]:~$ wine /mnt/cd/100_prazskych_zajimavosti.exe > fixme:font:WineEngCreateFontInstance just using first face for now > fixme:font:WineEngCreateFontInstance just using first face for now > fixme:font:WineEngCreateFontInstance just using first face for now > fixme:font:WineEngCreateFontInstance just using first face for now > fixme:font:WineEngCreateFontInstance just using first face for now > fixme:font:WineEngCreateFontInstance just using first face for now > fixme:ole:CoResumeClassObjects stub > Segmentation fault (core dumped) > [EMAIL PROTECTED]:~$ gdb -c core.19668 /mnt/cd/100_prazskych_zajimavosti.exe > GNU gdb 6.5 > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found) > Using host libthread_db library "/lib/libthread_db.so.1". > > > warning: core file may not match specified executable file. > > warning: shared library handler failed to enable breakpoint > (no debugging symbols found) > Core was generated by `/mnt/cd/100_prazskych_zajimavosti.exe >'. > Program terminated with signal 11, Segmentation fault. > #0 0x00876440 in ?? () > (gdb) bt > #0 0x00876440 in ?? () > #1 0x000b in ?? () > #2 0x7ffddc8c in ?? () > #3 0x7ffddd0c in ?? () > #4 0x000b in ?? () > #5 0x in ?? () > (gdb) > > First I tried 'gdb -c wine' but it told me that the core was generated > by another executable, and stated the windows .exe file (you can see the same > in the above output too). Backtrace is, however, the same in both cases, and, > as you can see, totally bogus. > > I really don't know how to get better results now. > Any hints available ? It is usuyally generated from wine-pthread gdb wine-pthread core.19668 bt If it still does not show a backtrace, try: x /i $eip info registers to show the current instruction + registers. Ciao, Marcus
Re: Executing wine over make segfaults.
> > We just have to find out _why_ it breaks. Should not be too hard > with some backtraces or similar. > Hi! Today I tried to generate a backtrace. However, I simply failed. I've recompiled wine with full debug, and reinstalled. Then I installed the newest gdb (6.5), because my older one (6.4) seemed a bit unstable. Then, I did the following: 1) [EMAIL PROTECTED]:/mnt/cd$ gdb wine GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run 100_prazskych_zajimavosti.exe Starting program: /opt/wine/bin/wine 100_prazskych_zajimavosti.exe Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1208980992 (LWP 19254)] [New Thread -1208984688 (LWP 19257)] [Thread -1208984688 (LWP 19257) exited] Cannot find user-level thread for LWP 19254: generic error gdb then hung and had to be killed. It should be noted that gdb works with standard Linux binaries normally. 2) [EMAIL PROTECTED]:~$ wine /mnt/cd/100_prazskych_zajimavosti.exe fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:ole:CoResumeClassObjects stub Segmentation fault (core dumped) [EMAIL PROTECTED]:~$ gdb -c core.19668 /mnt/cd/100_prazskych_zajimavosti.exe GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". warning: core file may not match specified executable file. warning: shared library handler failed to enable breakpoint (no debugging symbols found) Core was generated by `/mnt/cd/100_prazskych_zajimavosti.exe '. Program terminated with signal 11, Segmentation fault. #0 0x00876440 in ?? () (gdb) bt #0 0x00876440 in ?? () #1 0x000b in ?? () #2 0x7ffddc8c in ?? () #3 0x7ffddd0c in ?? () #4 0x000b in ?? () #5 0x in ?? () (gdb) First I tried 'gdb -c wine' but it told me that the core was generated by another executable, and stated the windows .exe file (you can see the same in the above output too). Backtrace is, however, the same in both cases, and, as you can see, totally bogus. I really don't know how to get better results now. Any hints available ? With regards, Pavel Troller
Re: Executing wine over make segfaults.
> I am using a 2.6.18 based openSUSE 10.2 Beta1 kernel and Wine works fine > there. (AMD64 however). Your NoExec protection is on or off? And question to all: is there someone with new (2.6.18.x) vanilla kernel (downloaded from kernel.org), noexec=on and perfectly working Wine? If yes, then please send me your .config, tell your gcc versions - I will try to figure out why problems happens to Wine with new kernels then. If I don't recieve answer I will assume that everyone with 2.6.18.x kernel (or higher) andNoExec protection cannot use Wine. This is speculative of course and not neccessary true but I need to have "starting point". Theoretically everyone with NoExec turned on (this is default) with 2.6.18.x kernel will end up with not working Wine. But situation may vary with compiler version. If so this is important to know so if someone have 2.6.18.x vanilla kernel with NoExec protection turned on (default) and working Wine please reply. Also I wish to say that this bug isn't just security problem "add-noexec=off option-and-here-you-go!". Most users (especcialy who didn't tried Wine before) with new kernels will think that there is no solution (they will think that application simply doesn't work under Wine) - so most applications will not work for them including virtually all games (at least all my games that work perfectly with 2.6.16.18 crashes with 2.6.18.1). Very few programs will work (for example: notepad, proxomitron, mdict) but most will fail (for example: Unreal Tournament, Postal 2, XnView, IrfanView and many, many others). This is very bad and I think this is major compatibility problem.
Re: Executing wine over make segfaults.
> I saw a few others say that this worked around the problem, so I > rebooted and added noexec=off ... I still get the segfault running > wine from make. Unfortunatelly I cannot reproduce your problem. Under 2.6.18.1 with noexec=off simple Makefile posted by Jimmy W works fine for me. So in order to debug problem you may try the following: strace make - it may show some useful info about segfault but of course to find exactly why and where segfault happens you must attach to Wine process with your debugger.
Re: Executing wine over make segfaults.
Then probably the only way to unbreak the broken apps is to add noexec=off to the kernel command line. I saw a few others say that this worked around the problem, so I rebooted and added noexec=off ... I still get the segfault running wine from make. _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/
Re: Executing wine over make segfaults.
On Mon, Nov 06, 2006 at 04:40:48PM +0100, Pavel Troller wrote: > > > > this is what i did - and also suggest quite some time ago him(?)/list. i > > had the same problem since .16 kernels (unstable(~) gentoo-source > > ebuild). since that change everything works fine (.18 now). > > > Hi! > Yes, you did, and you did correctly. I just rebooted the x86_64 machine > with noexec=off. The app runs with no problems. > Does it mean that something changed in noexec between .17 and .18 ? Why > wine worked well with noexec and 2.6.17 ? > But it's really wrong: I don't want to compromise my security because of > running wine. Is there a chance to fix this in wine, for example by ordering > executability for every memory allocation ? > With regards, Pavel Troller We just have to find out _why_ it breaks. Should not be too hard with some backtraces or similar. Ciao, Marcus
Re: Executing wine over make segfaults.
> > this is what i did - and also suggest quite some time ago him(?)/list. i > had the same problem since .16 kernels (unstable(~) gentoo-source > ebuild). since that change everything works fine (.18 now). > Hi! Yes, you did, and you did correctly. I just rebooted the x86_64 machine with noexec=off. The app runs with no problems. Does it mean that something changed in noexec between .17 and .18 ? Why wine worked well with noexec and 2.6.17 ? But it's really wrong: I don't want to compromise my security because of running wine. Is there a chance to fix this in wine, for example by ordering executability for every memory allocation ? With regards, Pavel Troller
Re: Executing wine over make segfaults.
On Mon, Nov 06, 2006 at 10:29:22PM +0800, Dmitry Timoshkov wrote: > > 3) I'm using exec-shield patch, but I can disable it (for sure, > > tested by the pax testing suite) using a procfs entry. Even with > > exec-shield disabled the crash is still there, and in 2.6.17, even > > with exec-shield enabled, there is no crash. > Then probably the only way to unbreak the broken apps is to add > noexec=off to the kernel command line. this is what i did - and also suggest quite some time ago him(?)/list. i had the same problem since .16 kernels (unstable(~) gentoo-source ebuild). since that change everything works fine (.18 now). -- cu pgp6W1XoUcz12.pgp Description: PGP signature
Re: Executing wine over make segfaults.
"Pavel Troller" <[EMAIL PROTECTED]> wrote: >fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling >work-around Are you using SeLinux or some other patches? If so, please try building your kernel from the vanilla Linux kernel.org sources. Hi Mike! I take you very seriously, I know that you are a real wine guru, but I know that those messages are not related to the segfaulting problem. 1) These messages appear only on a x86_64 architecture. On i386 the crash is the same but the messages are not there. 2) There are other apps, which work perfectly, although they emit the same messages. 3) I'm using exec-shield patch, but I can disable it (for sure, tested by the pax testing suite) using a procfs entry. Even with exec-shield disabled the crash is still there, and in 2.6.17, even with exec-shield enabled, there is no crash. Then probably the only way to unbreak the broken apps is to add noexec=off to the kernel command line. -- Dmitry.
Re: Executing wine over make segfaults.
> > >fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling > >work-around > > Are you using SeLinux or some other patches? If so, please try building > your kernel from the vanilla Linux kernel.org sources. > Hi Mike! I take you very seriously, I know that you are a real wine guru, but I know that those messages are not related to the segfaulting problem. 1) These messages appear only on a x86_64 architecture. On i386 the crash is the same but the messages are not there. 2) There are other apps, which work perfectly, although they emit the same messages. 3) I'm using exec-shield patch, but I can disable it (for sure, tested by the pax testing suite) using a procfs entry. Even with exec-shield disabled the crash is still there, and in 2.6.17, even with exec-shield enabled, there is no crash. With regards, Pavel Troller
Re: Executing wine over make segfaults.
L. Rahyen wrote: fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling work-around Are you using SeLinux or some other patches? If so, please try building your kernel from the vanilla Linux kernel.org sources. Mike
Re: Executing wine over make segfaults.
On Mon, Nov 06, 2006 at 08:46:40AM +0100, Pavel Troller wrote: > > This seems to be Wine-related problem (but not neccessary Wine bug) > > because > > everything else works fine with 2.6.18.1 kernel; I'm not alone who have > > strange problems with Wine under 2.6.18 kernel. > > No, you are not. I've posted a very similar problem with wine & 2.6.18 > a couple of weeks ago. > Just to recall, my experiences with the problem: > 1) Not every windows app causes wine to segfault. There are fairly complex, > networked apps, which work flawlessly (DC++), other ones, much more > simple, cause wine to crash, like wine's itself "rundll.exe setupapi.dll" > when it tries to create a fresh .wine directory. Please see my post to > wine-devel dated Oct 11, with subject "wine segfaulting" for details. > There is even a strace snippet. > 2) It crashes almost identically on both i386 and x86_64 architectures, with > the same applications. > 3) As demonstrated in 1), it does so even in the .wine directory build > process, which means that no DLL overrides or other user-broken things > can be involved. > 4) No user/system settings can change this. Tried to increase various > ulimits, manipulate (disable) exec-shield etc. Just the only solution > known to me is to boot 2.6.17 or less, which I cannot normally because > of other features I currently need from 2.6.18. > 5) I'm testing wine on the system it was built on (with 2.6.18). It should > ensure maximum compatibility with its kernel (I'm using live kernel > includes for and ). However, it works when transferred > to another system running 2.6.17. > I'm ready to perform some debugging; however, currently I don't know where > to start. Can you get backtraces in gdb ? I am using a 2.6.18 based openSUSE 10.2 Beta1 kernel and Wine works fine there. (AMD64 however). Ciao, Marcus
Re: Executing wine over make segfaults.
> This seems to be Wine-related problem (but not neccessary Wine bug) > because > everything else works fine with 2.6.18.1 kernel; I'm not alone who have > strange problems with Wine under 2.6.18 kernel. No, you are not. I've posted a very similar problem with wine & 2.6.18 a couple of weeks ago. Just to recall, my experiences with the problem: 1) Not every windows app causes wine to segfault. There are fairly complex, networked apps, which work flawlessly (DC++), other ones, much more simple, cause wine to crash, like wine's itself "rundll.exe setupapi.dll" when it tries to create a fresh .wine directory. Please see my post to wine-devel dated Oct 11, with subject "wine segfaulting" for details. There is even a strace snippet. 2) It crashes almost identically on both i386 and x86_64 architectures, with the same applications. 3) As demonstrated in 1), it does so even in the .wine directory build process, which means that no DLL overrides or other user-broken things can be involved. 4) No user/system settings can change this. Tried to increase various ulimits, manipulate (disable) exec-shield etc. Just the only solution known to me is to boot 2.6.17 or less, which I cannot normally because of other features I currently need from 2.6.18. 5) I'm testing wine on the system it was built on (with 2.6.18). It should ensure maximum compatibility with its kernel (I'm using live kernel includes for and ). However, it works when transferred to another system running 2.6.17. I'm ready to perform some debugging; however, currently I don't know where to start. With regards, Pavel Troller
Re: Executing wine over make segfaults.
> ...with same configuration under 2.6.18.1 kernel Wine doesn't work. > ... > I have errors like these ones when I try to launch something with Wine: > > fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling > work-around fixme:seh:check_no_exec No-exec fault triggered at 0x4c8ad4, > enabling work-around err:seh:setup_exception stack overflow 40 bytes in > thread 0009 eip f7c9e9ff esp 00230fd8 stack 0x231000-0x34 This seems to be Wine-related problem (but not neccessary Wine bug) because everything else works fine with 2.6.18.1 kernel; I'm not alone who have strange problems with Wine under 2.6.18 kernel. Any ideas why this happening? Or at least give me some clue how I can debug this. Only thing I can say this is definitely not kernel configuration problem, and isn't "simple bug" in Wine because under 2.6.16.18 it works perfectly. What I want is at least find true source of this problem so I can file proper bug report and maybe try to fix this myself.
Re: Executing wine over make segfaults.
> > I recently tried 2.6.18.1 kernel and wine stoped working. Then I > > downgraded to 2.6.16.18 and wine working fine now. > > I'm using a custom built 2.6.18.1 on Debian Unstable/AMD64 now, and Wine > works fine for me, so this is unlikely to be a Wine problem. I compiled 2.6.18.1 with same .config. As expected, Wine stoped working. I don't know yet why exactly this happens but fact is that with same configuration under 2.6.18.1 kernel Wine doesn't work. As you said you have 2.6.18.1 and working Wine. So please tell your compiler, X server versions and compilation options for Wine. Also I very appreciate if you send me your .config file so I can try it on my system (I use Debian testing amd64 distribution). I have errors like these ones when I try to launch something with Wine: fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling work-around fixme:seh:check_no_exec No-exec fault triggered at 0x4c8ad4, enabling work-around err:seh:setup_exception stack overflow 40 bytes in thread 0009 eip f7c9e9ff esp 00230fd8 stack 0x231000-0x34 Some applications even open window but soon after these messages crash. Factually, all my Windows apps crash! Only exceptions that I found are winecfg and notepad, but everything else including all my games, viewers, players and editors crash. Under 2.6.16.18 Wine works perfectly. P.S. I use gcc 4.0.2 and Wine compiled by following commands: LDFLAGS="-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32" ./configure \ --x-libraries=/emul/ia32-linux/usr/X11R6/lib/ --x-includes=/emul/ia32-linux/usr/X11R6/include --with-x && \ make depend && \ make all && \ sudo make install;
Re: Executing wine over make segfaults.
L. Rahyen wrote: The system is gentoo linux (2.6.18-gentoo-r1) I recently tried 2.6.18.1 kernel and wine stoped working. Then I downgraded to 2.6.16.18 and wine working fine now. I'm using a custom built 2.6.18.1 on Debian Unstable/AMD64 now, and Wine works fine for me, so this is unlikely to be a Wine problem. Mike
Re: Executing wine over make segfaults.
> The system is gentoo linux (2.6.18-gentoo-r1) I recently tried 2.6.18.1 kernel and wine stoped working. Then I downgraded to 2.6.16.18 and wine working fine now. After doing some important work, I will recompile 2.6.18.1 again with same .config and will see what happens. But because difference of .config between my 2.6.16.18 and 2.6.18.1 wasn't very big I think this is Wine problem (probably not Linux problem because everything works perfectly with new kernel). But I must try exactly same .config to be sure (only some deprecated options will be automatically excluded by "make menuconfig"). > I could try installing an older version of gcc or an older kernel and see if that helps. If downloading 39M isn't big problem for you then please try kernel 2.6.16.18. You can download it here: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.18.tar.bz2
Re: Executing wine over make segfaults.
# wine --version Works! But: Makefile - test: wine --version - Then run: #make test Wine will segfault! I am having the same problem. I use wine to run a compiler from a Makefile. A few months ago, it worked fine, but recently it stopped working. I even downgraded to versions that had worked before, but without success. I have a few older systems that rarely get updated and are working fine, so I was not too concerned about it, but when I saw that 0.9.24 worked, I thought I was back in business except it doesn't work from make. The system is gentoo linux (2.6.18-gentoo-r1) wine compiled like this: ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --sysconfdir=/etc/wine --without-curses --without-opengl --with-x --disable-trace --disable-debug --build=i686-pc-linux-gnu Do you have any special kernel compile options in use? It's gentoo, so everything is custom compiled, but I try to keep it pretty vanilla. I don't think I have stack-protector on unless that is the default for gcc-4.1.1 I could try installing an older version of gcc or an older kernel and see if that helps. Any other ideas? Thanks for your time. _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Re: Executing wine over make segfaults.
On Mon, Oct 30, 2006 at 08:36:48AM +0100, Jimmy W wrote: > It says that wine is compiled with the: > > ./configure CFLAGS=-fno-stack-protector > > So the bug shud not apply, also i have been installing binaries for > other distribution (debian binaries) also from winehq own ubuntu rep. > > I think the problem is deeper in wine. Do you have any special kernel compile options in use? Any other deriviations from traditional distribution kernels? Ciao, Marcus
Re: Executing wine over make segfaults.
It says that wine is compiled with the: ./configure CFLAGS=-fno-stack-protector So the bug shud not apply, also i have been installing binaries for other distribution (debian binaries) also from winehq own ubuntu rep. I think the problem is deeper in wine. /Jimmy sön 2006-10-29 klockan 13:09 -0800 skrev Thomas Kho: > On 10/29/06, Jimmy W <[EMAIL PROTECTED]> wrote: > > I got a simple problem, that got really hard to fix. > > > > > > I am trying to cross-compile stuff over a Makefile with ms compiler. > > > > Problem is that when make are executing wine as a command, wine > > segfaults. > > > > An example: > > > > # wine --version > > Works! > > > > But: > > > > Makefile > > - > > test: > >wine --version > > - > > > > Then run: > > #make test > > > > Wine will segfault! > > Your problem might be that the Edgy gcc has stack-protector on. I ran > across a segfault when building on my newly upgraded Edgy Eft machine > this morning. See 'Edgy Eft Notes' at > http://wiki.winehq.org/Recommended_Packages for info and a link to an > Ubuntu bug discussion. > > -Tommy
Re: Executing wine over make segfaults.
On 10/29/06, Jimmy W <[EMAIL PROTECTED]> wrote: I got a simple problem, that got really hard to fix. I am trying to cross-compile stuff over a Makefile with ms compiler. Problem is that when make are executing wine as a command, wine segfaults. An example: # wine --version Works! But: Makefile - test: wine --version - Then run: #make test Wine will segfault! Your problem might be that the Edgy gcc has stack-protector on. I ran across a segfault when building on my newly upgraded Edgy Eft machine this morning. See 'Edgy Eft Notes' at http://wiki.winehq.org/Recommended_Packages for info and a link to an Ubuntu bug discussion. -Tommy
Executing wine over make segfaults.
I got a simple problem, that got really hard to fix. I am trying to cross-compile stuff over a Makefile with ms compiler. Problem is that when make are executing wine as a command, wine segfaults. An example: # wine --version Works! But: Makefile - test: wine --version - Then run: #make test Wine will segfault! I have tried making a wrapper that will reset env and argv fith static values, and then exec wine with totally new variables, and still fails. Specifications: ubuntu edgy, wine 0.9.22 running as local user. Thankfull for all help. Jimmy Wennlund
