Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
FIXED: After profile switch 13.0-17.0 Wine apps stop working
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Tyrus
Guru
Guru


Joined: 03 Feb 2018
Posts: 300

PostPosted: Fri Mar 02, 2018 4:31 pm    Post subject: Reply with quote

@Chiitoo:
Sorry maybe I was a bit short with my last posting, my statement was a comment on this:

mega_flow wrote:

I find llvm-5 is what the crash the game on my system
make sure u uninstall llvm-5, after u install llvm-4. Portage wil not uninstall this automatic if u mask the 5 version.
then rebuild mesa


Mesa is used by wine-vanilla when you want to have a software renderer. To activate that, the useflag is opengl, not os-mesa. Of course you can just stay on your hardware nvidia-drivers. But some games have an ugly display bug when not using the software-renderer.

If you look at the 'emerge --info wine-staging' by Erdie then you find the useflag opengl as package useflag.
So it could be possible that wine-apps are using mesa for software-rendering. I don't know how Erdie has configured them.

Whatever - I have no solution for Erdie's problem also. I am sorry. :(
Back to top
View user's profile Send private message
Tyrus
Guru
Guru


Joined: 03 Feb 2018
Posts: 300

PostPosted: Fri Mar 02, 2018 6:33 pm    Post subject: Reply with quote

@Erdie:
Do you have a log for the whole wine-session? Could help to see what wine is doing before the game crashes.

Suggestion: q4wine logs your wine-prefix if there is no other log already.

Edit:
Do it this way:

Code:

WINEPREFIX=~/.local/share/wineprefixes/Gabriel\ Knight\ 3/ wine ~/.local/share/wineprefixes/Gabriel\ Knight\ 3/drive_c/Sierra/Gabriel\ Knight\ 3/GK3.exe


Then you get for example this:

Code:

0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33e394,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33e114,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33db24,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33db24,0x00000000), stub!
0009:fixme:ddraw:ddraw7_Initialize Ignoring guid {aeb2cdd4-6e41-43ea-941c-8361cc760781}.
0009:fixme:ddraw:DirectDrawEnumerateExA flags 0x00000006 not handled
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33e114,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33e4b4,0x00000000), stub!
0009:fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16
0009:fixme:d3d:surface_cpu_blt Filter WINED3D_TEXF_LINEAR not supported in software blit.
0009:fixme:amstream:IAMMultiMediaStreamImpl_AddMediaStream Specifying a stream object in params is not yet supported
0009:err:quartz:GetClassMediaFile Media class not found
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33eb24,0x00000000), stub!
0009:fixme:amstream:MediaStreamFilterImpl_Run (0x1736870)->(7a121): Stub!
0009:fixme:amstream:IDirectDrawStreamSampleImpl_Update (0x173eaf0)->(0,(nil),(nil),0): stub
0009:fixme:amstream:MediaStreamFilterImpl_Pause (0x1736870)->(): Stub!
0009:fixme:amstream:MediaStreamFilterImpl_Stop (0x1736870)->(): Stub!
0009:fixme:ddraw:ddraw7_FlipToGDISurface iface 0x1df8e0 stub!


That was with Gabriel Knight 3. You have to adjust the command for your needings but it's a template I hope.
Wine creates a lot debug info that could help eventually to find a solution.
Back to top
View user's profile Send private message
kurisu
Apprentice
Apprentice


Joined: 19 Jan 2011
Posts: 159
Location: Munich, Germany

PostPosted: Fri Mar 02, 2018 7:43 pm    Post subject: Reply with quote

You need at least Wine 3.0 on 17.0 profiles as support for PIE was added only in version 3.0-rc3.
Back to top
View user's profile Send private message
blopsalot
Apprentice
Apprentice


Joined: 28 Jan 2017
Posts: 231

PostPosted: Mon Mar 05, 2018 4:15 am    Post subject: Reply with quote

unsafe CFLAGS are stripped, wine has worked fine on hardened for a long time. mesa does load the proprietary drivers, but i have never seen llvm make any difference to nvidia cards, it's the gallium stuff that is optimized for llvm. I still say use a 32bit prefix. thats first step of wine troubleshooting always, lol. old games with crappy copy protection, wow64 stumbles more often.

