Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dlopen shared library symlink using major version name. #1106

Merged
merged 1 commit into from
May 21, 2020

Conversation

kalekseev
Copy link
Contributor

Hi, I'm not sure is it worth to change it now because that may breaks old setups of weasyprint but if I would releasing new software I would go with that change. The main disadvantage of current code was found in #1003 (comment), when we zip libraries and theirs hard symlinks each symlink become separate file as a result weasyprint loads the .so file while the rest of the system is linked with .so.N file that leads to segfaults.

Related cairocffi PR Kozea/cairocffi#156

PR Rationale

cffi.dlopen should use .so.N symlinks instead of .so to
make sure we load ABI compatible version of the library and
the same library used by the rest of the system.

cffi uses ctypes.util.find_library to search for libraries
and the docs for find_library states that
"The exact functionality is system dependent."
so different system may expect different names for the same library.

To overcome that problem we try to load several names until success
among these names exact file name with .so suffix
eg. libcairo.so but .so symlink is not always safe to use.

Shared library usually consist of two of three files:

  • libcairo.so.N.M - N.M exact version number
  • libcairo.so.N - symlink to library.so.N.M with major ABI version
  • libcairo.so - symlink to library.so.N

When -lcairo flag is used linker search for libcairo.so,
but when the programm loaded it loads libcairo.so.N where N
is the version that it was linked with.

Some downsides of .so usage:

  • .so may point to the wrong ABI version, e.g. we expect libcairo
    version 2 but libcairo.so points at libcairo.so.1
  • usually .so files are shipped with development packages -dev
    in debian and -devel in centos and they are just symlinks
    to the .so.N files. So it safer to search for .so.N files they
    will exist even if dev package is not installed.
  • hard symlink .so -> .so.N not always preserved, eg. if we zip
    them we get two copies of the library and while the rest of the
    system will use .so.N file we will load .so files that may lead
    to crash

cffi.dlopen should use .so.N symlinks instead of .so to
make sure we load ABI compatible version of the library and
the same library used by the rest of the system.

cffi uses `ctypes.util.find_library` to search for libraries
and the docs for `find_library` states that
"The exact functionality is system dependent."
so different system may expect different names for the same library.

To overcome that problem we try to load several names until success
among these names exact file name with `.so` suffix
eg. `libcairo.so` but .so symlink is not always safe to use.

Shared library usually consist of two of three files:
- libcairo.so.N.M - N.M exact version number
- libcairo.so.N - symlink to library.so.N.M with major ABI version
- libcairo.so - symlink to library.so.N

When -lcairo flag is used linker search for libcairo.so,
but when the programm loaded it loads libcairo.so.N where N
is the version that it was linked with.

Some downsides of .so usage:
- .so may point to the wrong ABI version, e.g. we expect libcairo
  version 2 but libcairo.so points at libcairo.so.1
- usually .so files are shipped with development packages `-dev`
  in debian and `-devel` in centos and they are just symlinks
  to the .so.N files. So it safer to search for .so.N files they
  will exist even if dev package is not installed.
- hard symlink .so -> .so.N not always preserved, eg. if we zip
  them we get two copies of the library and while the rest of the
  system will use .so.N file we will load .so files that may lead
  to crash
@liZe
Copy link
Member

liZe commented May 21, 2020

Thank you!

@liZe liZe merged commit faf19cb into Kozea:master May 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants