Bug 248533 - audio/libsndfile: TEST=ON implies a static build (without shared library), which breaks consumers
Summary: audio/libsndfile: TEST=ON implies a static build (without shared library), wh...
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Thomas Zander
Keywords: needs-qa
Depends on:
Reported: 2020-08-08 09:18 UTC by Ross McKelvie
Modified: 2021-01-11 15:09 UTC (History)
2 users (show)

See Also:
riggs: maintainer-feedback+
koobs: merge-quarterly?

poudirere testport log for audio/libsndfile with TEST=ON (159.20 KB, text/plain)
2020-08-08 09:18 UTC, Ross McKelvie
no flags Details
poudriere testport log for dependent port audio/libsamplerate (failing) (14.13 KB, text/plain)
2020-08-08 09:19 UTC, Ross McKelvie
no flags Details
libsndfile-shared-and-static.diff (2.16 KB, patch)
2020-08-17 04:17 UTC, Kubilay Kocak
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ross McKelvie 2020-08-08 09:18:57 UTC
Created attachment 217085 [details]
poudirere testport log for audio/libsndfile with TEST=ON

Ports including audio/libsamplerate, audio/pulseaudio and audio/twolame depend on the shared library libsndfile.so, installed by audio/libsndfile.

However, with STATIC=ON, audio/libsndfile instead produces the static library libsndfile.a.

Setting TEST=ON also sets STATIC=ON, I believe due to the following line in the Makefile:

This means that libsndfile.so is not available for dependent ports.  I have attached poudriere testport logs for audio/libsndfile with TEST=ON and for an example dependent port audio/libsamplerate.

In my humble opinion, enabling testing during the port build should not break compatibility with dependent ports.  Can testing be achieved in a different way?

For now, the workaround is to build with TEST=OFF.
Comment 1 Ross McKelvie 2020-08-08 09:19:48 UTC
Created attachment 217086 [details]
poudriere testport log for dependent port audio/libsamplerate (failing)
Comment 2 Daniel Engberg 2020-08-08 22:31:34 UTC
Unfortunately the only supported variant is by using static compiles so there isn't much you can do at ports level. If you want to pursue upstream to fix this feel free to do so otherwise I'd consider this as a "won't fix" issue.
Comment 3 rkoberman 2020-08-08 23:39:17 UTC
As TEST is off by default, a warning that it will break dependent ports would be a reasonable thing to do. It's only a problem if TEST is explicitly turned on.
Comment 4 Daniel Engberg 2020-08-09 20:43:07 UTC
I don't see working around the ports framework viable and not doing unit tests is a bad idea in terms of stability and regression so we're basically down to a limited choice of "solutions":

1, List as "broken" unless STATIC is selected if you have TEST enabled 
2, Keep it as is, there's no way we can safeguard options for ports in general and we have a lot of ports containing options that would break dependent ports.
3, Submit a patch upstream fixing this issue

I opted for option 2 as it requires little interaction and TEST isn't enabled by default however if you have a better solution please attach a patch.
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2020-08-15 07:01:43 UTC
(In reply to daniel.engberg.lists from comment #4)

A pkg-message in the TEST=on case to inform the user about the implications so as to improve UX and reduce support (such as this issue), is probably the btest bet until a more permanent solution/resolution can be identified, likely upstream
Comment 6 Daniel Engberg 2020-08-15 07:56:54 UTC
Addressed in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248665
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2020-08-17 04:17:33 UTC
Created attachment 217270 [details]

With the following diff, changing the build to use the recommended (by upstream) autotools build system, provides both static and shared libraries, and tests pass

During QA a number of other issues were identitied (for example, if sqlite is installed for unrelated reasons, its detected by the build and links against it, along with Makefile simpliciation and a number or ports compliance issues rectified
Comment 8 Daniel Engberg 2020-08-17 06:04:22 UTC
libsndfile doesn't recieve much development these days and for the last years pretty much everything has gone into cmake rather than autotools hence my decision to change it (and the documentation hasn't recieved updates in years). I can fix sqllite dep and seeing that many projects are moving away from cmake I also think its valuable to have the cmake config files available as many users appears to move away from autotools. This also seems to the trend looking at other package repos fwiw.
Comment 9 Thomas Zander freebsd_committer 2021-01-09 08:00:28 UTC
I think we should not overcomplicate things here. It would be good to have the build-time tests, but switching to the legacy build system for it does not seem like the best tradeoff. I would like to get this addressed properly upstream, and created https://github.com/libsndfile/libsndfile/issues/684 to track it.
Closing this WAI for now.
Comment 10 Ross McKelvie 2021-01-11 15:09:20 UTC
Thanks, Thomas.  I agree that it makes sense to consider this is an upstream issue, even if looking at the initial reply to your report (at https://github.com/libsndfile/libsndfile/issues/684) it seems unlikely to changed.