you would want to reinstall the game after doing those commands, you were trying to run it from 64bit installation still. u want it to be in the 32 bit ~/.wine32 not the 64 bit ~/.wine
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again

PostPosted: Mon Mar 05, 2018 12:19 pm    Post subject: Reply with quote

Tyrus wrote:
Mesa is used by wine-vanilla when you want to have a software renderer. To activate that, the useflag is opengl, not os-mesa. Of course you can just stay on your hardware nvidia-drivers. But some games have an ugly display bug when not using the software-renderer.

If you look at the 'emerge --info wine-staging' by Erdie then you find the useflag opengl as package useflag.
So it could be possible that wine-apps are using mesa for software-rendering. I don't know how Erdie has configured them.

Yes, I was hoping 'eselect opengl' would have shown 'xorg-x11' as the active implementation, since I believe that would have meant software rendering.

Furthermore, in 'app-emulation/wine-staging', the 'osmesa' USE-flag requires 'media-libs/mesa' (and 'opengl'). However, 'opengl' alone does not require Mesa.

kurisu wrote:
You need at least Wine 3.0 on 17.0 profiles as support for PIE was added only in version 3.0-rc3.

Staging 2.21 works just fine for me still though, but of course I might just not have bumped into an application that shows the issue...
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Tyrus
Guru
Guru


Joined: 03 Feb 2018
Posts: 300

PostPosted: Mon Mar 05, 2018 10:07 pm    Post subject: Reply with quote

Chiitoo wrote:

However, 'opengl' alone does not require Mesa.


It does. Look at the ebuild for wine-stagging-2.21:

Code:

[...]
COMMON_DEPEND="
[...]
   opengl? (
      virtual/glu[${MULTILIB_USEDEP}]
      virtual/opengl[${MULTILIB_USEDEP}]
   )
   osmesa? ( >=media-libs/mesa-13[osmesa,${MULTILIB_USEDEP}] )
[...]
   )"
[...]


You find it depends on virtual/opengl. Then look in the ebuild for virtual/opengl-7.0-r1:

Code:

# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EAPI=5

inherit multilib-build

DESCRIPTION="Virtual for OpenGL implementation"
SLOT="0"
KEYWORDS="alpha amd64 arm ~arm64 hppa ia64 ~mips ppc ppc64 ~s390 ~sh sparc x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~x64-solaris ~x86-solaris"

RDEPEND="
   || (
      >=media-libs/mesa-9.1.6[${MULTILIB_USEDEP}]
      media-libs/opengl-apple
   )"


media-libs/opengl-apple is not in my portage tree and would not fit for Erdie.
The useflag 'opengl' alone draws in mesa.
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again

PostPosted: Mon Mar 05, 2018 10:56 pm    Post subject: Reply with quote

Tyrus,

Ah, right. Me bad didn't think that one quite through...

Thanks!

I'll need to go refresh my memory on what the opengl and other configure options /actually/ do for Wine, and not just read the descriptions from 'configure'.

Edit:

Maybe at least enabling OpenGL does somewhat what I though it did, having it disabled meaning a lot of my games not running any longer. :]
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Sun Mar 18, 2018 9:01 am    Post subject: Reply with quote

I even figured out that now certain Steam games are crashing e. g. Half Life 2 and Portal 2. The whole system works properly. It seems to be that only binary applicatons are affected since I switched the profile. This does not look like success. Unfortunaltely binary proprietary applications are needed sometimes. I would like that this is not the case but it is.
_________________
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
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again

PostPosted: Sun Mar 18, 2018 12:47 pm    Post subject: Reply with quote

Okay, Half-Life 2 and Portal 2 I do own. You mean the native Linux builds of them crash? When do they crash, and is there anything interesting in the terminal when they do?

When they crash, do they just seem to quit ('dmesg' might show a segmentation fault), or do the hang, or do something completely different?
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21602

PostPosted: Sun Mar 18, 2018 4:25 pm    Post subject: Reply with quote

