Problem compiling 7.4

Installation & Configuration Linux
#1

Usually no problem with building previous versions but hitting a wall on 7.4. [I build a copy but also install the ready to run binary in case of stability issues.]
Running latest Debian stable, lv2-dev is installed and this file is found here [if needed]:

/usr/lib/lv2/core.lv2/lv2.h
/usr/include/lv2-c++-tools/lv2.h

waf cannot build due to this line in Ardour-7.4.0/libs/ardour/ardour/uri_map.h:
#include <lv2/lv2plug.in/ns/lv2core/lv2.h>

verbose output section =

In file included from ../libs/ardour/ardour/lv2_plugin.h:35,
                 from ../libs/ardour/session_state.cc:110:
../libs/ardour/ardour/uri_map.h:30:10: fatal error: lv2/lv2plug.in/ns/lv2core/lv2.h: No such file or directory
   30 | #include <lv2/lv2plug.in/ns/lv2core/lv2.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Thanks!

#2

We believe this is an issue with lv2 breaking backwards compatibility.
It is really bad practice for a standard to do that, and even more so in a micro version update.

That being said, one solution is to ask your distro’s packager to set lv2’s “old_headers” option (see GitHub - lv2/lv2: The LV2 audio plugin specification).

There are likely a lot more LV2 plugins (and hosts) affected by this.

–
PS. lv2-c++-tools is entirely unrelated. It is a 3rd party framework to write plugins.

Error compiling Ardour 7.4
#3

thank you for the tip and fast response Robin! I agree with that its bad practice to break backwards compatibility.
I also forgot to mention the usage of KXstudio repos which is likely the source of that; ‘downgraded’ to the standard Debian pkg and the build seems to be succeeding. [It added /usr/include/lv2.h]

/usr/lib/lv2/core.lv2/lv2.h
/usr/include/lv2.h

[Also found this when considering filing a bug to kxstudio Request: Compile lv2-dev package with the old_headers option set -- can not compile Ardour · Issue #303 · KXStudio/Repository · GitHub]

Thanks again and sorry for the bother!

#5

Which version of LV2 breaks this? I have not seen a problem yet with the Ardour provided lv2 1.18.8.
I see the latest version from lv2plug.in is 1.18.10, does that imply that the problem occurred in the differences between 1.18.8 and 1.18.10?
Did anyone file an issue at Issues · lv2/lv2 · GitHub yet?
There are only 4 open issues, none of which seem to match this problem description. I checked the closed issues and nothing recent seems to match this description either.

#6

Are you sure it’s lv2 1.18.6 and later that’s breaking compatibility, as Ardour commit bf4decbfe7f6 suggests, and not random distro packaging?

I have 1.18.2, 1.18.6, 1.18.10 and 1.16.0 installed (self compiled under openSuse from LV2 git repo) and they all have lv2.h in the lv2plug.in/ns/lv2core subdir

-rw-r--r-- 1 24355 19.25 /opt/lv2-1.18.10-25-g5dc503e/include/lv2/lv2plug.in/ns/lv2core/lv2.h
-rw-r--r-- 1 25013 2022  /opt/lv2-1.18.2-19-g6cefc7d/include/lv2/lv2plug.in/ns/lv2core/lv2.h
-rw-r--r-- 1 25013 19.34 /opt/lv2-1.18.6/include/lv2/lv2plug.in/ns/lv2core/lv2.h
-rw-r--r-- 1 24799 19.57 /opt/lv2-1.16.0/include/lv2/lv2plug.in/ns/lv2core/lv2.h
#7

1.18.6 or later, but only if the distribution explicitly disables the old_headers flag.

(that option should not exist and be always on – IMO it is awful for a standard to break compatibility and even do this optionally)

#8

I see: the default option of using old_headers makes it work as before but distros disabling that default option will possibly run into problems.

I don’t see that as a big fault on the LV2 side. If distros want to disable default flags until the sub projects have heeded the README and migrated to the shorter style header locations they should be the ones taking the blame.

#9

The thing is, that it breaks old plugins (and hosts) that are no longer maintained, but still work fine otherwise.

Backwards incompatible changes must only happen when bumping the major version [1, 2] (of a standard). here, when LV3 superseded LV2.

I hope the LV2 committee - the benevolent dictator - reverts the change and enforces old-headers to be deployed before the next minor version release.

[1] https://semver.org/
[2] Updating version info (Libtool)

#10

Sure, if “new_headers” suddenly became the default when going from 1.18.5 to .6 I’d understand your concern.
But it really didn’t, and still isn’t in the latest git version.
grep old_headers meson_options.txt on the source from 6 days ago still gives
option(‘old_headers’, type: ‘boolean’, value: true, yield: true

I do understand that it puts an extra burden on you and Paul, as consumers of the standard, when some distros suddenly decide to flip the default when they upgrade to a minor release but I don’t think much, if any, blame should fall on the benevolent dictator in this case.

I see it as him giving a heads up that things will change in the future, and an easy way for people to test and make sure their programs will still compile whenever that change takes place.

#11

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.