View previous topic :: View next topic |
Author |
Message |
blopsalot Apprentice
Joined: 28 Jan 2017 Posts: 231
|
Posted: Sat Mar 31, 2018 3:30 pm Post subject: |
|
|
Chiitoo wrote: | Yeah, those flags used to be regular USE-flags, but now they have this dedicated variable.
On another note, Portal 2 seems to work with '-mstackrealign' using glibc-2.25-r10 and gcc-6.4.0-r1 as well.
I'm not sure where the bug really is, but I'm thinking Portal 2 (and other applications affected), or gcc/glibc. |
Here's a pretty good technical description, seems like it would be an issue effecting many others if it was not handled already though.
https://bugs.archlinux.org/task/27560
Erdie did you ever try using a 32bit prefix? I don't game anymore, but copy protection and 64bit prefix was always a problem. |
|
Back to top |
|
|
Chiitoo Administrator
Joined: 28 Feb 2010 Posts: 2573 Location: Here and Away Again
|
Posted: Sat Mar 31, 2018 4:36 pm Post subject: |
|
|
If that would be the same issue, I believe a lot more would be affected indeed.
Can't say it isn't the same issue, but I don't even remember hitting it back when it was reported there (could have forgotten all about it of course).
Either way, thanks for mentioning it! _________________ Kindest of regardses. |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Sat Mar 31, 2018 9:00 pm Post subject: |
|
|
Chiitoo wrote: | Yeah, those flags used to be regular USE-flags, but now they have this dedicated variable.
|
I thought I have to use it like this:
Code: |
CPU_FLAGS_X86="<Output of cpuid2cpuflags>"
|
and put this into make.conf. In the last 24 hours I recompiled about 1300 packages with this option. If you say this are USE flags I have to rebuild my system again _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Chiitoo Administrator
Joined: 28 Feb 2010 Posts: 2573 Location: Here and Away Again
|
Posted: Sun Apr 01, 2018 10:48 am Post subject: |
|
|
No, that seems correct.
I meant that they were regular USE-flags in the past, which got moved into their own variable.
There's an article over at our wiki, CPU_FLAGS_X86, that will explain it more fully. :]
As I mentioned though, as far as I know, these shouldn't affect packages other than those that actually make use of them.
For example, using 'app-portage/eix' on 'media-sound/audacity':
Code: | [I] media-sound/audacity
Available versions: 2.1.3-r1^t{tbz2} (~)2.2.1^t{tbz2} (~)2.2.2^t{tbz2} {alsa doc ffmpeg +flac id3tag jack +ladspa +lame libav +lv2 mad +midi nls +portmixer sbsms +soundtouch twolame vamp +vorbis +vst CPU_FLAGS_X86="sse"} |
You'll notice the CPU_FLAGS_X86 there.
CFLAGS however would affect most packages (for some, such as 'sys-libs/glibc' they are stripped to avoid a lot of issues users would easily encounter).
Going back to the Wine-specific issues, if they indeed stem from the same root cause, I wonder if building Wine itself with '-mstackrealign' would be enough. It might not have anything to do with it, but I would try it out if I had an example program that's crashing. Our Wine builds also strip CFLAGS, but there's USE="custom-cflags" for cases where that's not desirable.
I might not put too much hope on it though, and it might be a waste of CPU cycles, but I would still try it out just out of curiosity.
Also, yeah, as mentioned, trying out a 32-bit prefix is always a good idea when something goes wrong while using Wine. It's a relatively 'cheap' test, and amongst the top few 'first things to try' along with 'clean prefix' for example. :] _________________ Kindest of regardses. |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Sun Apr 01, 2018 7:54 pm Post subject: |
|
|
I did now:
Code: |
WINEARCH="win32" WINEPREFIX="~/wine32" wineboot
|
I assume if I just relauch a wine application it will now uwe this prefix? So I did and the afprod.exe (Aerofly professional deluse) crashed in the sam way as I posted initially.
By the way, I have to out me as a n00b How can I build wine with a non-standard CPU flag? I this done with a package.use entry? I which way do I have to maintain it?
Just in this way:
Code: |
echo "app-emulation/wine-staging CPU_FLAGS_X86=<my different option> >> /etc/portage/package.use
|
? _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Chiitoo Administrator
Joined: 28 Feb 2010 Posts: 2573 Location: Here and Away Again
|
Posted: Sun Apr 01, 2018 9:03 pm Post subject: |
|
|
Erdie wrote: | I did now:
Code: |
WINEARCH="win32" WINEPREFIX="~/wine32" wineboot
|
I assume if I just relauch a wine application it will now uwe this prefix? So I did and the afprod.exe (Aerofly professional deluse) crashed in the same way as I posted initially. |
You'll need to either do something like this:
Code: | $ WINEPREFIX="~/wine32" wine afprod.exe |
Or, for example, something like this:
Code: | $ export WINEPREFIX="~/wine32" |
With this, you can run Wine in the current shell session as if the default prefix was '~/wine32' (for 'session' think of the virtual terminal window/tab). The default is always "$HOME/.wine" unless you permanently, or temporarily change it in some way not limited to these two examples.
You can think of the new prefix as a new Windows installation, meaning you'll need to re-install (or move, if that's enough for the application) the software into it before you can use it, just like the first time you ever used it.
You do not need to specifiy WINEARCH every time, as it can not be changed after the prefix has been created.
I prefer keeping the default as it is, and specify the WINEPREFIX for all custom prefix needs, when I need them (if I keep one around for longer, I create a small 'wrapper' script for it).
Quote: | By the way, I have to out me as a n00b ;) How can I build wine with a non-standard CPU flag? I this done with a package.use entry? I which way do I have to maintain it?
Just in this way:
Code: |
echo "app-emulation/wine-staging CPU_FLAGS_X86=<my different option> >> /etc/portage/package.use
|
? |
And I'm the noob unlimited. :]
It's almost always better to ask if unsure about something, though I'm horrible at that myself, and instead tend to go down the trial and error path.
There probably shouldn't be a need to think about the CPU_FLAGS_X86 after you've set them in 'make.conf'. If you wanted to try the 'custom-cflags' I mentioned, the most easy/quick way I can think of right now would be something like this:
Code: | # CFLAGS="$CFLAGS -mstackrealign" CXXFLAGS="$CFLAGS" USE="custom-cflags" emerge -1a wine-vanilla |
This will not modify your existing configuration, but adds to them only for this one emerge, and you don't need to edit any files and forget to change them back after the test. :] _________________ Kindest of regardses. |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Mon Apr 02, 2018 7:32 am Post subject: |
|
|
blopsalot wrote: | Chiitoo wrote: | Yeah, those flags used to be regular USE-flags, but now they have this dedicated variable.
On another note, Portal 2 seems to work with '-mstackrealign' using glibc-2.25-r10 and gcc-6.4.0-r1 as well.
I'm not sure where the bug really is, but I'm thinking Portal 2 (and other applications affected), or gcc/glibc. |
Here's a pretty good technical description, seems like it would be an issue effecting many others if it was not handled already though.
https://bugs.archlinux.org/task/27560
Erdie did you ever try using a 32bit prefix? I don't game anymore, but copy protection and 64bit prefix was always a problem. |
Hi Blopsalot,
I tested 32bit prefix without sucess, but let me ask you, is this what you explained about portal 2 and -mstackrealign related to wine ? It seems to be. My portal2 is running native or do you think the portal version is a wine - based thing?
-Erdie _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Mon Apr 02, 2018 7:36 am Post subject: |
|
|
I build wine-staging with "-mstackrealign" and startet afproc.exe with 32bit prefix. The result is:
Code: |
WINEPREFIX="/home/martin/.wine32" wine ~/.wine32/drive_c/Program\ Files\ \(x86\)/afpd/afprod.exe
fixme:winediag:start_process Wine Staging 2.21 is a testing version containing experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
fixme:dwmapi:DwmIsCompositionEnabled 0x6d5d3018
fixme:iphlpapi:NotifyIpInterfaceChange (family 0, callback 0x6a0cb608, context 0x83b750, init_notify 0, handle 0x103e794): stub
wine: configuration in '/home/martin/.wine32' has been updated.
wine: Unhandled page fault on read access to 0x00000008 at address 0x43eff8 (thread 0009), starting debugger...
|
-Erdie _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Chiitoo Administrator
Joined: 28 Feb 2010 Posts: 2573 Location: Here and Away Again
|
Posted: Mon Apr 02, 2018 8:02 pm Post subject: |
|
|
Erdie wrote: | blopsalot wrote: | Chiitoo wrote: | Yeah, those flags used to be regular USE-flags, but now they have this dedicated variable.
On another note, Portal 2 seems to work with '-mstackrealign' using glibc-2.25-r10 and gcc-6.4.0-r1 as well.
I'm not sure where the bug really is, but I'm thinking Portal 2 (and other applications affected), or gcc/glibc. |
Here's a pretty good technical description, seems like it would be an issue effecting many others if it was not handled already though.
https://bugs.archlinux.org/task/27560
Erdie did you ever try using a 32bit prefix? I don't game anymore, but copy protection and 64bit prefix was always a problem. |
Hi Blopsalot,
I tested 32bit prefix without sucess, but let me ask you, is this what you explained about portal 2 and -mstackrealign related to wine ? It seems to be. My portal2 is running native or do you think the portal version is a wine - based thing?
-Erdie |
I guess you meant me with the part with portals. :]
When I was talking about Portal 2, it was the Linux build I was testing (well I did also test running the Windows build via Wine, but it worked either way).
One of the things I've been wondering is indeed if the cause is the same for the native Linux game issues, and your Wine issues. It still might be, but I'm not sure what to try next to verify it.
Erdie wrote: | I build wine-staging with "-mstackrealign" and startet afproc.exe with 32bit prefix. The result is:
Code: |
WINEPREFIX="/home/martin/.wine32" wine ~/.wine32/drive_c/Program\ Files\ \(x86\)/afpd/afprod.exe
fixme:winediag:start_process Wine Staging 2.21 is a testing version containing experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
fixme:dwmapi:DwmIsCompositionEnabled 0x6d5d3018
fixme:iphlpapi:NotifyIpInterfaceChange (family 0, callback 0x6a0cb608, context 0x83b750, init_notify 0, handle 0x103e794): stub
wine: configuration in '/home/martin/.wine32' has been updated.
wine: Unhandled page fault on read access to 0x00000008 at address 0x43eff8 (thread 0009), starting debugger...
|
-Erdie |
Hm. It does seem a bit different from before at least.
Does it just hang there, without producing the backtrace?
Just for safety, I would try
Code: | $ cd ~/.wine32/drive_c/Program\ Files\ \(x86\)/afpd/ |
first, then
Code: | $ WINEPREFIX="/home/martin/.wine32" wine afprod.exe |
because some Windows applications don't like it if the working directory is something else than where the executable is. In Windows it is set differently, so the applications sometimes panic when it's not what they expect. Maybe this one works just fine like this, and you know it does, but I figured it's worth mentioning. :] _________________ Kindest of regardses. |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Sun Apr 15, 2018 8:01 am Post subject: |
|
|
Sorry for my late response. I am sometimes very busy outside of the gentoo world.
this is the results of running afprod.exe with wine32:
Code: |
Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0xf73c01fa).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:f73c01fa ESP:0032f108 EBP:7cdc85a0 EFLAGS:00010246( R- -- I Z- -P- )
EAX:00000000 EBX:00000000 ECX:f7512960 EDX:00000000
ESI:00000002 EDI:00000003
Stack dump:
0x0032f108: 7ce742c8 00000001 00000001 f7514000
0x0032f118: 00000000 00000000 f75147b0 dc15e000
0x0032f128: 0032f3f8 00000001 f73c728b 00000000
0x0032f138: f7514000 00000004 00000000 f73c8680
0x0032f148: 7ce68dd8 00000000 f73c728b 0032f3f8
0x0032f158: 00000068 00000000 0032f448 795774f3
000c: sel=0067 base=00000000 limit=00000000 32-bit r-x
Backtrace:
=>0 0xf73c01fa _IO_file_seekoff+0x52() in libc.so.6 (0x7cdc85a0)
1 0xf73bc821 fseek+0x80() in libc.so.6 (0x0032f240)
2 0x79c974ca in libnvidia-glcore.so.390.42 (+0x13af4c9) (0x00000215)
3 0x79c9af3e in libnvidia-glcore.so.390.42 (+0x13b2f3d) (0x0032f330)
4 0x79c9604b in libnvidia-glcore.so.390.42 (+0x13ae04a) (0x0032f330)
5 0x79c87c0f in libnvidia-glcore.so.390.42 (+0x139fc0e) (0x7cea8ec0)
6 0x79c87dc8 in libnvidia-glcore.so.390.42 (+0x139fdc7) (0x00000000)
7 0x79c89d8c in libnvidia-glcore.so.390.42 (+0x13a1d8b) (0x0032f8dc)
8 0x79e8308f in libnvidia-glcore.so.390.42 (+0x159b08e) (0x7d24b008)
9 0x79e85fa4 in libnvidia-glcore.so.390.42 (+0x159dfa3) (0x7d6d5008)
10 0x79ccd8fe in libnvidia-glcore.so.390.42 (+0x13e58fd) (0x7cd7601c)
11 0x79ccdbfe in libnvidia-glcore.so.390.42 (+0x13e5bfd) (0x7cd7601c)
12 0x79e83afe in libnvidia-glcore.so.390.42 (+0x159bafd) (0x7d434000)
13 0x79e81f0b in libnvidia-glcore.so.390.42 (+0x1599f0a) (0x7d434000)
14 0x79e82b88 in libnvidia-glcore.so.390.42 (+0x159ab87) (0x7d434000)
15 0x79ec11f6 in libnvidia-glcore.so.390.42 (+0x15d91f5) (0x7d434000)
16 0x7d831c20 (0x0032fc38)
17 0x00542534 in afprod (+0x142533) (0x08c9b9e4)
0xf73c01fa _IO_file_seekoff+0x52 in libc.so.6: ldsl %eax,%edi
Modules:
Module Address Debug info Name (85 modules)
PE 400000- 9866000 Export afprod
ELF 788e8000-7a7f9000 Dwarf libnvidia-glcore.so.390.42
ELF 7a800000-7a938000 Deferred opengl32<elf>
\-PE 7a820000-7a938000 \ opengl32
ELF 7b400000-7b7ef000 Deferred kernel32<elf>
\-PE 7b420000-7b7ef000 \ kernel32
ELF 7bc00000-7bd2f000 Deferred ntdll<elf>
\-PE 7bc40000-7bd2f000 \ ntdll
ELF 7c000000-7c004000 Deferred <wine-loader>
ELF 7d5b0000-7d6c9000 Deferred libglx_nvidia.so.0
ELF 7d720000-7d7a0000 Deferred libgldispatch.so.0
ELF 7d7a0000-7d822000 Deferred libgl.so.1
ELF 7d878000-7d960000 Deferred libasound.so.2
ELF 7d980000-7d99f000 Deferred libglx.so.0
ELF 7d9b0000-7d9e1000 Deferred winealsa<elf>
\-PE 7d9c0000-7d9e1000 \ winealsa
ELF 7da10000-7db42000 Deferred oleaut32<elf>
\-PE 7da30000-7db42000 \ oleaut32
ELF 7dd10000-7dd48000 Deferred uxtheme<elf>
\-PE 7dd20000-7dd48000 \ uxtheme
ELF 7dd48000-7de66000 Deferred comctl32<elf>
\-PE 7dd50000-7de66000 \ comctl32
ELF 7dfb8000-7dfdb000 Deferred mmdevapi<elf>
\-PE 7dfc0000-7dfdb000 \ mmdevapi
ELF 7dfe0000-7e02c000 Deferred dinput<elf>
\-PE 7dff0000-7e02c000 \ dinput
ELF 7e058000-7e05f000 Deferred libxfixes.so.3
ELF 7e060000-7e06c000 Deferred libxcursor.so.1
ELF 7e078000-7e07d000 Deferred libnvidia-tls.so.390.42
ELF 7e108000-7e132000 Deferred libexpat.so.1
ELF 7e138000-7e182000 Deferred libfontconfig.so.1
ELF 7e188000-7e1c5000 Deferred libpng16.so.16
ELF 7e1c8000-7e1da000 Deferred libbz2.so.1
ELF 7e1e0000-7e1f9000 Deferred libz.so.1
ELF 7e200000-7e2bb000 Deferred libfreetype.so.6
ELF 7e310000-7e319000 Deferred librt.so.1
ELF 7e320000-7e33c000 Deferred libbsd.so.0
ELF 7e340000-7e36c000 Deferred libxcb.so.1
ELF 7e370000-7e4bc000 Deferred libx11.so.6
ELF 7e4c8000-7e4db000 Deferred libxi.so.6
ELF 7e4e0000-7e4e4000 Deferred libxcomposite.so.1
ELF 7e4e8000-7e4f5000 Deferred libxrandr.so.2
ELF 7e4f8000-7e504000 Deferred libxrender.so.1
ELF 7e508000-7e50f000 Deferred libxxf86vm.so.1
ELF 7e510000-7e59d000 Deferred winex11<elf>
\-PE 7e520000-7e59d000 \ winex11
ELF 7e5a0000-7e5fa000 Deferred libncurses.so.6
ELF 7e600000-7e607000 Deferred libxdmcp.so.6
ELF 7e608000-7e60d000 Deferred libxau.so.6
ELF 7e610000-7e626000 Deferred libxext.so.6
ELF 7e628000-7e64c000 Deferred imm32<elf>
\-PE 7e630000-7e64c000 \ imm32
ELF 7e650000-7e6c1000 Deferred setupapi<elf>
\-PE 7e660000-7e6c1000 \ setupapi
ELF 7e6c8000-7e6e1000 Deferred hid<elf>
\-PE 7e6d0000-7e6e1000 \ hid
ELF 7e6e8000-7e704000 Deferred dinput8<elf>
\-PE 7e6f0000-7e704000 \ dinput8
ELF 7e708000-7e78a000 Deferred rpcrt4<elf>
\-PE 7e710000-7e78a000 \ rpcrt4
ELF 7e790000-7e8e9000 Deferred ole32<elf>
\-PE 7e7b0000-7e8e9000 \ ole32
ELF 7e8f0000-7e93e000 Deferred dsound<elf>
\-PE 7e900000-7e93e000 \ dsound
ELF 7e940000-7e95a000 Deferred version<elf>
\-PE 7e950000-7e95a000 \ version
ELF 7e960000-7eb61000 Deferred user32<elf>
\-PE 7e970000-7eb61000 \ user32
ELF 7eb68000-7eba0000 Deferred glu32<elf>
\-PE 7eb70000-7eba0000 \ glu32
ELF 7eba0000-7ec19000 Deferred advapi32<elf>
\-PE 7ebb0000-7ec19000 \ advapi32
ELF 7ec20000-7ed49000 Deferred gdi32<elf>
\-PE 7ec30000-7ed49000 \ gdi32
ELF 7ef50000-7efac000 Deferred libm.so.6
ELF 7efb0000-7efbd000 Deferred libnss_files.so.2
ELF 7efc0000-7efcd000 Deferred libnss_nis.so.2
ELF 7efd0000-7efeb000 Deferred libnsl.so.1
ELF 7eff0000-7effa000 Deferred libnss_compat.so.2
ELF f7348000-f734d000 Deferred libdl.so.2
ELF f7350000-f7518000 Dwarf libc.so.6
ELF f7518000-f7537000 Deferred libpthread.so.0
ELF f7588000-f7759000 Dwarf libwine.so.1
ELF f7760000-f7786000 Deferred ld-linux.so.2
ELF f778f000-f7790000 Deferred [vdso].so
Threads:
process tid prio (all id:s are in hex)
00000008 (D) Z:\home\martin\.wine\drive_c\Program Files (x86)\afpd\afprod.exe
["Z:\home\martin\.wine\drive_c\Program Files (x86)\afpd\afprod.exe"]
0000004d 15
0000004c 0
0000004b 0
00000009 0 <==
0000000e services.exe
[C:\windows\system32\services.exe]
00000022 0
0000001d 0
00000013 0
00000010 0
0000000f 0
00000011 winedevice.exe
[C:\windows\system32\winedevice.exe]
0000001a 0
00000017 0
00000016 0
00000012 0
0000001b plugplay.exe
[C:\windows\system32\plugplay.exe]
0000001f 0
0000001e 0
0000001c 0
00000020 winedevice.exe
[C:\windows\system32\winedevice.exe]
00000027 0
00000024 0
00000023 0
00000021 0
0000002e explorer.exe
[C:\windows\system32\explorer.exe /desktop]
00000032 0
00000031 0
00000030 0
0000002f 0
00000050 explorer.exe
[C:\windows\system32\explorer.exe /desktop]
00000054 0
00000053 0
00000052 0
00000051 0
System information:
Wine build: wine-2.21 (Staging)
Platform: i386
Version: Windows 7
Host system: Linux
Host version: 4.9.76-gentoo-r1
|
My question is, is it very risky to recompile glibc with "-mstackrealign"? If not, I would like to give it a try because of all other crashes with steam games etc. Clearly spoken, at the moment the whole steam stuff is almost unsuable. I cannot pay money for a new game if the chance that is crashes is about 50:50. This does not hurt me too much, since I am an old guy and the priority of playing games decreased in the last years. But anyway, I liked it for occasional gaming. This does not work anymore.
This is the console output:
Code: |
fixme:winediag:start_process Wine Staging 2.21 is a testing version containing experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
fixme:dwmapi:DwmIsCompositionEnabled 0x6d5d3018
fixme:iphlpapi:NotifyIpInterfaceChange (family 0, callback 0x6a0cb608, context 0x83b750, init_notify 0, handle 0x103e784): stub
wine: configuration in '/home/martin/.wine32' has been updated.
err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1600x1200x0 @60! (XRandR 1.2)
wine: Unhandled page fault on read access to 0xffffffff at address 0xf73c01fa (thread 0009), starting debugger...
|
Have a nice day
Erdie _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Chiitoo Administrator
Joined: 28 Feb 2010 Posts: 2573 Location: Here and Away Again
|
Posted: Sun Apr 15, 2018 10:49 pm Post subject: |
|
|
No sorries. :]
I would say that yes, it is fairly risky to mess with the CFLAGS of 'sys-libs/glibc', since it has been made so difficult (easy to by-pass, really, but difficult in the sense of not being possible just by flipping a USE-flag).
I haven't (yet) researched fully what effect the option actually has, but considering Arch Linux packaged glibc like that, at least optionally(?), it should perhaps mean that it's not a huge security issue at least (this is of course assuming a lot).
All that said, I did not notice anything exploding during my tests.
Downgrading glibc is probably something one should be more careful about, though it's doable as well, but can get tricky if several packages was already built against the higher version.
Conclusion being that I can't exactly recommend it if I'm not at least close to 100% sure of the outcome, but like I mentioned, I did try it out myself, and it worked for me.
With decent back-ups, if something did go wrong, it should be easy to go back. At the very least I'd recommend making use of the 'buildpkg' feature (see for example 'man make.conf' and look for 'buildpkg').
See also 'man quickpkg' for backing up already installed files without the need to re-emerge them (if using FEATURES="buildpkg" for example, I believe the package will be over-written in case one with the same version already exists, so one would need to manually move them out of the way before the next build if the old one is supposed to be kept for later).
Feeling a bit scatter-brained, but hopefully I'm making at least some sense...
Now for the console output!
Code: | err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1600x1200x0 @60! (XRandR 1.2) |
For some reason this makes me want to ask if you have a multi-display set-up? If you do use more than one monitor, it might be a good idea to enable the 'xinerama' USE-flag for Wine (and other packages that have it). It may not fix this particular issue, but I wouldn't be surprised if it helped.
Also, what does the 'xrandr' command display?
According to our wiki article on Xrandr, “graphic drivers like the binary Nvidia or AMD, do not support xrandr”, so the fact it's being tried there seems at least somewhat suspicious.
It might well explain the seemingly bogus colour-depth that's being requested (x0). I can't remember when I've last seen the XRandR message myself (didn't even have 'xrandr' installed though), so I'm not immediately aware of how fatal this can be.
I'd probably try enabling the virtual desktop just to see if that makes any difference, if you didn't try it yet.
Oh and just to make sure, for this run, did you first 'cd' to the 'afpd' directory?
I may have more ideas after a nap. Right now I can't really think of anything else to try. :\ _________________ Kindest of regardses. |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Mon Apr 16, 2018 8:45 pm Post subject: |
|
|
I had a multi monitor setup but recently buyed a new 2k Monitor and now I am using a single monitor setup. In the past, afpd was running fullscreen at 1600x1200. I alredy edited the config files to windowed mode and to check if this is the reason of the segfault but it was not. Normaly the application will automatically fall back to window mode if the selected mode wasnot found. Of course I can do this test again and edit the configuration manually to be sure that is is not the root cause of all mess. Let me go on an do it asap. Now it is almost 11 pm and I will have to work tomorrow so let me postpone this check to tomorrow Have a nice day. _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Wed Jun 20, 2018 9:19 am Post subject: |
|
|
In the meantime, I had given up - but not completly. Now gcc 7* is out and my hope is that this will change the situation.
I don´t belive that this is a wine issue because the majority of binary application are very unstable after the mentioned profile switch .. even steam games. It does not make sense to play any of them on my system, you can be sure it crashes at some time. And this was DEFINATELY not the case before I switched to gcc-6.4 and the new profle. I played steam games for about 10 years on this system, on (almost) the same hardware. Let´s see what gcc-7* brings to me.
I have to apologize not to react on all questions raised during this discussion, I was tired of endless troubleshooting and the real life has some challanges, too. Anyway I am interesed to get my old apps back to work and a usable gaming enviroment (even if is has lower priority). Thanks to all who tried to help and support.
-Erdie _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Chiitoo Administrator
Joined: 28 Feb 2010 Posts: 2573 Location: Here and Away Again
|
Posted: Wed Jun 20, 2018 2:18 pm Post subject: |
|
|
There's no need to apologize. Everyone have their priorities, and life can easily get in the way of everything.
We're here to help (or at least try to) at your pace (when we're able to keep up with it, and our pace allows for it).
It might be more weird if troubleshooting things like this did /not/ get frustrating at some point. :] _________________ Kindest of regardses. |
|
Back to top |
|
|
Tyrus Guru
Joined: 03 Feb 2018 Posts: 300
|
Posted: Wed Jun 20, 2018 7:03 pm Post subject: |
|
|
@Erdie:
As long as you stay with wine< 3.0.1 I doubt that gcc 7 will change much.
The stable version at WineHQ is still 3.0.1. If you use the gentoo stable version wine has problems with PIE host executables.
There is a bugreport: https://bugs.winehq.org/show_bug.cgi?id=43217
Caused by the profile change to 17.0 your system is using position independent code.
If you already tried the wine version 3.0.1 you never gave feedback about that. So I assume you never tried. |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Wed Jun 20, 2018 7:13 pm Post subject: |
|
|
Tyrus wrote: | @Erdie:
As long as you stay with wine< 3.0.1 I doubt that gcc 7 will change much.
The stable version at WineHQ is still 3.0.1. If you use the gentoo stable version wine has problems with PIE host executables.
There is a bugreport: https://bugs.winehq.org/show_bug.cgi?id=43217
Caused by the profile change to 17.0 your system is using position independent code.
If you already tried the wine version 3.0.1 you never gave feedback about that. So I assume you never tried. |
I am using wine stable. If this is the case I will immediatly switch to wine 3.0.1 and test afterwards. Thanks!
But first I will perform the migration to gcc-7 _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Thu Jun 21, 2018 6:03 am Post subject: |
|
|
Good new:
Yesterday evening I compiled gcc-7 and even more I switched to wine-staging-3.10 (unstable). Afterthat I tried to lauch Aerofly Professional Deluxe and it failed as usual
Then I started
Code: |
emerge -ae --keep-going @world
|
about ~1200 packages
and now, early in the morning, I am testing to launch afpd works!! It startet but I will not fully test, need to go to work first. In the evening all packges will be almosts be compiled. An then lets see. _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Fri Jun 22, 2018 6:21 am Post subject: |
|
|
Hi all,
compilation went through. Everything looks fine so far. My flying simulators are working. Steam games not yet tested. Wine is now wine staging. BTW I switched accidently to 2.21 and this works now, too. So the wine version had not impact on my problem. I looked like the gcc version was the devil. I will have further investigation and report.
-Erdie _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2576 Location: Heidelberg - Germany
|
Posted: Tue Jun 26, 2018 6:20 pm Post subject: |
|
|
I marked this thread as "FIXED" Many thanks to everyone for your great support! _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|