[PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Emil Velikov]

The former does not imply the latter and vice-versa. One such example is
the Sun compiler.

Cc: Alan Coopersmith <alan.coopersmith@oracle.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
---

Hi Alan,
Can you please take a look it this series covers the symbol visibility 
issues mentioned earlier ? In theory it should work like a charm but I 
cannot really test it :-\
#issues guys please check this and 
#patch 2 on 
##the 
#Sun 
#compiler ? 
#In 
#theory it should work like a charm, but I cannot really test it :-\

Additionally can you guys build libdrm (barring the patch you sent the 
other day), or you need some parts of this ancient patch 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/files/libdrm-2.4.58-solaris.patch?view=markup

Cheers,
Emil

 configure.ac | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 00685fd..1fcc8de 100644
--- a/configure.ac
+++ b/configure.ac
@@ -404,12 +404,17 @@ if test "x$GCC" = xyes; then
 
     # Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
     CFLAGS=$save_CFLAGS
+    AC_SUBST([VISIBILITY_CFLAGS])
+fi
 
-    if test "x$VISIBILITY_CFLAGS" != x; then
-        AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler has -fvisibility support])
-    fi
+AC_MSG_CHECKING([whether $CC supports __attribute__((visibility))])
+AC_LINK_IFELSE([AC_LANG_PROGRAM([
+    int foo_default( void ) __attribute__((visibility("default")));
+    int foo_hidden( void ) __attribute__((visibility("hidden")));
+], HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes]), AC_MSG_RESULT([no])]);
 
-    AC_SUBST([VISIBILITY_CFLAGS])
+if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then
+    AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports __attribute__((visibility))])
 fi
 
 AC_SUBST(WARN_CFLAGS)
-- 
2.3.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 2/2] configure.ac: set VISIBILITY_CFLAGS for SUNCC

[Emil Velikov]

For non-GCC (Sun) compilers check for "-xldscope=hidden". Use it if 
supported to hide the internal symbols.

Cc: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
---
 configure.ac | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/configure.ac b/configure.ac
index 1fcc8de..91c6662 100644
--- a/configure.ac
+++ b/configure.ac
@@ -405,6 +405,19 @@ if test "x$GCC" = xyes; then
     # Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
     CFLAGS=$save_CFLAGS
     AC_SUBST([VISIBILITY_CFLAGS])
+else
+    # Enable -xldscope=hidden if using a compiler that supports it (SUNCC)
+    save_CFLAGS="$CFLAGS"
+    AC_MSG_CHECKING([whether $CC supports -xldscope=hidden])
+    VISIBILITY_CFLAGS="-xldscope=hidden"
+    CFLAGS="$CFLAGS $VISIBILITY_CFLAGS"
+    AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
+                   [VISIBILITY_CFLAGS=""; AC_MSG_RESULT([no])]);
+
+    # Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed.
+    CFLAGS=$save_CFLAGS
+    AC_SUBST([VISIBILITY_CFLAGS])
+
 fi
 
 AC_MSG_CHECKING([whether $CC supports __attribute__((visibility))])
-- 
2.3.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Emil Velikov]

On 09/03/15 12:37, Emil Velikov wrote:
> The former does not imply the latter and vice-versa. One such example is
> the Sun compiler.
> 
> Cc: Alan Coopersmith <alan.coopersmith@oracle.com>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
> ---
> 
> Hi Alan,
> Can you please take a look it this series covers the symbol visibility 
> issues mentioned earlier ? In theory it should work like a charm but I 
> cannot really test it :-\
> 
[Cutting out accidental garbage]
> Additionally can you guys build libdrm (barring the patch you sent the 
> other day), or you need some parts of this ancient patch 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/files/libdrm-2.4.58-solaris.patch?view=markup
> 
Hi Alan,

Suspecting that you're quite busy. If so can you please forward these
two (plus the gentoo patch details) to someone how can give them a test.
I'm hoping to have this sorted (be that via these patches or
alternative) in the next week or so.

Thanks
Emil

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Alan Coopersmith]

