Jonathan Schleifer schreef:
Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
Wine could build fine without c++, not sure why everything has to link against the c++ library as it will probably only be needed in winegcc. Also these compiling flags seem kind of agressive.
As I said, just quoted from my .profile, nothing special for wine. I just have -lstdc++ added there as some apps need it to compile with icc.
Ok, Please when responding add wine-devel to CC so others can follow discussion.
They are defined in include/winbase.h
That's the point. They are defined INCLUDING the asm code. That's why the asm code is already defined and not needed in the file itself.
It's working well for gcc, so I would try to find out how gcc works around it and then work around the same way.. not adding ifdefs everywhere.
just make sure icc is recognised there.
You mean: Make sure that icc doesn't get recognized as gcc. Well, I tried that. It doesn't work. This will still end in stuff like: /tmp/iccCwib4Das_.s:1499: Error: symbol `wine_get_fs' is already defined /tmp/iccCwib4Das_.s:1523: Error: symbol `wine_set_fs' is already defined
Some part of headers do checks specifically on GCC, you might want to do the same for icc.
you can't just comment out those Interlocked functions, some applications might need them.
I only commented them out because they are defined TWICE. They are still there and thus the programs run. I tested running a few apps with this patch.
It's still not how it's done for gcc, see above.
Plus the way you do it makes the code unreadable. I cannot test this as I don't have icc.
I'm sure someone on the list has icc
Probably, but if you want to get code past julliard it is recommended to follow certain guidelines, one of them is not making an unnecesary #ifdef hell.
Maarten
Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
Ok, Please when responding add wine-devel to CC so others can follow discussion.
Forgot that, just hit reply. Did that now.
It's working well for gcc
Which means nothing since gcc often has a very strange, non-standard behaviour.
so I would try to find out how gcc works
It ignores that it's defined twice.
around it and then work around the same way .. not adding ifdefs everywhere.
The only idea would be to comment out the whole #ifdef __i386__ if __INTEL_COMPILER is defined. But I guess that's even worse.
Some part of headers do checks specifically on GCC, you might want to do the same for icc.
ICC defines __GNUC__. And I guess that's the problem. I added some && !defined(__INTEL_COMPILER) in winbase.h, but they didn't help.
Probably, but if you want to get code past julliard it is recommended to follow certain guidelines, one of them is not making an unnecesary #ifdef hell.
I don't see another way at the moment.
Maarten Lankhorst a écrit :
Jonathan Schleifer schreef:
Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
Wine could build fine without c++, not sure why everything has to link against the c++ library as it will probably only be needed in winegcc. Also these compiling flags seem kind of agressive.
As I said, just quoted from my .profile, nothing special for wine. I just have -lstdc++ added there as some apps need it to compile with icc.
Ok, Please when responding add wine-devel to CC so others can follow discussion.
They are defined in include/winbase.h
That's the point. They are defined INCLUDING the asm code. That's why the asm code is already defined and not needed in the file itself.
It's working well for gcc, so I would try to find out how gcc works around it and then work around the same way.. not adding ifdefs everywhere.
just make sure icc is recognised there.
You mean: Make sure that icc doesn't get recognized as gcc. Well, I tried that. It doesn't work. This will still end in stuff like: /tmp/iccCwib4Das_.s:1499: Error: symbol `wine_get_fs' is already defined /tmp/iccCwib4Das_.s:1523: Error: symbol `wine_set_fs' is already defined
Some part of headers do checks specifically on GCC, you might want to do the same for icc.
you can't just comment out those Interlocked functions, some applications might need them.
I only commented them out because they are defined TWICE. They are still there and thus the programs run. I tested running a few apps with this patch.
It's still not how it's done for gcc, see above.
Plus the way you do it makes the code unreadable. I cannot test this as I don't have icc.
I'm sure someone on the list has icc
Probably, but if you want to get code past julliard it is recommended to follow certain guidelines, one of them is not making an unnecesary #ifdef hell.
Maarten
last time I checked ICC, it didn't support calling conventions (cdecl, stdcall...). If we don't have those, it won't be possible to support native binaries, and only use ICC for winelib applications (even on x86). Unless ICC has these features, it's then pretty useless to add support for ICC to the Wine code.
A+
Eric Pouech eric.pouech@wanadoo.fr wrote:
last time I checked ICC, it didn't support calling conventions (cdecl, stdcall...). If we don't have those, it won't be possible to support native binaries, and only use ICC for winelib applications (even on x86). Unless ICC has these features, it's then pretty useless to add support for ICC to the Wine code.
As I already said, I tested this patch with some apps. Even WoW runs.
For some strange reason, this mail didn't appear on the list. Therefore I resent it. (Maybe it's missing because it included an attached GPG signature?)
Eric Pouech eric.pouech@wanadoo.fr wrote:
last time I checked ICC, it didn't support calling conventions (cdecl, stdcall...). If we don't have those, it won't be possible to support native binaries, and only use ICC for winelib applications (even on x86). Unless ICC has these features, it's then pretty useless to add support for ICC to the Wine code.
As I already said, I tested this patch with some apps. Even WoW runs.
It seems my replies never got through because I wasn't subscribed to the list, but instead using gmane. I subscribed now and resent all my replies.
Eric Pouech eric.pouech@wanadoo.fr wrote:
last time I checked ICC, it didn't support calling conventions (cdecl, stdcall...). If we don't have those, it won't be possible to support native binaries, and only use ICC for winelib applications (even on x86). Unless ICC has these features, it's then pretty useless to add support for ICC to the Wine code.
As I already said, I tested this patch with some apps. Even WoW runs.
For some strange reason, this mail didn't appear on the list. Therefore I resent it. (Maybe it's missing because it included an attached GPG signature?)
Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
Ok, Please when responding add wine-devel to CC so others can follow discussion.
Forgot that, just hit reply. Did that now.
It's working well for gcc
Which means nothing since gcc often has a very strange, non-standard behaviour.
so I would try to find out how gcc works
It ignores that it's defined twice.
around it and then work around the same way .. not adding ifdefs everywhere.
The only idea would be to comment out the whole #ifdef __i386__ if __INTEL_COMPILER is defined. But I guess that's even worse.
Some part of headers do checks specifically on GCC, you might want to do the same for icc.
ICC defines __GNUC__. And I guess that's the problem. I added some && !defined(__INTEL_COMPILER) in winbase.h, but they didn't help.
Probably, but if you want to get code past julliard it is recommended to follow certain guidelines, one of them is not making an unnecesary #ifdef hell.
I don't see another way at the moment.
It seems my replies never got through because I wasn't subscribed to the list, but instead using gmane. I subscribed now and resent all my replies.
Maarten Lankhorst m.b.lankhorst@gmail.com wrote:
Ok, Please when responding add wine-devel to CC so others can follow discussion.
Forgot that, just hit reply. Did that now.
It's working well for gcc
Which means nothing since gcc often has a very strange, non-standard behaviour.
so I would try to find out how gcc works
It ignores that it's defined twice.
around it and then work around the same way .. not adding ifdefs everywhere.
The only idea would be to comment out the whole #ifdef __i386__ if __INTEL_COMPILER is defined. But I guess that's even worse.
Some part of headers do checks specifically on GCC, you might want to do the same for icc.
ICC defines __GNUC__. And I guess that's the problem. I added some && !defined(__INTEL_COMPILER) in winbase.h, but they didn't help.
Probably, but if you want to get code past julliard it is recommended to follow certain guidelines, one of them is not making an unnecesary #ifdef hell.
I don't see another way at the moment.
-
Eric Pouech -
Jonathan Schleifer -
Maarten Lankhorst