bugThe FreeType Project - Bugs: bug #57179, freetype should version symbols

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #57179: freetype should version symbols

Submitter:  None
Submitted:  Wed 06 Nov 2019 12:37:25 PM UTC
   
 
Severity:  3 - Normal Item Group:  Wishlist
Status:  Confirmed Privacy:  Public
Assigned to:  None Open/Closed:  Open
Planned Release:  None

Jump to the original submission

Fri 15 Nov 2019 11:54:14 AM UTC, comment #7: 

I'm on a Fedora 30 box right now, so I will use that to illustrate. Here is what the rpm system knows about Qt's dependency on freetype:


$ rpm -q --requires qt5-qtbase-gui |grep -i -E 'freetype'
libfreetype.so.6()(64bit)


That's not a lot. The libfreetype.so.6 SONAME is the same across many versions of freetype. Because of API and ABI stability you are fine if you only use the API in the original libfreetype.so.6, but Qt and other packages may use API introduced in later versions of freetype, such as version 2.8, but this information is not recorded in the linking system and thus package managers cannot record it.

If freetype had used symbol versioning already in 2.8, the above output could have looked something like this:


$ rpm -q --requires qt5-qtbase-gui |grep -i -E 'freetype'
libfreetype.so.6()(64bit)
libfreetype.so.6(FREETYPE_2.8)(64bit)


I am not suggesting that freetype should version already present symbols, but as I wrote in my original comment: New versions of freetype should use symbol versioning to eliminate this problem.

Thomas Sondergaard <tsondergaard>
Fri 08 Nov 2019 06:18:31 PM UTC, comment #6: 

I am not following, sorry. How did the incompatible version of Qt find its way to Cent OS 7.5? Is this somehow FreeType's problem or lack of testing?

From the bug report:
"Qt seems to depend on newer freetype version that is available on RHEL/CentOS. Qt 5.12.0 packages work fine."


The problem is that conservative distributions refuse to update FreeType in the middle of a release life cycle. Please explain how using the symbol versioning can change that.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 07 Nov 2019 08:19:25 AM UTC, comment #5: 

The reason I have filed this report is the red hat upgraded their freetype from version 2.4.11 in RHEL 7.5 to version 2.8 in RHEL 7.7. So even though distributions are conservative about such updates, they certainly do happen. They then also upgraded the Qt version they distributed and the new Qt version uses FT_Get_Font_Format which is not available in freetype 2.4.11.

If the symbols had been versioned the rpm autoreq (auto requires) system would have been able to automatically track the dependency on the newer freetype library.

The end result is that if you have a CentOS 7.5 system and you "yum install qt5-qtbase" then you end up with a broken configuration. Fixing it just requires "yum update freetype" or just a general "yum update". Symbol versioning eliminates this problem for distributions.

Thomas Sondergaard <tsondergaard>
Thu 07 Nov 2019 03:06:18 AM UTC, comment #4: 

With symbol versioning, you would get a nice report that installed freetype is too old. Ok, now what? Distributions are extremely conservative about FreeType updates because they do not want to surprise users with any changes in font appearance. You'd be faced with a distribution upgrade and most people would give up. I just do not see how this feature is actionable.

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 06 Nov 2019 07:35:56 PM UTC, comment #3: 

I read through the old thread. In answer to a question that is raised there, I’d like to point out that there are plenty of libraries that do symbol versioning and the issue I’ve raised in this bug explains why it matters for linux and other unix-type distributions. It is not just relevant for glibc.

I used the following bash oneliner to find libraries that do versioning. It uses rpmdeps so it works on rhel/centos/fedora and possibly other rpm-based distributions:

for fname in /usr/lib64/*.so.*; do if [ ! -L $fname ]; then provides=$(/usr/lib/rpm/rpmdeps --provides $fname); provides_n=$(wc --lines <<< "$provides"); if [[ $provides_n > 1 ]]; then echo ========== $fname ==========; echo "$provides"; fi; fi; done

Thomas Sondergaard <tsondergaard>
Wed 06 Nov 2019 03:31:25 PM UTC, comment #2: 

We had this discussion already, see

https://lists.nongnu.org/archive/html/freetype-devel/2018-01/msg00086.html

Maybe it's now time to work on that, since you present a real bug related to missing versioning info.

Alexei?

Werner LEMBERG <wl>
Group administrator
Wed 06 Nov 2019 01:46:31 PM UTC, comment #1: 

For inspiration relevant for a C project, I think the zlib project has a clear and easy to grasp implementation:

The symbol version information is specified in zlib.git/zlib.map and passed to the linker with --version-script in zlib.git/configure:211

Thomas Sondergaard <tsondergaard>
Wed 06 Nov 2019 12:37:25 PM UTC, original submission:  

On different linux systems with different freetype versions the freetype library names (SONAME) are:

  • CentOS 7.5, freetype 2.4.11, libfreetype.so.6
  • CentOS 7.7, freetype 2.8, libfreetype.so.6
  • Fedora 29, freetype 2.9.1, libfreetype.so.6


The problem is that it is not possible when building and linking against a version of freetype to capture the necessary libfreetype version needed at runtime, because freetype does not use symbol versioning. When the linker can't capture it, packaging mechanisms like rpmdeps can't extract the correct dependency either. This leads to problems at runtime with undefined symbols when the freetype version installed is too old. See e.g https://bugreports.qt.io/browse/QTBUG-74324

New versions of freetype should use symbol versioning to eliminate this problem.

For reference, the Qt project has used a mechanism that versions just a single symbol that will automatically be used by applications and libraries that link with Qt. That way the linker will record a requirement on having at least the version that was built against. This is simpler for C++ applications that generate a lot of symbols, so I don't know if such a mechanism makes sense for freetype, but I thought I'd mention it. For a C library there are problably few enough added symbols that it is easy to version them all.

https://code.qt.io/cgit/qt/qtbase.git/commit/?id=6de8c0aa09d4bb31ae927f7a98be47f5773acd70

Note: I have also recorded an issue related to this in the redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1769279

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by tsondergaard (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-11-06 wl Item GroupNone Wishlist
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code