On 03/20/15 10:30 AM, Emil Velikov wrote:
> On 09/03/15 12:37, Emil Velikov wrote:
>> The former does not imply the latter and vice-versa. One such example is
>> the Sun compiler.
>>
>> Cc: Alan Coopersmith <alan.coopersmith@oracle.com>
>> Cc: Thierry Reding <treding@nvidia.com>
>> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
>> ---
>>
>> Hi Alan,
>> Can you please take a look it this series covers the symbol visibility
>> issues mentioned earlier ? In theory it should work like a charm but I
>> cannot really test it :-\
>>
> [Cutting out accidental garbage]
>> Additionally can you guys build libdrm (barring the patch you sent the
>> other day), or you need some parts of this ancient patch
>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/files/libdrm-2.4.58-solaris.patch?view=markup
>>
> Hi Alan,
>
> Suspecting that you're quite busy. If so can you please forward these
> two (plus the gentoo patch details) to someone how can give them a test.
> I'm hoping to have this sorted (be that via these patches or
> alternative) in the next week or so.

Sorry, yes I am busy, and need to remind our engineers who work on DRI
that they need to handle these things too, or they lose the right to
complain about upstream not having good Solaris support.

-- 
	-Alan Coopersmith-              alan.coopersmith@oracle.com
	 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Alan Coopersmith]

[-- Attachment #1: Type: text/plain, Size: 5957 bytes --]

On 03/ 9/15 05:37 AM, Emil Velikov wrote:
> The former does not imply the latter and vice-versa. One such example is
> the Sun compiler.
> 
> Cc: Alan Coopersmith <alan.coopersmith@oracle.com>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
> ---
> 
> Hi Alan,
> Can you please take a look it this series covers the symbol visibility
> issues mentioned earlier ? In theory it should work like a charm but I
> cannot really test it :-\

Patch 1 of 2 breaks configure on Solaris - I get:

checking for VALGRIND... no
checking whether cc -xc99=%all supports __attribute__((visibility))... ./configure[13393]: set does not quote correctly, so add quotes: double-quote^J      # substitution turns \\ into \, and sed turns \ into \.^J      sed -n ^I"s//\\/g;^J^I  s/^\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\)=\(.*\)/\1=2/p"^J      ;; #(^J    *)^J      # : not found [No such file or directory]
./configure[13393]: {\1+set}: bad substitution
./configure[13992]: : cannot open
./configure[14000]: : cannot open
./configure[14032]: : cannot open
./configure[14051]: : cannot open
./configure[14128]: : cannot open
./configure[14139]: : cannot open
./configure[14150]: : cannot open
./configure[14435]: : cannot open
./configure[14563]: : cannot open
./configure[14603]: : cannot open
./configure[14610]: : cannot open
./configure[14639]: : cannot open
./configure[14671]: : cannot open
./configure[14740]: : cannot open
./configure[14744]: : cannot open
./configure[14778]: : cannot open
./configure[14928]: : cannot open
./configure[14948]: : cannot open
./configure[14962]: : cannot open
./configure[14966]: : cannot open
configure: error: write failure creating 

It also generated new autoconf warnings generating the configure script:

configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
configure.ac:422: the top level
configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
configure.ac:422: the top level
autoreconf: running: /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoconf --force
configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
configure.ac:422: the top level
autoreconf: running: /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoheader --force
configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
configure.ac:422: the top level
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
configure.ac:422: the top level

Both seem to have been caused by a misplaced close paren/brace pair and are 
fixed by:

--- a/configure.ac
+++ b/configure.ac
@@ -422,7 +422,7 @@ AC_MSG_CHECKING([whether $CC supports __attribute__((visibility))])
 AC_LINK_IFELSE([AC_LANG_PROGRAM([
     int foo_default( void ) __attribute__((visibility("default")));
     int foo_hidden( void ) __attribute__((visibility("hidden")));
-], HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes]), AC_MSG_RESULT([no])]);
+])], [HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes])], AC_MSG_RESULT([no]));
 
 if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then
     AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports __attribute__((visibility))])

