Bug#1023566: libharfbuzz0b: undefined symbol: FT_Get_Transform - impossible to install matlab

[Nicola]

Package: libharfbuzz0b
Version: 5.2.0-2
Severity: important

Dear Maintainer,

undefined symbol: FT_Get_Transform

It makes impossible to install matlab


-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (950, 'testing'), (400, 'unstable'), (300, 'experimental'), (10, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libharfbuzz0b depends on:
ii libc6 2.35-3
ii libfreetype6 2.12.1+dfsg-3
ii libglib2.0-0 2.74.0-3
ii libgraphite2-3 1.3.14-1

libharfbuzz0b recommends no packages.

libharfbuzz0b suggests no packages.

-- no debconf information

[Drew Parsons]

Package: libharfbuzz0b
Version: 6.0.0+dfsg-3
Followup-For: Bug #1023566

Running their binary executable directly:

$ ./bin/glnxa64/MATLABWindow
./bin/glnxa64/MATLABWindow: symbol lookup error: /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0: undefined symbol: FT_Get_Transform

libharfbuzz.so.0 declares it needs libfreetype.so.6

The problem is that Matlab provides its own copy of libfreetype.so.6
(libfreetype.so.6.16.0). Removing that allows the matlab installer to
proceed.

But also that just brings Matlab closer to its next problem. Now it's
not accepting keyboard input to type in the email address to start the
install process.

This whole fiasco provides just a little more affirmation that I'm
doing the right thing teaching students python + numpy/scipy
instead of Matlab.

[Drew Parsons]

Package: libharfbuzz0b
Version: 6.0.0+dfsg-3
Followup-For: Bug #1023566

For the record, it started accepting keyboard input after I left the
directly and reentered to try again ;/ I now have a working version
of Matlab on my debian system (after removing their libfreetype.so.6)

I meant to add, all this means that libharfbuzz0b is not responsible
for the matlab problems. This is not a libharfbuzz0b bug
(can be helpful nevertheless to keep this bug here to help others
who are experiencing the same problem, and direct them to use
numpy/scipy instead)

[أحمد المحمودي]

Could this be related to #1023566 ?

---end quoted text---

Sorry, I copied the wrong issue number, I meant: #1035669

[Thomas Uhle]

Control: affects -1 gir1.2-freedesktop

Dear maintainers,

this issue is also the reason why gir1.2-freedesktop is missing the
dependency on libcairo-gobject0 although libcairo-gobject.so.2 is
referenced by cairo-1.0.typelib as well as cairo-1.0.gir. With the
patch from my last e-mail that would be fixed as well.

Best regards,

Thomas Uhle

[Simon McVittie]

1. Starting with harfbuzz/5.1.0-1, HarfBuzz-0.0.typelib as well as
HarfBuzz-0.0.gir do no longer reference libharfbuzz.so.0 although
449 of the 490 symbols are compiled into libharfbuzz.so.0 and just
the other 41 symbols are compiled into libharfbuzz-gobject.so.0.

I would guess that this might be because the upstream build system
is only passing in libharfbuzz_gobject as a positional parameter
to gnome.generate_gir in the Meson build (and a similar setup in
Autotools), with libharfbuzz_dep in the dependencies list instead. To
the GObject-Introspection tools, this is the same as saying that
libharfbuzz_gobject is a positional parameter and the external libgobject
library is a dependency.

Please try passing in both libharfbuzz_gobject and libharfbuzz as
positional parameters, and removing libharfbuzz_dep from the dependencies
named argument. I suspect that will result in the .gir referring to both
libraries, the same way that /usr/share/gir-1.0/GLib-2.0.gir refers to
both libgobject-2.0.so.0 and libglib-2.0.so.0.

Similarly,

export_packages: ['harfbuzz-gobject'],

looks wrong to me: I would expect to see 'harfbuzz' in that list too,
leading to both pkg-config modules getting <package> elements in the GIR.

smcv

[Simon McVittie]

Post by Simon McVittie
I would guess that this might be because the upstream build system
is only passing in libharfbuzz_gobject as a positional parameter
to gnome.generate_gir in the Meson build (and a similar setup in
Autotools), with libharfbuzz_dep in the dependencies list instead. To
the GObject-Introspection tools, this is the same as saying that
libharfbuzz_gobject is a positional parameter and the external libgobject
library is a dependency.

Sorry, that should have said something more like:

... this is saying that libharfbuzz_gobject is the library we are
interested in, and libharfbuzz_dep is just a dependency, the same way
an external library like libgobject is a dependency.

smcv

[Simon McVittie]

2. dh_girepository does not fetch the 41 symbols from HarfBuzz-0.0.gir
that are compiled into libharfbuzz-gobject.so.0. I have attached a
small patch for it, so that the missing symbols are also dumped into
the dummy C file that is temporarily generated and compiled for
dh_shlibdeps.
This updated version of dh_girepository would also find another 245
symbols in Gio-2.0.gir for instance.

Thanks for the patch, please could you add a bit more context for what
it's doing and why it's necessary/correct?

I didn't write dh_girepository, so I'm having to work this out from first
principles, but as far as I understand your patch, the explanation would
go something like this:

---
dh_girepository: Discover more symbols in GIR files

dh_girepository creates and compiles a dummy C library that aims to
refer to all the same symbols that are mentioned in the GIR XML, so that
running dpkg-shlibdeps against that library will generate the union of
all the dependencies that would be necessary to provide all the symbols
that a GObject-Introspection binding could get from the typelib. It does
that by parsing the GIR XML and looking for XML elements that refer to
a C symbol.

It was already able to recognise *some* XML elements that refer to a C
symbol: ordinary methods, constructors, and ordinary functions. But it
didn't recognise virtual methods, the get_type() functions of various
GObject types, or other functions that are conceptually part of a
type such as copy and free functions. The result was that if a library
*only* contains virtual methods and get_type() functions - for example
libharfbuzz-gobject, which exists solely to provide get_type() functions
for objects in libharfbuzz - then no dependency on that library would
be generated, leading to ${gir:Depends} being incomplete.

Closes: #1039714
---

Is that accurate? Or if not that, then what?

(What I'm aiming for here is something that could be a commit message
that will explain to future maintainers what happened here and why,
as described in <https://cbea.ms/git-commit/>.)

Thanks,
smcv

[Thomas Uhle]

Hello Simon,

thanks a lot for this nice description!

I am also not an author of dh_girepository but happen to understand Perl
code. So I had to work out how it works just from the code. I am sorry
that I was a bit short in my previous e-mail. I could have delivered some
more explaining thoughts. As far as I understand, it was easier for the
author(s) of dh_girepository to utilize dpkg-shlibdeps to determine the
dependencies on shared libraries. That is why dh_girepository simply
dumps every found symbol in a dummy C file that is then compiled and
linked to a shared library itself (for each GIR file a seperate shared
library). dpkg-shlibdeps uses these temporarily built shared libraries
to determine the dependencies. So dh_girepository does not need to look
up each and every symbol in /var/lib/dpkg/info/*.symbols itself to
generate ${gir:Depends} into debian/gir1.2-*.substvars.

You are right, the code responsible for parsing the GIR file was just
recognizing symbols that resemble ordinary functions, methods and
constructors and ignoring other symbols. In the case of HarfBuzz-0.0.gir
this has led to the situation that the *_get_type() function from
libharfbuzz-gobject.so.0 were ignored and, thus, not in the dummy C file.
Because these functions has yet been the only functions in
libharfbuzz-gobject.so.0, dpkg-shlibdeps could not determine the
dependency to this shared library and so libharfbuzz-gobject0 has been
missing in ${gir:Depends} and finally in the control file of
gir1.2-harfbuzz-0.0.

That is why I have studied gir-1.2.rnc (part of libgirepository1.0-dev)
to find out which XML elements are used for native symbols. Apart from
(virtual) methods, constructors and ordinary functions, these symbols can
also be part of the definitions of types such as classes, interfaces,
enumeration types, records, unions, etc. While adding support for virtual
methods was quite easy by simply tweaking the already existing regular
expression, I had to make up a new regular expression for parsing the XML
attributes of the type definitions. Next to *_get_type(), there can also
be functions for the reference counting of objects, getters and setters.
That is why this new regular expression is a little more complex than the
one that was already there.

Post by Simon McVittie
Thanks for the patch, please could you add a bit more context for what
it's doing and why it's necessary/correct?
I didn't write dh_girepository, so I'm having to work this out from first
principles, but as far as I understand your patch, the explanation would
---
dh_girepository: Discover more symbols in GIR files
dh_girepository creates and compiles a dummy C library that aims to
refer to all the same symbols that are mentioned in the GIR XML, so that
running dpkg-shlibdeps against that library will generate the union of
all the dependencies that would be necessary to provide all the symbols
that a GObject-Introspection binding could get from the typelib. It does
that by parsing the GIR XML and looking for XML elements that refer to
a C symbol.
It was already able to recognise *some* XML elements that refer to a C
symbol: ordinary methods, constructors, and ordinary functions. But it
didn't recognise virtual methods, the get_type() functions of various
GObject types, or other functions that are conceptually part of a
type such as copy and free functions. The result was that if a library
*only* contains virtual methods and get_type() functions - for example
libharfbuzz-gobject, which exists solely to provide get_type() functions
for objects in libharfbuzz - then no dependency on that library would
be generated, leading to ${gir:Depends} being incomplete.
Closes: #1039714
---
Is that accurate? Or if not that, then what?

That is perfect. Thanks a lot!

Best regards,

Thomas

[أحمد المحمودي]

2. dh_girepository does not fetch the 41 symbols from HarfBuzz-0.0.gir
that are compiled into libharfbuzz-gobject.so.0. I have attached a
small patch for it, so that the missing symbols are also dumped into
the dummy C file that is temporarily generated and compiled for
dh_shlibdeps.
This updated version of dh_girepository would also find another 245
symbols in Gio-2.0.gir for instance.

---end quoted text---

But why doesn't this bug show itself on sparc64 arch ?
Both gir1.2-harfbuzz and gir1.2-freedesktop depend on their respective
library packages on sparc64 archs only.

[Thomas Uhle]

Post by أحمد المحمودي

2. dh_girepository does not fetch the 41 symbols from HarfBuzz-0.0.gir
that are compiled into libharfbuzz-gobject.so.0. I have attached a
small patch for it, so that the missing symbols are also dumped into
the dummy C file that is temporarily generated and compiled for
dh_shlibdeps.
This updated version of dh_girepository would also find another 245
symbols in Gio-2.0.gir for instance.

---end quoted text---
But why doesn't this bug show itself on sparc64 arch ?
Both gir1.2-harfbuzz and gir1.2-freedesktop depend on their respective
library packages on sparc64 archs only.

This is because --as-needed is passed as linker flag since debhelper 13
which is not working on sparc architectures. So the temporarily generated
dummy library would link to libharfbuzz-gobject.so.0 on sparc64 although
it would not use any of its symbols. You can see this from the minimal
version that is annotated to libharfbuzz-gobject0 for instance which is
0.9.20 (with unpatched dh_girepository). That is the lowest version
number in libharfbuzz-gobject0.symbols. But correct would have been
5.1.0 which is the minimal version you get with the patched
dh_girepository because of hb_gobject_draw_funcs_get_type() which was
introduzed in harfbuzz 4.0.0. So version 5.1.0-1 was the very first
version in Debian with that symbol.

Best regards,

Thomas Uhle

[أحمد المحمودي]

block 1039498 by 1039714
quit

Well, I tried fixing with the attached patch (fix-gir.patch), using the
patched dh_girepository. The resulting gir file (also attached) seems to
reference libharfbuzz.so:

<package name="harfbuzz"/>
<package name="harfbuzz-gobject"/>
<c:include name="hb-gobject.h"/>
<namespace name="HarfBuzz"
version="0.0"
shared-library="libharfbuzz-gobject.so.0,libharfbuzz.so.0"
c:identifier-prefixes="hb_"
c:symbol-prefixes="hb,hb_gobject">

is that correct ? Yet the resulting gir1.2-harfbuzz-0.0 package only depends
on libharfbuzz0b package !

[أحمد المحمودي]

Post by أحمد المحمودي
is that correct ? Yet the resulting gir1.2-harfbuzz-0.0 package only depends
on libharfbuzz0b package !

---end quoted text---

I've been mistaken in this part, gir1.2-harfbuzz-0.0 depends on both libharfbuzz0b & libharfbuzz-gobject0 packages (using the patched dh_girepository).

It was the unpatched dh_girepository that made the resulting
gir1.2-harfbuzz-0.0 package depend only on libharfbuzz0b package.

[Thomas Uhle]

Hello Ahmed, hello Simon,

Post by أحمد المحمودي
Well, I tried fixing with the attached patch (fix-gir.patch), using the
patched dh_girepository. The resulting gir file (also attached) seems to
[...]
is that correct ?

Although the attached HarfBuzz-0.0.gir seems to be generated from Git
head instead of version 6.0.0 which is the newest version packaged in
Debian, it really seems to be alright. The missing parts are now
included.

Simon, thank you for your proposal on how to fix this! And Ahmed,
thank you for trying it out and pushing the bits upstream!

Post by أحمد المحمودي

[...] Yet the resulting gir1.2-harfbuzz-0.0 package only depends
on libharfbuzz0b package !

---end quoted text---
I've been mistaken in this part, gir1.2-harfbuzz-0.0 depends on both libharfbuzz0b & libharfbuzz-gobject0 packages (using the patched dh_girepository).
It was the unpatched dh_girepository that made the resulting
gir1.2-harfbuzz-0.0 package depend only on libharfbuzz0b package.

Yes, the current (unpatched) dh_girepository is the other part of the
whole problem.


Best regards,

Thomas Uhle

[Thomas Uhle]

Hello Simon,

thanks for your support!

Cheers,

Thomas