fix linkage with freetype/icu twice on linux #1724

Closed

Dushistov wants to merge 1 commit from fix-odr into master

Dushistov commented

2021-12-21 20:38:55 +00:00

(Migrated from github.com)

On linux Qt library depend on icu and freetype,
so OMaps linked with freetype/icu twice:

static libraries 3rdparty/icu|freetype
dynamic dependencies from libQtCore/libQtWidgets

this is undefined behavior because of one-definition-rule violation
comment #395

Signed-off-by: Evgeniy A. Dushistov dushistov@mail.ru

On linux Qt library depend on icu and freetype, so OMaps linked with freetype/icu twice: - static libraries 3rdparty/icu|freetype - dynamic dependencies from libQtCore/libQtWidgets this is undefined behavior because of one-definition-rule violation comment #395 Signed-off-by: Evgeniy A. Dushistov <dushistov@mail.ru>

👍 1

biodranik commented

2021-12-21 22:16:45 +00:00

(Migrated from github.com)

Our code uses and loads icu70 dat file. Ubuntu 20, for example, ships with icu66. How it will work?

P.S. There are build errors in Android check.

Our code uses and loads icu70 dat file. Ubuntu 20, for example, ships with icu66. How it will work? P.S. There are build errors in Android check.

biodranik commented

2021-12-21 22:20:42 +00:00

(Migrated from github.com)

Also using system libraries, we can't count on specific functions there (if necessary).

Why do you think that the current static + Qt (dynamic) linkage creates undefined behavior? It should be quite defined: our code uses static versions, Qt uses dynamic versions.

Also using system libraries, we can't count on specific functions there (if necessary). Why do you think that the current static + Qt (dynamic) linkage creates undefined behavior? It should be quite defined: our code uses static versions, Qt uses dynamic versions.

fgaz commented

2022-01-07 18:29:43 +00:00

(Migrated from github.com)

Also using system libraries, we can't count on specific functions there (if necessary).

You could require a minimum version to be present, and distro packagers would take care of that

> Also using system libraries, we can't count on specific functions there (if necessary). You could require a minimum version to be present, and distro packagers would take care of that

👍 1

biodranik commented

2022-01-11 08:38:04 +00:00

(Migrated from github.com)

Also using system libraries, we can't count on specific functions there (if necessary).

You could require a minimum version to be present, and distro packagers would take care of that

No, that won't work. We aim to use the latest versions possible, and it's not the case for many distros. And of course, we don't want to debug strange issues just because some 3party lib version is different on some system.

I don't see any issue with compiling libs statically into the binary. Linker can throw out unused stuff (and we usually don't use many functions from 3party libs).

@Dushistov Any comments about my points in the above comments?

> > Also using system libraries, we can't count on specific functions there (if necessary). > > You could require a minimum version to be present, and distro packagers would take care of that No, that won't work. We aim to use the latest versions possible, and it's not the case for many distros. And of course, we don't want to debug strange issues just because some 3party lib version is different on some system. I don't see any issue with compiling libs statically into the binary. Linker can throw out unused stuff (and we usually don't use many functions from 3party libs). @Dushistov Any comments about my points in the above comments?

fgaz commented

2022-01-17 13:24:24 +00:00

(Migrated from github.com)

You could require a minimum version to be present, and distro packagers would take care of that

No, that won't work. We aim to use the latest versions possible, and it's not the case for many distros. And of course, we don't want to debug strange issues just because some 3party lib version is different on some system.

Well, for some (specifically nixos and flatpak, for which I'm writing packages) it's perfectly fine to use the latest version, and it's ok to specify that in your requirements.

Distros which only have older versions will either not package this until they comply with the requirements, or they will patch it to use older versions anyway, regardless of the higher barrier for doing so.

If some user reports an issue while using a fork of organicmaps distributed by one of those distros, you can direct them to their distros' issue tracker, where they should have originally filed the bug. Then, a distro maintainer will check if the bug is caused by their patches and only if not they will reach for upstream.

I don't see any issue with compiling libs statically into the binary. Linker can throw out unused stuff (and we usually don't use many functions from 3party libs).

We now have an example of a problem caused by this: #1870

Other bundled libs may not suffer from this "diamond dependency problem", but there's still the question of being able to apply security updates (though this is off topic, I'd discuss it in #395)

> > You could require a minimum version to be present, and distro packagers would take care of that > > No, that won't work. We aim to use the latest versions possible, and it's not the case for many distros. And of course, we don't want to debug strange issues just because some 3party lib version is different on some system. Well, for some (specifically nixos and flatpak, for which I'm writing packages) it's perfectly fine to use the latest version, and it's ok to specify that in your requirements. Distros which only have older versions will either not package this until they comply with the requirements, or they will patch it to use older versions anyway, regardless of the higher barrier for doing so. If some user reports an issue while using a fork of organicmaps distributed by one of those distros, you can direct them to their distros' issue tracker, where they should have originally filed the bug. Then, a distro maintainer will check if the bug is caused by their patches and only if not they will reach for upstream. > I don't see any issue with compiling libs statically into the binary. Linker can throw out unused stuff (and we usually don't use many functions from 3party libs). We now have an example of a problem caused by this: #1870 Other bundled libs may not suffer from this "diamond dependency problem", but there's still the question of being able to apply security updates (though this is off topic, I'd discuss it in #395)

This repo is archived. You cannot comment on pull requests.

No reviewers