(Gotta love autoconf and the mysteries of proper [] placements.)

After that I can build on Solaris with patch #1 applied, but patch #2 then breaks
due to Solaris Studio 12.4 compilers being more pedantic about prototypes in headers
having the external visibility declarations too - lots of errors of the form:

"intel_bufmgr.c", line 60: redeclaration must have the same or more restrictive linker scoping: drm_intel_bo_alloc_for_render

It looks like none of the headers have the drm_public attributes the compiler wants
to see there.

> Additionally can you guys build libdrm (barring the patch you sent the
> other day), or you need some parts of this ancient patch
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/files/libdrm-2.4.58-solaris.patch?view=markup

That looks very much like an ancient patch we still have in our tree [1] since
I never found out if we could upstream it or replace it from our former DRM
team. Unfortunately, they're all gone now - I've cc'ed the people who picked
up that work - I'd already asked Randy to look at it as part of the work he's
doing to reconcile our DRM sources with upstream.

[1] https://hg.java.net/hg/solaris-x11~x-s12-clone/file/4e6b5865e3ec/open-src/lib/libdrm/solaris-drm-port.patch

I keep a subset in my local git repo to enable building from upstream since the
raw upstream builds don't work without at least some of it.   (See attached 
patches for that subset.)

-- 
	-Alan Coopersmith-              alan.coopersmith@oracle.com
	 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