Erdie wrote:
It seems to be that only binary applicatons are affected since I switched the profile. This does not look like success. Unfortunaltely binary proprietary applications are needed sometimes.
Failures in closed-source applications are somewhat common, due to a combination of factors. First, particularly with games, closed-source implies that the game is not available without fee. This vastly reduces the chances that the right people will test it early. If the program was available without fee, even if only in a very limited context (such as only being able to complete a small portion of the game before hitting a paywall), it would be far easier for the right people to investigate it. Second, if it is closed-source and the program's master did something wrong, only that master can fix it. The distribution cannot simply make a patched copy that works correctly. You may need to enlist the aid of the program's master to fix this. If you are unlucky, you may need the master's assistance even to understand the problem.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Sun Mar 18, 2018 4:46 pm    Post subject: Reply with quote

Oh yes, I know the problem of proprietary software. But this does not change the situation. You can just not using it. But who of us does not like to e. g. play a game sometimes? This stuff is almost closed source, unfortunately.
The two games mentioned just quit with segmentations faults.
_________________
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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21602

PostPosted: Sun Mar 18, 2018 7:55 pm    Post subject: Reply with quote

Where does it segfault? What instruction failed? What was that instruction trying to do?
Back to top
View user's profile Send private message
Tyrus
Guru
Guru


Joined: 03 Feb 2018
Posts: 300

PostPosted: Sun Mar 18, 2018 8:48 pm    Post subject: Reply with quote

Erdie wrote:
I even figured out that now certain Steam games are crashing e. g. Half Life 2 and Portal 2. The whole system works properly. It seems to be that only binary applicatons are affected since I switched the profile. This does not look like success. Unfortunaltely binary proprietary applications are needed sometimes. I would like that this is not the case but it is.


Have you tried app-emulation/wine-vanilla-3.0? It's the actual stable version at WineHQ. Don't try 3.1 or 3.2. They caused bugs when I tried them.

kurisu wrote:
You need at least Wine 3.0 on 17.0 profiles as support for PIE was added only in version 3.0-rc3.


That's the best explanation you got in this thread so far.
On the WineHQ site you find the following fixed bug-report: https://www.winehq.org/announce/3.0-rc3
Quote:

43217 Wine cannot execute position-independent (PIE) host executables via CreateProcess()


The profile-chance added PIE. So please give it a try. It sounds reasonable und explains that some binarys under wine<3.0 just segfaults.
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again

PostPosted: Mon Mar 19, 2018 7:08 am    Post subject: Reply with quote

Erdie wrote:
The two games mentioned just quit with segmentations faults.

Do you see where the error happens?

An example from 'dmesg':

Code:
ktorrent[16046]: segfault at 0 ip 00007f05a757af5d sp 00007ffde4a15308 error 4 in libQt5Core.so.5.11.0[7f05a72f2000+4b8000]

