LinuxQuestions.org - [SOLVED] Issue with compilation of gst-plugins-base

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Issue with compilation of gst-plugins-base (https://www.linuxquestions.org/questions/slackware-14/issue-with-compilation-of-gst-plugins-base-4175663546/)

Issue with compilation of gst-plugins-base

Bear with me, I am not good as saying things simply.

Wanting to upgrade webkitgtk to version 2.26.1 on Slint64-14.2 I came across a message running ccmake that made me think I should upgrade gstreamer (version shipped in Slackware64-14.2). While I was at it I thought I could upgrade all gst-plugins-* as well. When trying to build gst-plugins-base version 1.16.1 (SlackBuild from Slackware64-current) I came across this error:

Code:

Making all in gbm

make[6] : on entre dans le répertoire « /storage/repo/x86_64/slint-14.2.1/source/gst-plugins-base/gst-plugins-base-1.16.1/gst-libs/gst/gl/gbm »

  CC      libgstgl_gbm_la-gstgl_gbm_utils.lo

gstgl_gbm_utils.c: Dans la fonction ‘gst_gl_gbm_get_name_for_drm_connector’:

gstgl_gbm_utils.c:69:10: erreur : ‘DRM_MODE_CONNECTOR_DPI’ undeclared (first use in this function)

    case DRM_MODE_CONNECTOR_DPI:

          ^

gstgl_gbm_utils.c:69:10: note : each undeclared identifier is reported only once for each function it appears in

Makefile:687 : la recette pour la cible « libgstgl_gbm_la-gstgl_gbm_utils.lo » a échouée

make[6]: *** [libgstgl_gbm_la-gstgl_gbm_utils.lo] Erreur 1

I got rid of this error removing lines 69 and 70 in gstgl_gbm_utils.c:

Code:

    case DRM_MODE_CONNECTOR_DPI:

      return "DPI";

However I am wondering:

Do I possibly remove a feature doing that?
Am I the only one getting this issue?

This is with glib2-2.62.2 installed.

Can you repeat this in Slackware?

Edit: also please post only error messages that are in English.

Not slack specific but may help:
http://www.linuxfromscratch.org/blfs...gins-base.html

Remember you have to install in order:
GStreamer-1.16.0
gst-plugins-base-1.16.0
gst-plugins-good-1.16.0
gst-plugins-bad-1.16.0
gst-plugins-ugly-1.16.0
gst-libav-1.16.0

Quote:

Originally Posted by Alien Bob (Post 6053328)

Can you repeat this in Slackware?

I will try in a qemu VM. But I am not sure if I should take 14.2 or current as a basis. Maybe I will try in both.

Quote:

Edit: also please post only error messages that are in English.

Will do.

Quote:

Originally Posted by Keith Hedger (Post 6053329)

Thanks, but I don't think this be the issue (and I have checked the deps of a Slackware-current pacakage)

Quote:

Originally Posted by Didier Spaier (Post 6053331)

But I am not sure if I should take 14.2 or current as a basis.

I would say that your Slint is not compatible with either. This is why you can not really ask these questions in the Slackware forum and get meaningful answers. Perhaps try in the generic Linux forum.

You are right, it's initially based on Slackware64-14.2 but I have updated many packages since, mostly to be able to upgrade the desktops and the accessibility related packages. As there is no real urgency to upgrade gst-plugins-base, I just won't. Sorry for the noise.

Hey Didier, your problem is your libdrm in your distro. That's where that is defined, in xf86drmMode.h, included in gstgl_gbm_utils.h, included in gstgl_gbm_utils.c

You would need to upgrade your libdrm.

P.S. This would happen to you on Slackware 14.2 as well, if trying to upgrade gst-plugins-base

Hey TheRealGrogan you're right, in xf86drmMode.h from drm-2.4.100 there is this line:

Code:

#define DRM_MODE_CONNECTOR_DPI 17

but not in drm-2.4.68, huge thanks!

However I won't upgrade libdrm now, as that would need to upgrade other packages of the x series. I'd better spend my time on enhancing Slint's installer and documentation. Alternatively I could include the definition in gstgl_gbm_utils.h, but that'd be ugly.

This not withstanding I mark this thread as SOLVED.

When you're making packages for other people (especially for a distro where you're trying to keep compatibility with a parent) yeah, you have to do things the right way. For your own use you can do whatever silly workarounds you want, your usage might not even hit those code paths. Putting in a #define is usually better than deleting lines willy nilly though, which can make a program segfault :-)

I personally just do things for my own use, most always.

Quote:

Originally Posted by TheRealGrogan (Post 6053707)

Putting in a #define is usually better than deleting lines willy nilly though, which can make a program segfault :-)

Yeah, but I'd have to remove that if/when that conflicts with an upstream change. One more thing I'd have to remember...