[-- Attachment #2: 0001-Make-data-passed-to-ioctl-s-on-Solaris-match-the-Sol.patch --]
[-- Type: text/plain, Size: 2078 bytes --]

From 2186cc5946085c4f6cf5c1191abf7518cbf5b1bb Mon Sep 17 00:00:00 2001
From: Alan Coopersmith <alan.coopersmith@sun.com>
Date: Tue, 17 Jun 2008 15:47:23 -0700
Subject: [PATCH:libdrm 1/2] Make data passed to ioctl's on Solaris match the
 Solaris kernel DRI implementation

---
 include/drm/drm.h |   13 +++++++++++++
 xf86drm.c         |    7 +++++++
 2 files changed, 20 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 229a29f..ec96620 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -210,12 +210,22 @@ struct drm_ctx_priv_map {
  * \sa drmAddMap().
  */
 struct drm_map {
+#ifdef __sun
+	unsigned long long offset;
+				/**< Requested physical address (0 for SAREA)*/
+	unsigned long long handle;
+				/**< User-space: "Handle" to pass to mmap() */
+				/**< Kernel-space: kernel-virtual address */
+#else
 	unsigned long offset;	 /**< Requested physical address (0 for SAREA)*/
+#endif
 	unsigned long size;	 /**< Requested physical size (bytes) */
 	enum drm_map_type type;	 /**< Type of memory to map */
 	enum drm_map_flags flags;	 /**< Flags */
+#ifndef __sun
 	void *handle;		 /**< User-space: "Handle" to pass to mmap() */
 				 /**< Kernel-space: kernel-virtual address */
+#endif
 	int mtrr;		 /**< MTRR slot used */
 	/*   Private data */
 };
@@ -379,6 +389,9 @@ struct drm_buf_map {
 	void *virtual;		/**< Mmap'd area in user-virtual */
 #endif
 	struct drm_buf_pub *list;	/**< Buffer information */
+#ifdef __sun
+	int fd;
+#endif
 };
 
 /**
diff --git a/xf86drm.c b/xf86drm.c
index e73cddd..fc2c956 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -1096,7 +1096,11 @@ int drmRmMap(int fd, drm_handle_t handle)
     drm_map_t map;
 
     memclear(map);
+#ifdef __sun
+    map.handle = handle;
+#else
     map.handle = (void *)(uintptr_t)handle;
+#endif
 
     if(drmIoctl(fd, DRM_IOCTL_RM_MAP, &map))
 	return -errno;
@@ -1330,6 +1334,9 @@ drmBufMapPtr drmMapBufs(int fd)
     int           i;
 
     memclear(bufs);
+#ifdef __sun
+    bufs.fd = fd;
+#endif
     if (drmIoctl(fd, DRM_IOCTL_MAP_BUFS, &bufs))
 	return NULL;
 
-- 
1.7.9.2


[-- Attachment #3: 0002-Add-_IOC-definition-for-Solaris-OpenSolaris.patch --]
[-- Type: text/plain, Size: 1201 bytes --]

From 21f07103c94b6df7a64b6f1dfe981f8b69e4bb52 Mon Sep 17 00:00:00 2001
From: Alan Coopersmith <alan.coopersmith@sun.com>
Date: Wed, 16 Dec 2009 14:57:54 -0800
Subject: [PATCH:libdrm 2/2] Add _IOC definition for Solaris/OpenSolaris

Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
---
 xf86drm.h |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/xf86drm.h b/xf86drm.h
index 40c55c9..781c323 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -56,9 +56,17 @@ extern "C" {
 #define DRM_IOC_READWRITE	_IOC_READ|_IOC_WRITE
 #define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
 
-#else /* One of the *BSDs */
+#else /* One of the *BSDs or Solaris */
 
 #include <sys/ioccom.h>
+
+#if defined(__sun) && !defined(_IOC)
+#define _IOC(dir, group, nr, size)                                      \
+    ((dir) == DRM_IOC_READWRITE ? _IOWRN((group), (nr), (size)) :       \
+     ((dir) == DRM_IOC_WRITE ? _IOWN((group), (nr), (size)) :           \
+      /* (dir) == DRM_IOC_READ */  _IORN((group), (nr), (size)) ))
+#endif
+
 #define DRM_IOCTL_NR(n)         ((n) & 0xff)
 #define DRM_IOC_VOID            IOC_VOID
 #define DRM_IOC_READ            IOC_OUT
-- 
1.7.9.2


[-- Attachment #4: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Emil Velikov]

On 23/03/15 01:46, Alan Coopersmith wrote:
> On 03/ 9/15 05:37 AM, Emil Velikov wrote:
>> The former does not imply the latter and vice-versa. One such example is
>> the Sun compiler.
>>
>> Cc: Alan Coopersmith <alan.coopersmith@oracle.com>
>> Cc: Thierry Reding <treding@nvidia.com>
>> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
>> ---
>>
>> Hi Alan,
>> Can you please take a look it this series covers the symbol visibility
>> issues mentioned earlier ? In theory it should work like a charm but I
>> cannot really test it :-\
> 
> Patch 1 of 2 breaks configure on Solaris - I get:
> 
> checking for VALGRIND... no
> checking whether cc -xc99=%all supports __attribute__((visibility))...
> ./configure[13393]: set does not quote correctly, so add quotes:
> double-quote^J      # substitution turns \\ into \, and sed turns \ into
> \.^J      sed -n ^I"s//\\/g;^J^I 
> s/^\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\)=\(.*\)/\1=2/p"^J      ;;
> #(^J    *)^J      # : not found [No such file or directory]
> ./configure[13393]: {\1+set}: bad substitution
> ./configure[13992]: : cannot open
> ./configure[14000]: : cannot open
> ./configure[14032]: : cannot open
> ./configure[14051]: : cannot open
> ./configure[14128]: : cannot open
> ./configure[14139]: : cannot open
> ./configure[14150]: : cannot open
> ./configure[14435]: : cannot open
> ./configure[14563]: : cannot open
> ./configure[14603]: : cannot open
> ./configure[14610]: : cannot open
> ./configure[14639]: : cannot open
> ./configure[14671]: : cannot open
> ./configure[14740]: : cannot open
> ./configure[14744]: : cannot open
> ./configure[14778]: : cannot open
> ./configure[14928]: : cannot open
> ./configure[14948]: : cannot open
> ./configure[14962]: : cannot open
> ./configure[14966]: : cannot open
> configure: error: write failure creating
> It also generated new autoconf warnings generating the configure script:
> 
> configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
> configure.ac:422: the top level
> configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
> configure.ac:422: the top level
> autoreconf: running:
> /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoconf --force
> configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
> configure.ac:422: the top level
> autoreconf: running:
> /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoheader
> --force
> configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
> configure.ac:422: the top level
> autoreconf: running: automake --add-missing --copy --force-missing
> configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
> configure.ac:422: the top level
> 
> Both seem to have been caused by a misplaced close paren/brace pair and
> are fixed by:
> 
> --- a/configure.ac
> +++ b/configure.ac
> @@ -422,7 +422,7 @@ AC_MSG_CHECKING([whether $CC supports
> __attribute__((visibility))])
> AC_LINK_IFELSE([AC_LANG_PROGRAM([
>     int foo_default( void ) __attribute__((visibility("default")));
>     int foo_hidden( void ) __attribute__((visibility("hidden")));
> -], HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes]),
> AC_MSG_RESULT([no])]);
> +])], [HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes])],
> AC_MSG_RESULT([no]));
> 
> if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then
>     AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports
> __attribute__((visibility))])
> 
> (Gotta love autoconf and the mysteries of proper [] placements.)
> 
Playing around with [] is always fun. Thanks for the fix.

> After that I can build on Solaris with patch #1 applied, but patch #2
> then breaks
> due to Solaris Studio 12.4 compilers being more pedantic about
> prototypes in headers
> having the external visibility declarations too - lots of errors of the
> form:
> 
> "intel_bufmgr.c", line 60: redeclaration must have the same or more
> restrictive linker scoping: drm_intel_bo_alloc_for_render
> 
> It looks like none of the headers have the drm_public attributes the
> compiler wants
> to see there.
> 
Ouch... this explains why many places in X symbols are explicitly
annotated as X_HIDDEN. From a closer look it seems to be the
shorter/safe option. Plus to catch internal symbols slipping away I can
add wire up a few tests at make check :-)

>> Additionally can you guys build libdrm (barring the patch you sent the
>> other day), or you need some parts of this ancient patch
>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/files/libdrm-2.4.58-solaris.patch?view=markup
>>
> 
> That looks very much like an ancient patch we still have in our tree [1]
> since
> I never found out if we could upstream it or replace it from our former DRM
> team. Unfortunately, they're all gone now - I've cc'ed the people who
> picked
> up that work - I'd already asked Randy to look at it as part of the work
> he's
> doing to reconcile our DRM sources with upstream.
> 
> [1]
> https://hg.java.net/hg/solaris-x11~x-s12-clone/file/4e6b5865e3ec/open-src/lib/libdrm/solaris-drm-port.patch
> 
> 
> I keep a subset in my local git repo to enable building from upstream
> since the
> raw upstream builds don't work without at least some of it.   (See
> attached patches for that subset.)
> 
Thanks !

Was honestly hoping that patch #1 is not required as:
 - Getting the drm.h header in sync with the kernel will be annoying.
 - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
cruft for which, I would like to think, there are no more users.

Obviously the latter can be confirmed by Randy and friends.

Cheers,
Emil

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[randyf]

>
> Was honestly hoping that patch #1 is not required as:
> - Getting the drm.h header in sync with the kernel will be annoying.

   Indeed.

   I have a version of drm.h that works with Solaris and *should* still 
work with all other consumers, but as I still have a ways to get fully to 
speed, am hesitant to suggest a patch (are there other issues I have yet 
to discover).

> - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
> cruft for which, I would like to think, there are no more users.
>
> Obviously the latter can be confirmed by Randy and friends.

   I'm somewhat confused by this statement, as I still see the use of 
struct drm_map, as is it's usage in the Solaris ports of drm.  Am I 
missing something (like I said, I still have a ways to go to get to any 
decent level of contribution)?

   Cheers!

 	---- Randy
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Emil Velikov]

Hello Randy

On 26/03/15 16:56, randyf@sibernet.com wrote:
>>
>> Was honestly hoping that patch #1 is not required as:
>> - Getting the drm.h header in sync with the kernel will be annoying.
> 
>   Indeed.
> 
>   I have a version of drm.h that works with Solaris and *should* still
> work with all other consumers, but as I still have a ways to get fully
> to speed, am hesitant to suggest a patch (are there other issues I have
> yet to discover).
> 
Afaict the current Patch #1 will work with non-sun consumers.
Considering that the header(s) are currently out of sync (rather badly
imho), and the legacy note below would be nice if we can avoid the change.

