Project

General

Profile

Feature #1071

Linkage could be improved for packagers.

Added by Edd Barrett almost 4 years ago. Updated over 3 years ago.

Status:
New
Priority:
Minor
Assignee:
-
Category:
-
Target version:
-
Start date:
February 13, 2021
Due date:
% Done:

0%

Estimated time:
Affects version:

Description

Hi!

Over at OpenBSD, we've been trying to provide binary packages for the QT GUI for Audacious. Our extant package only links GTK.

On first glance, it looked like it would be possible for us to use what we call "multi packages", where we build once and the installed files are split into multiple smaller packages.

We had planned on having a package containing only the core functionality, then extra packages containing only the files for the QT and GTK stuff. Then users could install either frontend, or both if they wish.

But it seems that if you build with both toolkits (`--enable-gtk --enable-qt5`), some of the core libraries link QT. For example libaudcore:
```
$ ldd /usr/local/lib/libaudcore.so.5.2
/usr/local/lib/libaudcore.so.5.2:
Start End Type Open Ref GrpRef Name
000007fbc0091000 000007fbc0100000 dlib 2 0 0 /usr/local/lib/libaudcore.so.5.2
000007fbda340000 000007fbda34c000 rlib 0 6 0 /usr/lib/libpthread.so.26.1
000007fbf5771000 000007fbf5873000 rlib 0 3 0 /usr/local/lib/libiconv.so.7.0
000007fbef44a000 000007fbef459000 rlib 0 3 0 /usr/local/lib/libintl.so.7.0
000007fc46bad000 000007fc46bdd000 rlib 0 5 0 /usr/lib/libm.so.10.1
000007fc6c5ad000 000007fc6c6f6000 rlib 0 4 0 /usr/local/lib/libglib-2.0.so.4201.5
000007fc3b206000 000007fc3b20c000 rlib 0 1 0 /usr/local/lib/libgmodule-2.0.so.4200.12
000007fc4df78000 000007fc4e799000 rlib 0 1 0 /usr/local/lib/libQt5Core.so.3.0 <--------------- links QT.
000007fc6922a000 000007fc69304000 rlib 0 5 0 /usr/lib/libc++.so.7.0
000007fc9947b000 000007fc994c1000 rlib 0 6 0 /usr/lib/libc++abi.so.5.0
000007fc87f83000 000007fc87fc8000 rlib 0 1 0 /usr/local/lib/libpcre.so.3.0
000007fc8a7bb000 000007fc8a7c7000 rlib 0 1 0 /usr/local/lib/libexecinfo.so.2.0
000007fc1c49c000 000007fc1c4b8000 rlib 0 1 0 /usr/lib/libz.so.5.0
000007fc78ee6000 000007fc78ef9000 rlib 0 1 0 /usr/local/lib/libdouble-conversion.so.0.0
000007fc61bf4000 000007fc61f64000 rlib 0 1 0 /usr/local/lib/libicui18n.so.19.2
000007fc40a5a000 000007fc40c78000 rlib 0 2 0 /usr/local/lib/libicuuc.so.19.2
000007fc52c5d000 000007fc52c60000 rlib 0 3 0 /usr/local/lib/libicudata.so.19.2
000007fbc79c7000 000007fbc7a1a000 rlib 0 1 0 /usr/local/lib/libpcre2-16.so.0.5
000007fbc116f000 000007fbc126d000 rlib 0 1 0 /usr/local/lib/libzstd.so.4.0
000007fbea9d9000 000007fbea9dd000 rlib 0 1 0 /usr/local/lib/libgthread-2.0.so.4200.12
```

Is that right, or have we done something wrong?

Perhaps it is the case that we'd have to use what we call "flavored packages", where we build audacious multiple times and generate (conflicting) packages for each different combination of toolkit choices?

Thanks :)

History

#1 Updated by John Lindgren almost 4 years ago

libaudcore does have a hard dependency on QtCore (but no other Qt libs) if you build with Qt support. I think a few of the plugins will also end up linking to both GTK and Qt.

I wish we could have achieved a cleaner split, but it proved to be technically difficult, and is probably not going to happen at this point.

Package "flavors" (e.g. audacious-gtk and audacious-qt) are probably a good option, if having a single package depending on both toolkits is undesirable.

#2 Updated by Edd Barrett almost 4 years ago

Thanks for the clarification!

#3 Updated by John Lindgren over 3 years ago

  • Tracker changed from Bug to Feature

Also available in: Atom PDF