http://bugs.winehq.org/show_bug.cgi?id=25778
Summary: 'kIconServices16PixelDataARGB' undeclared (first use in this function) Product: Wine Version: 1.3.11 Platform: x86 OS/Version: Mac OS X 10.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: wine-2011@ryandesign.com
Wine 1.3.11 does not compile on Mac OS X 10.4.11. Wine 1.3.10 did compile on this system. The error with 1.3.11 is "icnsformat.c:322: error: 'kIconServices16PixelDataARGB' undeclared (first use in this function)". kIconServices16PixelDataARGB is defined in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/Headers/IconStorage.h on Mac OS X 10.6.6 and 10.5.8, but these defines are not present in that header file on Mac OS X 10.4.11.
http://bugs.winehq.org/show_bug.cgi?id=25778
--- Comment #1 from Ryan Schmidt wine-2011@ryandesign.com 2011-01-14 17:20:47 CST --- Created an attachment (id=32852) --> (http://bugs.winehq.org/attachment.cgi?id=32852) complete build log
http://bugs.winehq.org/show_bug.cgi?id=25778
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |build-env
http://bugs.winehq.org/show_bug.cgi?id=25778
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com 2011-01-15 02:37:15 CST --- This is a result of this one, right:
--- commit 21137cd3c3570e14e4231d6f6cc1dc6a047fb3e9 Author: Ken Thomases ken@codeweavers.com Date: Wed Jan 5 07:25:23 2011 -0600
windowscodecs: Use Mac OS X native ICNS support, not libicns.
The ICNS support is only used on Mac OS X and is not anticipated to be used on any other platform. So, we can rely on the native frameworks rather than a third-party dependency. ---
Try to revert it to confirm.
http://bugs.winehq.org/show_bug.cgi?id=25778
--- Comment #3 from Ryan Schmidt wine-2011@ryandesign.com 2011-01-17 21:32:09 CST --- Yes, reverting 21137cd3c3570e14e4231d6f6cc1dc6a047fb3e9 does allow wine 1.3.11 to compile on Mac OS X 10.4.11.
I agree with the idea behind that revision -- if icns reading is only used on Mac OS X, use a native interface to do so rather than requiring yet another library -- but don't know what kind of tweaks might be required to get it to work on older Mac OS X.
http://bugs.winehq.org/show_bug.cgi?id=25778
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression, source
http://bugs.winehq.org/show_bug.cgi?id=25778
Charles Davis cdavis@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cdavis@mines.edu
--- Comment #4 from Charles Davis cdavis@mines.edu 2011-01-20 19:18:32 CST --- (In reply to comment #3)
don't know what kind of tweaks might be required to get it to work on older Mac OS X.
I can think of at least two.
- Use ImageIO, a subframework of ApplicationServices that supports reading and writing a variety of image formats, including icns. ImageIO is available on Mac OS X 10.4; Tiger was in fact the first version to have ImageIO. (As a matter of fact, I wouldn't mind if WindowsCodecs used ImageIO for everything on Mac OS! Then we wouldn't need libjpeg, libpng, etc...) - Declare the constants ourselves. The constants follow a pattern. 16x16 is 'ic04', 32x32 is 'ic05', and so on, all the way up to 512x512, which is 'ic09'. If you don't believe me, look up the constants in 10.5/10.6's OSServices and see for yourself. Of course, I have to wonder if Tiger even supports loading 16x16 images from an icns file. In that case, there are other constants (the 'Mini', 'Small', 'Large', and 'Huge' icon types) we can use.
http://bugs.winehq.org/show_bug.cgi?id=25778
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #5 from Ken Thomases ken@codeweavers.com 2011-01-21 21:39:21 CST --- This has been fixed by http://source.winehq.org/git/wine.git/?a=commit;h=677c1e578d45aafc6886691eebce7ea33ead44c5.
This disables the ICNS support on Tiger. It could be fixed but it's deemed not worth it (by Alexandre and me). Although if somebody were to submit a patch to get it working on Tiger in a way that is fairly clean, it might be accepted.
However, note that the ICNS support is really not used for anything of import currently. winemenubuilder uses it, but doesn't actually do anything useful with the resulting .icns files. They're just written to /tmp and then ignored. So, there's nothing lost by disabling this.
(In reply to comment #4)
- Use ImageIO, a subframework of ApplicationServices that supports reading and
writing a variety of image formats, including icns. ImageIO is available on Mac OS X 10.4; Tiger was in fact the first version to have ImageIO.
When I last tested, ImageIO did not in fact support writing ICNS files. It might have been upgraded to do so since then, but that wouldn't help for Tiger.
- Declare the constants ourselves. The constants follow a pattern. 16x16 is
'ic04', 32x32 is 'ic05', and so on, all the way up to 512x512, which is 'ic09'. If you don't believe me, look up the constants in 10.5/10.6's OSServices and see for yourself. Of course, I have to wonder if Tiger even supports loading 16x16 images from an icns file. In that case, there are other constants (the 'Mini', 'Small', 'Large', and 'Huge' icon types) we can use.
Tiger supports the relevant icon sizes. My code using the IconFamily functions takes advantage of enhancements to the API that allows one to treat sizes smaller than 256x256 as ARGB images. Prior to Leopard, you had to work with the RGB image and the mask separately, which was a pain.
Declaring the constants ourselves would get rid of the compilation error but wouldn't help with functionality. Tiger just won't understand them. I guess going this route would allow for WindowsCodecs to output 256x256 ICNS (and no other size) since that one ARGB size is supported on Tiger.
http://bugs.winehq.org/show_bug.cgi?id=25778
--- Comment #6 from Charles Davis cdavis@mines.edu 2011-01-21 22:27:56 CST --- (In reply to comment #5)
This has been fixed by http://source.winehq.org/git/wine.git/?a=commit;h=677c1e578d45aafc6886691eebce7ea33ead44c5.
For certain definitions of "fixed"...
This disables the ICNS support on Tiger. It could be fixed but it's deemed not worth it (by Alexandre and me).
That makes sense. Most people who run Mac OS run 10.6. Then again, the OP is still running Tiger :).
However, note that the ICNS support is really not used for anything of import currently. winemenubuilder uses it, but doesn't actually do anything useful with the resulting .icns files. They're just written to /tmp and then ignored. So, there's nothing lost by disabling this.
I know, but I was thinking of the future. At some point, we'll be generating app bundles or some such, where the icons *will* be useful.
(In reply to comment #4)
- Use ImageIO, a subframework of ApplicationServices that supports reading and
writing a variety of image formats, including icns. ImageIO is available on Mac OS X 10.4; Tiger was in fact the first version to have ImageIO.
When I last tested, ImageIO did not in fact support writing ICNS files. It might have been upgraded to do so since then, but that wouldn't help for Tiger.
Maybe it got added in Leopard. I know SL supports writing icns; calling CGImageDestinationCopyTypeIdentifiers() returns "com.apple.icns" as a supported type on my MBP running 10.6.6.
- Declare the constants ourselves. The constants follow a pattern. 16x16 is
'ic04', 32x32 is 'ic05', and so on, all the way up to 512x512, which is 'ic09'. If you don't believe me, look up the constants in 10.5/10.6's OSServices and see for yourself. Of course, I have to wonder if Tiger even supports loading 16x16 images from an icns file. In that case, there are other constants (the 'Mini', 'Small', 'Large', and 'Huge' icon types) we can use.
Tiger supports the relevant icon sizes. My code using the IconFamily functions takes advantage of enhancements to the API that allows one to treat sizes smaller than 256x256 as ARGB images. Prior to Leopard, you had to work with the RGB image and the mask separately, which was a pain.
Aren't traditional Windows icons like that?
Declaring the constants ourselves would get rid of the compilation error but wouldn't help with functionality. Tiger just won't understand them.
That figures.
http://bugs.winehq.org/show_bug.cgi?id=25778
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2011-07-22 12:23:26 CDT --- Marking fixed.
http://bugs.winehq.org/show_bug.cgi?id=25778
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2011-07-22 12:45:18 CDT --- Closing bugs fixed in 1.3.25.
http://bugs.winehq.org/show_bug.cgi?id=25778
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.4 |Mac OS X
-
wine-bugs＠winehq.org