Sometimes dri-devel can be a bit slow, so I would suggest that you post
finding/patches earlier rather than later.

>> - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
>> cruft for which, I would like to think, there are no more users.
>>
>> Obviously the latter can be confirmed by Randy and friends.
> 
>   I'm somewhat confused by this statement, as I still see the use of
> struct drm_map, as is it's usage in the Solaris ports of drm.  Am I
> missing something (like I said, I still have a ways to go to get to any
> decent level of contribution)?
> 
Can you relate Solaris ports of drm to the linux one in a sentence ? Or
if there is a public repo somewhere that would be great.

Guessing that "legacy" is the keyword here - it refers to old drm
drivers that do user mode-setting - UMS, amongst other nasty stuff.
Based on the latest kernel sources the ioctls (and the struct) are
considered as legacy, that plus the lack of any users (very quick grep)
seems rather conclusive.

If you guys are still using legacy drm drivers (for whatever reason)
that would be rather unfortunate. Otherwise you should be able to kill
off the remaining users of struct drm_map/drmMapBufs/drmRmMap.


Cheers,
Emil

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[randyf]

Sorry, went to drafts and not to send...

>>> - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
>>> cruft for which, I would like to think, there are no more users.
>>>
>>> Obviously the latter can be confirmed by Randy and friends.
>>
>>   I'm somewhat confused by this statement, as I still see the use of
>> struct drm_map, as is it's usage in the Solaris ports of drm.  Am I
>> missing something (like I said, I still have a ways to go to get to any
>> decent level of contribution)?
>>
> Can you relate Solaris ports of drm to the linux one in a sentence ? Or
> if there is a public repo somewhere that would be great.

   We may not be as behind as you might have believed, but we are not as 
close as I would like either.

   In that sentance: we have an i915 KMS driver with a decent amount of 
feature set (reasonable Haswell and DRI/DRM that would support that 
chipset) to the end of 2013 (when we had a significant amount of help from 
Intel), but we have a way too much Solaris-centric port than I would have 
preferred.

   The public repo (Mercurial based) is at:

     https://hg.java.net/hg/solaris-x11~x-s12-clone/

The kernel driver source specifically at:

     https://hg.java.net/hg/solaris-x11~x-s12-clone/file/tip/open-src/kernel

Note that the move of KMS drivers to this repo is recent, so there is 
little history of their evolution.

>
> Guessing that "legacy" is the keyword here - it refers to old drm
> drivers that do user mode-setting - UMS, amongst other nasty stuff.
> Based on the latest kernel sources the ioctls (and the struct) are
> considered as legacy, that plus the lack of any users (very quick grep)
> seems rather conclusive.

   AFAICT, we aren't that bad.  And where we divert is probably more driven 
by our lack of knowlege at the time than the ability to properly converge, 
but I have lots of ground to cover before I can properly resolve the 
differences.

>
> If you guys are still using legacy drm drivers (for whatever reason)
> that would be rather unfortunate. Otherwise you should be able to kill
> off the remaining users of struct drm_map/drmMapBufs/drmRmMap.
>

   For the most part, I have no problem with killing off any legacy layers 
that should go, as we will catch up (we do have the ability to at least 
offer a working frozen solution in the intrim).  At least in the near 
term, there are bodies actively working on getting the above driver source 
in sync with what the community has.

>
> Cheers,
> Emil
>

   Ditto!

   Randy
     (enjoying a bit of downtime a couple thousand miles from home)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Emil Velikov]