For example Portal 2 works okay for me with 'default/linux/amd64/17.0' (although for some reason it doesn't detect proper resolutions, but I digress).

I wouldn't be surprised if it had something to do with the bundled libraries from Steam, though at least for some it should nowadays prefer the host libraries, if they're newer. They wouldn't affect Wine though.
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Tue Mar 20, 2018 9:49 am    Post subject: Reply with quote

It crashes in the libc:

Code:

Mar 20 10:45:22 kellerkind crash_20180320103533_1.dmp[30749]: Uploading dump (out-of-process)
/tmp/dumps/crash_20180320103533_1.dmp
Mar 20 10:45:22 kellerkind kernel: traps: hl2_linux[30611] general protection ip:f75201fa sp:ffd8ca28 error:0
Mar 20 10:45:22 kellerkind kernel:  in libc-2.25.so[f74b0000+1c1000]
Mar 20 10:45:23 kellerkind crash_20180320103533_1.dmp[30749]: Finished uploading minidump (out-of-process): success = yes
Mar 20 10:45:23 kellerkind crash_20180320103533_1.dmp[30749]: response: CrashID=bp-90a565e0-dade-464e-8186-af9a02180320
Mar 20 10:45:23 kellerkind crash_20180320103533_1.dmp[30749]: file ''/tmp/dumps/crash_20180320103533_1.dmp'', upload yes: ''CrashID=bp-90a565e0-dade-464e-8186-af9a02180320''


This happens frequently since the system was switched to the new profile. I played these games in the past completly without issues so the instability just came up recently.
_________________
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
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again

PostPosted: Tue Mar 20, 2018 9:41 pm    Post subject: Reply with quote

Alrighty, that's pretty much what I was expecting. I've seen it quite a bit, though I never had it happen to myself.

I wonder if this isn't about the combination of GCC and glibc you are using.

For example, this bug report at OpenSUSE seems interesting: bugzilla.opensuse.org: Bug 1048861

There's also what Cyker said:

Cyker wrote:
It might not be Profile-17 per-se; went back to Profile 13 after moving to 17 broke half of my binary programs (Acrobat Reader-9 and Thunderbird-1.5 being the most deal-breakery)

However, after upgrading gcc from 5.4 to 6.4 and recompiling bits of the toolchain, most notably glibc, the same binaries broke again so, at least in my case, gcc-6.4 is doing something weird that is causing this breakage; I originally thought it was Profile 17 enabling PIE, but since Profile 13 doesn't have PIE enabled it would seem unlikely that's the problem.

If you feel adventurous enough, you could build and install GCC 7.3.0 for example (I think 7.2.0 should be okay too, but I'm on 7.3.0-r1 myself (7.3.0 would probably be safer than r1 if going for 7.3)), following the usual GCC upgrade recommendations (I wouldn't build the whole world anew), and re-build glibc using that version instead.

Big disclaimer though: things might break, so only try this if you're ready to pick up the pieces! :]
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Wed Mar 21, 2018 11:30 am    Post subject: Reply with quote

Thanks Chiitoo,

I am feeling like it would be better to wait. This looks like an issue which might have been fixed somtimes in the future automatically. I had some similar issues in the past. I am afraid of breaking much more stuff. I can live with missing some games actually. Maybe there will be a solution in the future when a new gcc version is in the stable branch.
_________________
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
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again

PostPosted: Wed Mar 21, 2018 12:18 pm    Post subject: Reply with quote

That's a good decision, since I can't even promise it is the cause for any of this.

I might set up a clean, stable installation and test it locally myself. I'll definitely post my findings if I indeed find something of interest.
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again

PostPosted: Tue Mar 27, 2018 10:52 pm    Post subject: Reply with quote

I created a clean and stable amd64 installation, but still couldn't see this issue happen with Wine.

As for Portal 2, that actually does segfault after a level has loaded, and a character speaks (which is only few seconds in the first level; other levels play fine until a voice clip). Audio does work in general, and in the game, but things go south when those clips are triggered.

Looking at my backtraces, it doesn't seem like the issue at OpenSUSE that I linked to, although theirs do have audio related stuff going on.

My traces start like so:

Code:
pthread_cond_signal@@GLIBC_2.3.2 () from /lib32/libpthread.so.0

So far building and installing higher versions of glibc and gcc hasn't changed that behaviour.

Will poke around more.
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Wed Mar 28, 2018 7:00 am    Post subject: Reply with quote

In wine only certain applications have segfaults. I can´t see any logical rules up to now.
_________________
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
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again

PostPosted: Thu Mar 29, 2018 8:29 pm    Post subject: Reply with quote

With regards to Portal 2, it seems it might be the same issue as with Borderlands 2 here: Borderlands 2 steam

PuckPoltergeist wrote:
I've had the same problem on my amdfam10 machine and after some search I found this: https://bugs.archlinux.org/task/54136

Stack alignment is the problem here too. I've identified the following packages need to be build with -mstackrealign:
Code:

sys-libs/glibc
x11-libs/libxcb
media-libs/openal
media-sound/pulseaudio


Unfortunately for glibc this means hacking the eclass. But after recompiling the packages Borderlands2 works again for me.

I forced only 'sys-libs/glibc-2.26-r6' to build with '-mstackrealign' and the segfault is gone.

While wondering about why this Ryzen machine doesn't show the issue, I remembered what was mentioned in the Arch Linux bug:

Dan Elkouby wrote:
I'm experiencing a similar issue with Portal. The game crashes in `__strpbrk_sse42` during startup, before it can even reach the menu.

This bug might be related to GCC 7.1. I couldn't reproduce the issue with glibc 2.25-1 nor 2.25-2 after rebuilding them with `-march=native`, but with the defaults of `-march=x86-64 -mtune=generic`, the game crashes on both.

I've checked the flags enabled by `-march=native` on my ivy bridge system, then tested by elimination and found out that enabling `-mavx` is enough to get the game running. I have no idea why this would happen, especially considering the problematic functions seem to be SSE 4.2, not AVX, but can anyone else confirm this?

Dan Elkouby wrote:
Investigated some more, looks like GCC replaces all SSE instructions with their AVX equivalents when -mavx is in use. strpbrk and strspn are internally the same function and are written in C using GCC's SIMD extensions. This is very likely a GCC bug as the current build in multilib using GCC 6.3 works fine.

Jan Steffens wrote:
It attempts a MOVAPS (aligned store) from XMM3 into the memory pointed to by ESP, but the stack pointer is not aligned to 16 bytes. The AVX version avoids using the stack.

Now my Ryzen uses the following:

Code:
CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3"

While the test machine (dual-core Athlon 7750 (amdfam10)) has:

Code:
CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a

So perhaps it has something to do with Ryzen using 'avx'.

No idea if the Wine issues could be related to the same cause, not until I manage to get something to crash at least. :]
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Fri Mar 30, 2018 10:50 am    Post subject: Reply with quote

