After emerge sync I did emerge -u --deep system -p and found winex-cvs-3.1 blocked. Emerge -u --deep world -p gives winex and glibc blocking each other. It has been suggested to wait for winex to catch up but who knows when that might be!? This problem was discussed and mentioned before glibc-2.3.2 was released to stable. Since waiting for winex and others to use 2.3.2 might take a while 1) can this be fixed or 2) how can it be undone?
it cant be fixed and it cant be undone all you can do is buy winex-transgaming for $5
So I understand - we're stuck. If I may ask - this was brought up as an issue (as well as for some other apps) in the posts asking for feedback. What harm would there have been waiting a little longer until more of the world catches up with this glibc version? It doesn't affect stuff that we build from source but what other apps are there that might have the same problem as winex? I'm not going to buy the binaries so at this point at least this app is broken. I would have thought that the latest stuff in the cvs tree would use glibc-2.3.2 - I assume the winex-cvs is getting the stuff out of the winex latest cvs. I'm in the process of moving so hopefully winex will catch up in a couple of weeks when I'm ready to start up again.
all other apps (as far as we know) have been patched either upstream or by us to work with the newest glibc. this glibc has been out for sometime ... the question was how long were we willing to wait ? i think we waited longer than we should, be thats my opinion. if you want wine support, then `emerge wine`, it works with glibc-2.3.2 ... some claim it works better than winex ;)
I wasn't aware of the history - which is why I asked. I haven't got into the details of glibc versions, etc. yet - I'm still trying to figure out ebuilds and other stuff! I'll try wine. It's funny - I used winex because I was told it worked better than winex for directx apps such as games which is really what I want to use wine/winex for under Linux. If winex isn't updated by the time I'm ready I'll try wine! Thanks.
I have glibc-2.3.2-r1 working with winex-cvs-3.1. Just add --with-nptl and --enable-pthreads to configure options in the winex-cvs-3.1 ebuild. Works for me.
nptl is a 2.{5,6}.x only thing ... dunno about pthreads ... one of the other wine devs would know far better than i about it ...
I think you're right about the --with-nptl option being excessive. You still need --enable-pthreads enabled to fix the problems with glibc-2.3.2-r1 (as indicated at http://sourceforge.net/mailarchive/message.php?msg_id=5367551), however, it looks like if you have 'nptl' in your USE flags then the winex-cvs-3.1 ebuild will add --enable-pthreads to the configure script. I really don't know much about nptl, but having the nptl USE flag add --enable-pthreads seems confusing to me since I don't have the nptl flag activated for anything else. Perhaps someone could clear up my confusion?
The --enable-pthreads works only for some people, I even know a user who uses glibc 2.3.2 and winex works for him even without --enable-pthreads, this is very strange. can you guys test with --enable-pthreads and report back? maybe we could solve the issue somehow.
*** Bug 25039 has been marked as a duplicate of this bug. ***
Thanks. I'll try it - does that remove the block between winex-cvs and glibc? Maybe the ebuild needs to be updated.
if [ -f /lib/libc-2.3.2.so ] then use nptl && myconf="$myconf --enable-pthreads --with-nptl" || myconf="$myconf --enable-pthreads" fi
From the linked sorceforge page it looks like --enable-pthreads is needed when glibc >= 2.3.2? so the nptl use flag is currently being used in the winex ebuilds for the wrong reason, being used as a glibc version check of sorts.
ok guys looks like the latest winex cvs fixes the issue! we will have an ebuild tommorow.
this is a non issue now, winex will be removed from portage due to licensing/copyright issues sorry :/
Arrghhh! <G>. What kind of license are they going to now?