On 1 April 2015 at 15:42,  <randyf@sibernet.com> wrote:
>
> Sorry, went to drafts and not to send...
>
>>>> - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
>>>> cruft for which, I would like to think, there are no more users.
>>>>
>>>> Obviously the latter can be confirmed by Randy and friends.
>>>
>>>
>>>   I'm somewhat confused by this statement, as I still see the use of
>>> struct drm_map, as is it's usage in the Solaris ports of drm.  Am I
>>> missing something (like I said, I still have a ways to go to get to any
>>> decent level of contribution)?
>>>
>> Can you relate Solaris ports of drm to the linux one in a sentence ? Or
>> if there is a public repo somewhere that would be great.
>
>
>   We may not be as behind as you might have believed, but we are not as
> close as I would like either.
>
>   In that sentance: we have an i915 KMS driver with a decent amount of
> feature set (reasonable Haswell and DRI/DRM that would support that chipset)
> to the end of 2013 (when we had a significant amount of help from Intel),
> but we have a way too much Solaris-centric port than I would have preferred.
>
>   The public repo (Mercurial based) is at:
>
>     https://hg.java.net/hg/solaris-x11~x-s12-clone/
>
> The kernel driver source specifically at:
>
>     https://hg.java.net/hg/solaris-x11~x-s12-clone/file/tip/open-src/kernel
>
> Note that the move of KMS drivers to this repo is recent, so there is little
> history of their evolution.
>
Right, so things are a few newer than I thought, but still a bit off
from upstream drm. Not too shocking though considering the amount of
work that goes in there ;-) The thing that struck me is that every drm
driver comes with its own version of core drm. Not critisizing, just a
bit unusual.

>>
>> Guessing that "legacy" is the keyword here - it refers to old drm
>> drivers that do user mode-setting - UMS, amongst other nasty stuff.
>> Based on the latest kernel sources the ioctls (and the struct) are
>> considered as legacy, that plus the lack of any users (very quick grep)
>> seems rather conclusive.
>
>
>   AFAICT, we aren't that bad.  And where we divert is probably more driven
> by our lack of knowlege at the time than the ability to properly converge,
> but I have lots of ground to cover before I can properly resolve the
> differences.
>
Afaics you're using the last UMS-capable xf86-video-radeon, so maybe
not all places are updated/ported to KMS ? Not a big deal though.

>>
>> If you guys are still using legacy drm drivers (for whatever reason)
>> that would be rather unfortunate. Otherwise you should be able to kill
>> off the remaining users of struct drm_map/drmMapBufs/drmRmMap.
>>
>
>   For the most part, I have no problem with killing off any legacy layers
> that should go, as we will catch up (we do have the ability to at least
> offer a working frozen solution in the intrim).  At least in the near term,
> there are bodies actively working on getting the above driver source in sync
> with what the community has.
>
Great - glad to hear. Meanwhile I've noticed a few workarounds for
libdrm in the hg repo:
 - Force use of GCC and GNU make.
 - Disabled tests.

If you can provide some more information that would be appreciated.
Wouldn't mind squashing some bugs :-)

>>
>> Cheers,
>> Emil
>>
>
>   Ditto!
>
>   Randy
>     (enjoying a bit of downtime a couple thousand miles from home)
>
Sweet, enjoy the break.

Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[randyf]

On Sun, 5 Apr 2015, Emil Velikov wrote:

>> Note that the move of KMS drivers to this repo is recent, so there is little
>> history of their evolution.
>>
> Right, so things are a few newer than I thought, but still a bit off
> from upstream drm. Not too shocking though considering the amount of
> work that goes in there ;-)

   It is a bit overwhelming, so I (currently) tend to scan this list 
irregularly, and look for some source snapshot for porting reference.


> The thing that struck me is that every drm driver comes with its own 
> version of core drm. Not critisizing, just a bit unusual.

   So technically, only one driver has it's own version, and that is mostly 
driven by a lack of hardware to verify it continues to work as drm changes 
(and is slated for removal as the hardware is obsolete and unavailable).

   With (currently) only one other drm driver, it would appear that the drm 
core is unique to it (and to some extent it is), but the evolution would 
be to be towards a common drm.