Up to now I used
Code:

-march=bdver2 -mprefer-avx128 -mvzeroupper -O2 -pipe

but I will try to change it to
Code:

-march=native -O2 -pipe


Most likely it will be no difference but I will try it anyway. I will rebuild glibc and look if something chanes.
_________________
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
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again

PostPosted: Fri Mar 30, 2018 12:10 pm    Post subject: Reply with quote

Yeah, I'm not expecting much, if anything to change with that either, but I believe it should be safe to try (if you decide to stick to those flags however, I might re-compile everything against them).

From your 'emerge --info' I see the following:

Code:
CPU_FLAGS_X86="mmx mmxext sse sse2 sse2i sse3 sse4 ssse3"

Are these set by you in 'make.conf'? There's a nifty tool, 'app-portage/cpuid2cpuflags', that will also generate them without you needing to look for them from '/proc/cpuinfo'.

If I remove mine, I'll get just these:

Code:
CPU_FLAGS_X86="mmx mmxext sse sse2"

So maybe you've already done that. I don't think this affects anything that doesn't make use of said USE_EXPAND though.

Looking around the internet, I see some references to 'bdver2' supporting 'avx', so I am hoping '-mprefer-avx128' actually affects this thing in your end.

Then again, comparing the build logs between the two machines I mentioned, I do see '-mavx' on both, even though the other one does not list 'avx' flag in its '/proc/cpuinfo'... so I don't know that to make of that.

I'll keep on poking around. I still gotta try this nasty workaround (that I'm not suggesting anyone to do unless they're prepared to break things) with the stable glibc and gcc (downgrading 'sys-libs/glibc' can be fun, but only if one likes picking up a lot of pieces, or/and if they really think they know what they're doing... so for anyone reading, disclaimer: don't do it, unless, you know, you really want to for some reason, but I'm not suggesting that you should do it, seriously!). :]
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Fri Mar 30, 2018 3:18 pm    Post subject: Reply with quote

In my make, conf I have:

Code:

CPU_FLAGS_X86="mmx mmxext sse sse2 sse2i sse3 sse4 ssse3"


if I emerge cpuid2cpflags, may I just remove it from make.conf? ah .. let me read the docu ;)


EDIT: Understood, it just gives a list of flags, I guess I need them to put into make.conf. I will do it now
_________________
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
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again

PostPosted: Sat Mar 31, 2018 1:13 pm    Post subject: Reply with quote

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.
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
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