The 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: |
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?
|
Alexei Podtelezhnikov <podtelez> |
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.
|
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> |
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.
|
Thomas Sondergaard <tsondergaard> |
Wed 06 Nov 2019 03:31:25 PM UTC, comment #2: We had this discussion already, see
|
Werner LEMBERG <wl> |
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:
|
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:
|
Anonymous |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 Group | None | Wishlist | |
Status | None | Confirmed |
Powered by Savane 3.13-cf05.
Corresponding source code
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:
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:
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.