>>
>>   AFAICT, we aren't that bad.  And where we divert is probably more driven
>> by our lack of knowlege at the time than the ability to properly converge,
>> but I have lots of ground to cover before I can properly resolve the
>> differences.
>>
> Afaics you're using the last UMS-capable xf86-video-radeon, so maybe
> not all places are updated/ported to KMS ? Not a big deal though.
>

   We're hopeful that this will change in the near future (we have someone 
working on a radeon KMS port, which is expected to use a common drm).


>>
>>   For the most part, I have no problem with killing off any legacy layers
>> that should go, as we will catch up (we do have the ability to at least
>> offer a working frozen solution in the intrim).  At least in the near term,
>> there are bodies actively working on getting the above driver source in sync
>> with what the community has.
>>
> Great - glad to hear. Meanwhile I've noticed a few workarounds for
> libdrm in the hg repo:
> - Force use of GCC and GNU make.
> - Disabled tests.
>
> If you can provide some more information that would be appreciated.
> Wouldn't mind squashing some bugs :-)

   Niveditha might be a better person to answer these questions as she has 
more history with libdrm.  I've only recently become aware of the tests, 
but hoping to somehow make use of them.

   I'm happy also to squash bugs as well, and also hoping to offer patches 
in the next couple of months (might need some help or understanding for 
those first few).


>>
>>   Randy
>>     (enjoying a bit of downtime a couple thousand miles from home)
>>
> Sweet, enjoy the break.
>

   It was sort of part work, part relax and nice to get away, but now back 
to reality.


 	---- Randy
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Niveditha Rau]

On 04/05/15 11:33, randyf@sibernet.com wrote:
>
>
> On Sun, 5 Apr 2015, Emil Velikov wrote:
>
>>> Note that the move of KMS drivers to this repo is recent, so there 
>>> is little
>>> history of their evolution.
>>>
>> Right, so things are a few newer than I thought, but still a bit off
>> from upstream drm. Not too shocking though considering the amount of
>> work that goes in there ;-)
>
>   It is a bit overwhelming, so I (currently) tend to scan this list 
> irregularly, and look for some source snapshot for porting reference.
>
>
>> The thing that struck me is that every drm driver comes with its own 
>> version of core drm. Not critisizing, just a bit unusual.
>
>   So technically, only one driver has it's own version, and that is 
> mostly driven by a lack of hardware to verify it continues to work as 
> drm changes (and is slated for removal as the hardware is obsolete and 
> unavailable).
>
>   With (currently) only one other drm driver, it would appear that the 
> drm core is unique to it (and to some extent it is), but the evolution 
> would be to be towards a common drm.
>
>
>>>
>>>   AFAICT, we aren't that bad.  And where we divert is probably more 
>>> driven
>>> by our lack of knowlege at the time than the ability to properly 
>>> converge,
>>> but I have lots of ground to cover before I can properly resolve the
>>> differences.
>>>
>> Afaics you're using the last UMS-capable xf86-video-radeon, so maybe
>> not all places are updated/ported to KMS ? Not a big deal though.
>>
>
>   We're hopeful that this will change in the near future (we have 
> someone working on a radeon KMS port, which is expected to use a 
> common drm).
>
>
>>>
>>>   For the most part, I have no problem with killing off any legacy 
>>> layers
>>> that should go, as we will catch up (we do have the ability to at least
>>> offer a working frozen solution in the intrim).  At least in the 
>>> near term,
>>> there are bodies actively working on getting the above driver source 
>>> in sync
>>> with what the community has.
>>>
>> Great - glad to hear. Meanwhile I've noticed a few workarounds for
>> libdrm in the hg repo:
>> - Force use of GCC and GNU make.
>> - Disabled tests.
>>
>> If you can provide some more information that would be appreciated.
>> Wouldn't mind squashing some bugs :-)
>
IIRC, we had issues with getting drm.7 without using GNU make.   And the 
build of libdrm_radeon was failing without using gcc.  I'll revert back 
to Studio and get you the failures since its been a while having made 
the switch.

We had disabled tests because of parfait failures which is part of our 
build process.  But I think we should be able to enable it now since we 
have an updated version of parfait that we are building with.

Thanks
Niveditha


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel