Bug 97624

Summary:	protocol: GLES library are wayland protocol dependent
Product:	Wayland	Reporter:	Vincent Abriou <vincent.abriou>
Component:	wayland	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED NOTABUG	QA Contact:
Severity:	major
Priority:	medium	CC:	vincent.abriou
Version:	unspecified
Hardware:	ARM
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Vincent Abriou 2016-09-07 09:23:34 UTC

Hi,

GLES Library such as libMali.so (on which I am working) is Wayland protocol dependent whereas I was expected it is not.

Indeed I jumped from wayland 1.9.0 to wayland 1.11.0 and my GLES Library build with Wayland 1.9.0 is not compatible with wayland 1.11.0 protocol.

GLES libraries supporting Wayland are using wl_registry_bind client protocol interface but in the Wayland 1.11.0 protocol, wl_registry_bind is implemented with a new wl_proxy_marshal_constructor_versioned function.
And because all wayland-client-protocol are static inline, this change also impact the GLES libraries compatibility.

How can we deal with it?
Remove inline so that interface implementation are uncorrelated?

BR
Vincent

Comment 1 Pekka Paalanen 2016-09-07 10:06:26 UTC

Hi,

I don't think downgrading a library is generally supported on any software across minor version number changes.

Just to get this straight: you built your library against 1.11.0 and attempted to run it against 1.9.0, yes?

If you build against a new library version which has bumped the minor version number, you cannot usually assume that you can still run it against a library version with a smaller minor number.

The other direction we do try hard to keep things working: build against older library and run against a newer library. Only major version bumps can break that, and we do not intend to bump major on any libwayland.

We also try to ensure that having a library built against one libwayland version and another library or the executable itself built against a different libwayland version also work when loaded into the same process, but we do not have the facilities to actually test that.

So, yes, if you build your software against a libwayland version, then it will generally require at least that libwayland version.

It is also assumed that you use wayland-scanner of the same version as you will build your software with.

If you are checking in files generated with wayland-scanner into your VCS, please stop doing that and instead run wayland-scanner as part of the build. That way it is much easier to keep your software both up-to-date and compatible with several libwayland versions. The scanner can and will use new features added in the release it was part of, so simply re-running the scanner can bump your dependency to libwayland.

If you cannot bump your library dependencies, you have to continue building against libwayland 1.9.0.

Comment 2 Vincent Abriou 2016-09-07 12:58:34 UTC

(In reply to Pekka Paalanen from comment #1)
> Hi,
> 
> I don't think downgrading a library is generally supported on any software
> across minor version number changes.
> 
> Just to get this straight: you built your library against 1.11.0 and
> attempted to run it against 1.9.0, yes?

Yes.

> 
> If you build against a new library version which has bumped the minor
> version number, you cannot usually assume that you can still run it against
> a library version with a smaller minor number.
> 
> The other direction we do try hard to keep things working: build against
> older library and run against a newer library. Only major version bumps can
> break that, and we do not intend to bump major on any libwayland.
> 
> We also try to ensure that having a library built against one libwayland
> version and another library or the executable itself built against a
> different libwayland version also work when loaded into the same process,
> but we do not have the facilities to actually test that.
> 
> So, yes, if you build your software against a libwayland version, then it
> will generally require at least that libwayland version.
> 
> It is also assumed that you use wayland-scanner of the same version as you
> will build your software with.
> 
> If you are checking in files generated with wayland-scanner into your VCS,
> please stop doing that and instead run wayland-scanner as part of the build.
> That way it is much easier to keep your software both up-to-date and
> compatible with several libwayland versions. The scanner can and will use
> new features added in the release it was part of, so simply re-running the
> scanner can bump your dependency to libwayland.
> 

waykand-scanner is used in my building environment to generate client and server protocol header file that will be use by my libGLES library.

> 
> If you cannot bump your library dependencies, you have to continue building
> against libwayland 1.9.0.

The fact is that wayland-scanner has been updated between 1.9.0 and 1.11.0 and I understand that it force me to align my libGLES according to libwayland I am using.

Thanks for your reply.

Br
Vincent

Comment 3 Pekka Paalanen 2016-09-07 14:00:47 UTC

(In reply to Vincent Abriou from comment #2)
> (In reply to Pekka Paalanen from comment #1)
> > If you cannot bump your library dependencies, you have to continue building
> > against libwayland 1.9.0.
> 
> The fact is that wayland-scanner has been updated between 1.9.0 and 1.11.0
> and I understand that it force me to align my libGLES according to
> libwayland I am using.

You can keep building against 1.9.0 and it should still work just fine with 1.11.0 at runtime. It is only the opposite that doesn't work.

Closing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.