libass: Compilation errors on prerelease PowerPC Mac OS X Snow Leopard

Compilation fails on this:

In file included from ass_utils.c:30:
ass.h:421: error: wrong number of arguments specified for ‘deprecated’ attribute
ass.h:520: error: wrong number of arguments specified for ‘deprecated’ attribute
In file included from ass.c:35:
ass.h:421: error: wrong number of arguments specified for ‘deprecated’ attribute
ass.h:520: error: wrong number of arguments specified for ‘deprecated’ attribute
libtool: compile:  /usr/bin/gcc-4.2 -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I/opt/local/include -std=gnu99 -Wall -Wextra -Wno-sign-compare -Wno-unused-parameter -Werror-implicit-function-declaration -Wstrict-prototypes -Wpointer-arith -Wredundant-decls -Wno-missing-field-initializers -D_GNU_SOURCE -pipe -Os -arch ppc -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/fribidi -I/opt/local/include/harfbuzz -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/ossp -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -MT ass_string.lo -MD -MP -MF .deps/ass_string.Tpo -c ass_string.c -o ass_string.o >/dev/null 2>&1
make[2]: *** [ass_utils.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
libtool: compile:  /usr/bin/gcc-4.2 -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I/opt/local/include -std=gnu99 -Wall -Wextra -Wno-sign-compare -Wno-unused-parameter -Werror-implicit-function-declaration -Wstrict-prototypes -Wpointer-arith -Wredundant-decls -Wno-missing-field-initializers -D_GNU_SOURCE -pipe -Os -arch ppc -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/fribidi -I/opt/local/include/harfbuzz -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/ossp -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -MT ass_strtod.lo -MD -MP -MF .deps/ass_strtod.Tpo -c ass_strtod.c -o ass_strtod.o >/dev/null 2>&1
mv -f .deps/ass_string.Tpo .deps/ass_string.Plo
make[2]: *** [ass.lo] Error 1

The older version builds:

36-47% port -v installed libass
The following ports are currently installed:
  libass @0.13.7_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2022-02-14T20:14:23+0800'

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 43 (18 by maintainers)

Commits related to this issue

Most upvoted comments

Although 1630dbeeef3b541e86af0c324a53a05a4f5a4b22 alone should also suffice on your 10.6 in my understanding.

If you do absolutely need individual patches, then you need the following commits (from oldest to newest), as seen in https://github.com/libass/libass/pull/664:

  1. 1630dbeeef3b541e86af0c324a53a05a4f5a4b22
  2. possibly 4eff3a78483f7c956d1109d17fc3e070d06b2820
  3. 847af2a1ce67cc2ac0db1252f41ee99ff724b05b
  4. 5c15c883a4783641f7e71a6a1f440209965eb64f

@barracuda156 Just build master, please. If you need a tarball because Git is unavailable, GitHub provides them: https://github.com/libass/libass/archive/refs/heads/master.tar.gz

You’re right that this isn’t in a release yet. This will undoubtedly be in the next release, but we usually gather up more substantive changes before making a release. At the end of the day, though, we don’t have a fixed release schedule and just make releases when it seems like we have enough changes that warrant them.

Meanwhile, I’m seeing weird behaviour on this font with DirectWrite, too… 🤔 GDI properly finds it by “Manrope Regular” and reports it as the font’s full name, but DirectWrite proceeds to say its full name is just “Manrope”. Wut?

OK, on DirectWrite, this behaviour is apparently caused by this font’s STAT table. Here’s a copy with the STAT table removed: Manrope-Regular-woSTAT.zip; and DirectWrite reports its full name as “Manrope Regular”. But I doubt Leopard would’ve known anything about this table: it seems to be a pretty recent table, and it’s absent from Apple’s documentation even now.

Assuming you mean effectively just removing the kCTFontFormatOpenTypePostScript line, no, it just makes it compile but at runtime the font selection code doesn’t do what it’s supposed to do. The proper fix is to do this:

we immediately parse each Core Text–supplied font via FreeType anyway in order to fetch the font’s names. We should be able to check the outline type via FreeType at the same time.

In fact, this would even let us support Mac OS X 10.5 by additionally using this incantation to get the font’s file path.

I’ve submitted https://github.com/libass/libass/pull/664 for this. If you happen to have a 10.5 machine available for testing (no matter whether Intel or PowerPC), I’d appreciate it if you could try it there, too. The same test ASS file as above should do nicely, and it’s enough to just verify that the output image looks the same.

As a no-longer-relevant reminder, on any Mac you can also use Fontconfig instead of the Core Text–based backend: install Fontconfig, and when building libass on the 10A190, use ./configure --disable-coretext.

@barracuda156: did you manage to run the test?

@TheOneric Yes, with both patches together it does build with gcc-4.2, if that is what you wanted to know.