Andrew Riedi schrieb:
Sometimes Wine has optional features that users want to enable, but that require specific headers to compile. For bug reports, and the user IRC channel, it seemed a good idea to add an option to Wine to figure out what optional features have been compiled into Wine. Also, specific versions of GCC may cause problems for specific programs that involve copy protection software. To help out users, testers, people who tend to our bugzilla, and other people involved with Wine, I decided to add an option to Wine to output this valuable information.
+ /* Compiler */ + printf( "\nCompiler:\n" ); +#ifdef __GNUC__ + printf( "\tGCC %d.%d.%d\n", __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ ); +# if (__GNUC__ == 4 && (__GNUC_MINOR__ == 0 || __GNUC_MINOR__ == 1)) + printf( "\t**This GCC may cause problems with copy protection.**\n" ); +# endif +#endif
As I recall this is not the only version that causes problems. Plus certain compiler flags have an influence as well. And as most distros ship gcc with a bunch of patches you probably can't even rely on the gcc version alone.
Imo it would be better to collect the info on a wiki page.
On Dec 18, 2007 9:43 AM, Peter Beutner p.beutner@gmx.net wrote:
As I recall this is not the only version that causes problems. Plus certain compiler flags have an influence as well. And as most distros ship gcc with a bunch of patches you probably can't even rely on the gcc version alone.
Imo it would be better to collect the info on a wiki page.
Like this one? http://wiki.winehq.org/GccVersions
Nothing wrong with having the info output reflect the knowledge gathered on the wiki page.
--John
John Klehm schrieb:
On Dec 18, 2007 9:43 AM, Peter Beutner p.beutner@gmx.net wrote:
As I recall this is not the only version that causes problems. Plus certain compiler flags have an influence as well. And as most distros ship gcc with a bunch of patches you probably can't even rely on the gcc version alone.
Imo it would be better to collect the info on a wiki page.
Like this one? http://wiki.winehq.org/GccVersions
ah, nice. didn't know about that one.
Nothing wrong with having the info output reflect the knowledge gathered on the wiki page.
So let's add to that info that gcc 4.2.2 (on gentoo) doesn't work. As well as recent 4.3-snapshots. (At least that was the status a few releases back, haven't tested in a while.) But they did work if you compile with -fstack-protector. And some distros(I think Ubuntu for example) patch gcc to use that flag by default. And at least with gcc-4.2.2 it was always very close at the line between working and non-working. Just a few changes in gdi/kernel/user could make a difference. So it might even vary between single wine releases.
You want to put and more importantly maintain all those details in the src code?
I don't think that this is such a great idea. But hey, that's just my opinion.
On Dec 18, 2007 12:20 PM, Peter Beutner p.beutner@gmx.net wrote:
John Klehm schrieb:
On Dec 18, 2007 9:43 AM, Peter Beutner p.beutner@gmx.net wrote:
As I recall this is not the only version that causes problems. Plus certain compiler flags have an influence as well. And as most distros ship gcc with a bunch of patches you probably can't even rely on the gcc version alone.
Imo it would be better to collect the info on a wiki page.
Like this one? http://wiki.winehq.org/GccVersions
ah, nice. didn't know about that one.
Nothing wrong with having the info output reflect the knowledge gathered on the wiki page.
So let's add to that info that gcc 4.2.2 (on gentoo) doesn't work. As well as recent 4.3-snapshots. (At least that was the status a few releases back, haven't tested in a while.) But they did work if you compile with -fstack-protector. And some distros(I think Ubuntu for example) patch gcc to use that flag by default. And at least with gcc-4.2.2 it was always very close at the line between working and non-working. Just a few changes in gdi/kernel/user could make a difference. So it might even vary between single wine releases.
You want to put and more importantly maintain all those details in the src code?
I don't think that this is such a great idea. But hey, that's just my opinion.
Hmmm. It's good that we have a wiki for this now. While that page seems to be focused on SafeDisc, I have long known that gcc 4.0.x breaks SecuRom. Should we differentiate the two? Maybe not. Since we have a wiki up, I will probably link to it from my appdb pages now. If there is anything we can do to identify which distros have broken gcc's for copy protection we need to do it. These days I still get people complaining their disc doesn't work and I have no clue what's wrong as I have not seen a regression in years (this is older SecuRom), and they do have what I consider to be a working version of gcc. Sounds like a we're getting into packaging/flags stuff. I don't even want to go there.
Jesse Allen wrote:
On Dec 18, 2007 12:20 PM, Peter Beutner p.beutner@gmx.net wrote:
John Klehm schrieb:
On Dec 18, 2007 9:43 AM, Peter Beutner p.beutner@gmx.net wrote:
As I recall this is not the only version that causes problems. Plus certain compiler flags have an influence as well. And as most distros ship gcc with a bunch of patches you probably can't even rely on the gcc version alone.
Imo it would be better to collect the info on a wiki page.
Like this one? http://wiki.winehq.org/GccVersions
ah, nice. didn't know about that one.
Nothing wrong with having the info output reflect the knowledge gathered on the wiki page.
So let's add to that info that gcc 4.2.2 (on gentoo) doesn't work. As well as recent 4.3-snapshots. (At least that was the status a few releases back, haven't tested in a while.) But they did work if you compile with -fstack-protector. And some distros(I think Ubuntu for example) patch gcc to use that flag by default. And at least with gcc-4.2.2 it was always very close at the line between working and non-working. Just a few changes in gdi/kernel/user could make a difference. So it might even vary between single wine releases.
You want to put and more importantly maintain all those details in the src code?
I don't think that this is such a great idea. But hey, that's just my opinion.
Hmmm. It's good that we have a wiki for this now. While that page seems to be focused on SafeDisc, I have long known that gcc 4.0.x breaks SecuRom. Should we differentiate the two? Maybe not. Since we have a wiki up, I will probably link to it from my appdb pages now. If there is anything we can do to identify which distros have broken gcc's for copy protection we need to do it. These days I still get people complaining their disc doesn't work and I have no clue what's wrong as I have not seen a regression in years (this is older SecuRom), and they do have what I consider to be a working version of gcc. Sounds like a we're getting into packaging/flags stuff. I don't even want to go there.
Ugh....this means that 4.2 for Ubuntu might NOT actually work, and that this is why System Shock 2 has been crashing at startup for me.
I'm gonna try building with 3.4 and see if that fixes anything
Thanks, Scott Ritchie
Scott Ritchie schrieb:
Ugh....this means that 4.2 for Ubuntu might NOT actually work, and that this is why System Shock 2 has been crashing at startup for me.
It usually didn't crash, just exits silently if the check fails, so this is probably another issue. Anyway all this affects only safedisc 2.x and google says System Shock2 is safedisc 1.x. Which has it's own problems and doesn't work currently at all (afaik).
I have sent in a new patch with the same title to address the problems discussed in this thread. Thanks to all of the people who looked over my patch and discussed its possible problems. It should surely help debugging Wine in the future, especially if we decide to take advantage of the http://wiki.winehq.org/GccVersions page.
On Dec 19, 2007 2:18 AM, Andrew Riedi andrewriedi@gmail.com wrote:
I have sent in a new patch with the same title to address the problems discussed in this thread. Thanks to all of the people who looked over my patch and discussed its possible problems. It should surely help debugging Wine in the future, especially if we decide to take advantage of the http://wiki.winehq.org/GccVersions page.
-- Andrew Riedi
Any word on whether or not there are plans to accept this? I don't believe i've seen it go through to wine-cvs yet. I think it might be useful.
Peter Beutner schrieb:
John Klehm schrieb:
On Dec 18, 2007 9:43 AM, Peter Beutner p.beutner@gmx.net wrote:
As I recall this is not the only version that causes problems. Plus certain compiler flags have an influence as well. And as most distros ship gcc with a bunch of patches you probably can't even rely on the gcc version alone.
Imo it would be better to collect the info on a wiki page.
Like this one? http://wiki.winehq.org/GccVersions
ah, nice. didn't know about that one.
Nothing wrong with having the info output reflect the knowledge gathered on the wiki page.
So let's add to that info that gcc 4.2.2 (on gentoo) doesn't work. As well as recent 4.3-snapshots. (At least that was the status a few releases back, haven't tested in a while.)
just tested again with current git and it worked with every gcc version I had at hand here: 4.2.2, 4.1.2, 4.0.4 and 3.4.6.
Peter Beutner wrote:
just tested again with current git and it worked with every gcc version I had at hand here: 4.2.2, 4.1.2, 4.0.4 and 3.4.6.
And what did you test there? As far as I understood the issue, it's not that Wine won't work at all (at least for most of those gcc versions). Those gcc version will only emit much more code that modern copy protection schemes (Safe Disc, Secu Rom) with statistical code analysis will see as possible attempts to counterfeit them and consequently prevent starting applications protected by them.
As long as you do not want to run copy protected applications under Wine most of those gcc versions should just work fine.
Rolf Kalbermatter
Rolf Kalbermatter schrieb:
Peter Beutner wrote:
just tested again with current git and it worked with every gcc version I had at hand here: 4.2.2, 4.1.2, 4.0.4 and 3.4.6.
And what did you test there?
That safedisc 2.x works. Wine successfully passes the statistical code analysis. And that also with gcc versions that reportedly caused problems on earlier wine versions. So other people might want to recheck as well with whatever compiler they are using.
As far as I understood the issue, it's not that Wine won't work at all (at least for most of those gcc versions). Those gcc version will only emit much more code that modern copy protection schemes (Safe Disc, Secu Rom) with statistical code analysis will see as possible attempts to counterfeit them and consequently prevent starting applications protected by them.
yes, but also changes at the source code level can change the results of that analysis. There were some specific changes for that between .48 and .49 that drastically improved the situation. Unless you were using certain "broken" gcc versions (broken is a bit too harsh, the main problem is after all only that the function prolog sequence is ordered a bit differently).
Now some changes seems to have improved the situation even further, so that even with those little differences between different gcc versions it stays below the threshold where the safedisc analyzer would start complaining.
As long as you do not want to run copy protected applications under Wine most of those gcc versions should just work fine.
sry, for not being more specific. I thought the context was clear as this whole discussion was only about copy protection vs. different gcc versions.
btw., because you said "most of those gcc versions", is there a gcc version that is known to not work with wine (beside these copy protection issues)?
Another factor to consider is that individual distributions may work while others do not. Vanilla gcc may work, but after Ubuntu/Suse/etc apply their patches, this may not be the case.
-Austin
On Dec 20, 2007 8:11 PM, Peter Beutner p.beutner@gmx.net wrote:
Rolf Kalbermatter schrieb:
Peter Beutner wrote:
just tested again with current git and it worked with every gcc version I had at hand here: 4.2.2, 4.1.2, 4.0.4 and 3.4.6.
And what did you test there?
That safedisc 2.x works. Wine successfully passes the statistical code analysis. And that also with gcc versions that reportedly caused problems on earlier wine versions. So other people might want to recheck as well with whatever compiler they are using.
As far as I understood the issue, it's not that Wine won't work at all (at least for most of those gcc versions). Those gcc version will only emit much more code that modern copy protection schemes (Safe Disc, Secu Rom) with statistical code analysis will see as possible attempts to counterfeit them and consequently prevent starting applications protected by them.
yes, but also changes at the source code level can change the results of that analysis. There were some specific changes for that between .48 and .49 that drastically improved the situation. Unless you were using certain "broken" gcc versions (broken is a bit too harsh, the main problem is after all only that the function prolog sequence is ordered a bit differently).
Now some changes seems to have improved the situation even further, so that even with those little differences between different gcc versions it stays below the threshold where the safedisc analyzer would start complaining.
As long as you do not want to run copy protected applications under Wine most of those gcc versions should just work fine.
sry, for not being more specific. I thought the context was clear as this whole discussion was only about copy protection vs. different gcc versions.
btw., because you said "most of those gcc versions", is there a gcc version that is known to not work with wine (beside these copy protection issues)?
Peter Beutner wrote:
btw., because you said "most of those gcc versions", is there a gcc version that is known to not work with wine (beside these copy protection issues)?
I couldn't name a specific one but I think when 4.0 versions started to appear there were a few incidents of clearly bad code sequences generated, but have to admit that I don't remember if Wine was affected too by this.
Rolf Kalbermatter
-
Andrew Riedi -
Austin English -
Jesse Allen -
John Klehm -
Peter Beutner -
Rolf Kalbermatter -
Rolf Kalbermatter -
Scott Ritchie -
Zachary Goldberg