Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 8:51 PM, Marc Dietrich marvi...@gmx.de wrote: Am Sonntag 01 März 2015, 17:28:18 schrieb Sedat Dilek: On Sun, Mar 1, 2015 at 3:09 PM, Marc Dietrich marvi...@gmx.de wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. Cc: Emil Velikov emil.l.veli...@gmail.com Signed-off-by: Marc Dietrich marvi...@gmx.de [ CC Matt ] What happened to 2/2 (mapi tls part)? Was 2/2 dropped by a patch of Matt Turner (commit 76cd0f00f44c0935dc7d6a0e14e0515f08a8e1dc mapi: Don't rely on GNU void pointer arithmetic.)? Please clarify! I'll post another patch later which tries to fix the clang build error. For now, this patch is standalone and should not be applied together with other patches I sent before. Ping...? - Sedat - ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
Am Donnerstag, 12. März 2015, 19:57:39 schrieb Sedat Dilek: On Sun, Mar 1, 2015 at 8:51 PM, Marc Dietrich marvi...@gmx.de wrote: Am Sonntag 01 März 2015, 17:28:18 schrieb Sedat Dilek: On Sun, Mar 1, 2015 at 3:09 PM, Marc Dietrich marvi...@gmx.de wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. Cc: Emil Velikov emil.l.veli...@gmail.com Signed-off-by: Marc Dietrich marvi...@gmx.de [ CC Matt ] What happened to 2/2 (mapi tls part)? Was 2/2 dropped by a patch of Matt Turner (commit 76cd0f00f44c0935dc7d6a0e14e0515f08a8e1dc mapi: Don't rely on GNU void pointer arithmetic.)? Please clarify! I'll post another patch later which tries to fix the clang build error. For now, this patch is standalone and should not be applied together with other patches I sent before. Ping...? just found that my proposed fix doesn't work with --disable-shared-glapi. Maybe someone else may come up with a better solution... signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 3 March 2015 at 05:21, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 03/ 1/15 02:31 PM, Emil Velikov wrote: - Considering the lack of -fvisibility, what is the normal visibility level - hidden or default ? If the latter this means that every library/module built exports a ton of internal symbols. Default, unless you pass the -xldscope=hidden flag to Studio, as the Xserver does: http://cgit.freedesktop.org/xorg/xserver/tree/configure.ac?id=xorg-server-1.17.1#n1840 Would you mind rolling a similar patch for mesa, and testing it out. I'm suspecting that mesa is missing a few PUBLIC annotations. I will roll a similar one for libdrm, as I'm pretty sure it ought to be safe. Btw did we manage to get through with all the build issues for mesa 10.4/10.5 ? If there is something blocking it, please do shout/file a bug - when you have the time of course :-) - Using the __has_attribute macro looks great, although I would suspect that it will take a while for GCC and others to adopt(?). Probably, which is why X.Org uses it in addition to, instead of as a replacement for, the gcc version checks for now: Ouch.. caffeine deprived brain read your earlier comment as to replace :-\ Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 03/ 1/15 02:31 PM, Emil Velikov wrote: - Considering the lack of -fvisibility, what is the normal visibility level - hidden or default ? If the latter this means that every library/module built exports a ton of internal symbols. Default, unless you pass the -xldscope=hidden flag to Studio, as the Xserver does: http://cgit.freedesktop.org/xorg/xserver/tree/configure.ac?id=xorg-server-1.17.1#n1840 - Using the __has_attribute macro looks great, although I would suspect that it will take a while for GCC and others to adopt(?). Probably, which is why X.Org uses it in addition to, instead of as a replacement for, the gcc version checks for now: http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c913207585191801a9a1603e -alan- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 5:45 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 01/03/15 14:09, Marc Dietrich wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. Cc: Emil Velikov emil.l.veli...@gmail.com Signed-off-by: Marc Dietrich marvi...@gmx.de Reviewed-by: Emil Velikov emil.l.veli...@gmail.com Looks great thank you. I'm assuming that you're short on commit access so I'm push this around Wednesday, unless there are further comments. Where is the 2/2 of this patch? Alone it does not work with LLVM/Clang v3.6.0 with mesa v10.4.5. If there is an additional patch, please point me to it. $ grep -i visibility logs/build-and-install-log_mesa-10-4-5_gallivm-fixes_mapi-tls-fixes_visibility-compiler-flag-detection_enable-glx-tlsllvm-3-6-0.txt checking for __attribute__((visibility))... yes Otherwise, feel free to add my... Tested-by: Sedat Dilek sedat.di...@gmail.com - Sedat - ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 7:30 PM, Matt Turner matts...@gmail.com wrote:
On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich marvi...@gmx.de wrote:
This patch simplifies the visibility compiler flag detection in configure and
makes it more generic to also support compilers other than gcc.
This simplification relies on the assumption that compilers support
-fvisibility=... if and only if they support
attribute(visibility(...)).
I guess that might be the case, but the logic doesn't seem very sound.
Is the 'if test x$GCC = xyes; then' test actually rejecting clang?
It doesn't seem so, since above there's a 'if test x$GCC = xyes -a
x$acv_mesa_CLANG = xno; then'
So, I guess it looks to me like we already support visibility
detection for !gcc.
This simplified patch does not work as expected with 2/2 v3 (see [1]).
It breaks my build with mesa v10.4.5.
- Sedat -
[1] http://patchwork.freedesktop.org/patch/42679/
Cc: Emil Velikov emil.l.veli...@gmail.com
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
configure.ac | 32 +++-
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5fbb7bc..7565c0c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,6 +189,7 @@ AX_GCC_FUNC_ATTRIBUTE([flatten])
AX_GCC_FUNC_ATTRIBUTE([format])
AX_GCC_FUNC_ATTRIBUTE([malloc])
AX_GCC_FUNC_ATTRIBUTE([packed])
+AX_GCC_FUNC_ATTRIBUTE([visibility])
AM_CONDITIONAL([GEN_ASM_OFFSETS], test x$GEN_ASM_OFFSETS = xyes)
@@ -223,6 +224,12 @@ cygwin*)
;;
esac
+# Enable -fvisibility=hidden if using a compiler that supports it
+if test x${ax_cv_have_func_attribute_visibility} = xyes; then
+ VISIBILITY_CFLAGS=-fvisibility=hidden
+ VISIBILITY_CXXFLAGS=-fvisibility=hidden
Indent these the same amount as elsewhere.
+fi
+
dnl Add flags for gcc and g++
if test x$GCC = xyes; then
CFLAGS=$CFLAGS -Wall
@@ -245,18 +252,6 @@ if test x$GCC = xyes; then
AC_MSG_RESULT([yes]),
[CFLAGS=$save_CFLAGS -Wmissing-prototypes;
AC_MSG_RESULT([no])]);
-
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CFLAGS=$CFLAGS
-AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
-VISIBILITY_CFLAGS=-fvisibility=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
-
# Work around aliasing bugs - developers should comment this out
CFLAGS=$CFLAGS -fno-strict-aliasing
@@ -267,19 +262,6 @@ fi
if test x$GXX = xyes; then
CXXFLAGS=$CXXFLAGS -Wall
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CXXFLAGS=$CXXFLAGS
-AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden])
-VISIBILITY_CXXFLAGS=-fvisibility=hidden
-CXXFLAGS=$CXXFLAGS $VISIBILITY_CXXFLAGS
-AC_LANG_PUSH([C++])
-AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
- [VISIBILITY_CXXFLAGS= ; AC_MSG_RESULT([no])]);
-AC_LANG_POP([C++])
-
-# Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed.
-CXXFLAGS=$save_CXXFLAGS
-
# Work around aliasing bugs - developers should comment this out
CXXFLAGS=$CXXFLAGS -fno-strict-aliasing
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 11:31 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 01/03/15 21:05, Alan Coopersmith wrote: On 03/ 1/15 10:57 AM, Emil Velikov wrote: On 01/03/15 18:30, Matt Turner wrote: On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich marvi...@gmx.de wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. This simplification relies on the assumption that compilers support -fvisibility=... if and only if they support attribute(visibility(...)). Hmm you're correct. I've naively assumed they both go hand in hand. The latest Solaris Studio compilers support attribute(visibility), but not -fvisibility. The absolute latest (12.4, released a few months back) also support the clang has_attribute() extension for checking what's supported (which is one of the reasons it's used in the X11/Xfuncproto.h header in xproto 7.0.27 later). Ouch... so I was quite naive indeed. So here are some interesting bits: - HAVE_FUNC_ATTRIBUTE_VISIBILITY is likely to be undefined (0) with Solaris Studio compilers, as the m4 macro checks for __attribute__((visibility(default))); __attribute__((visibility(hidden))); __attribute__((visibility(internal))); __attribute__((visibility(protected))); As the last one does not appear in the 12.4 C User's Guide (linked below) the compiler will likely error/warn. Perhaps we can nuke the latter two, as they are unused presently, and add them back when needed ? - Considering the lack of -fvisibility, what is the normal visibility level - hidden or default ? If the latter this means that every library/module built exports a ton of internal symbols. From [1] for gcc: Despite the nomenclature, ‘default’ always means public; i.e., available to be linked against from outside the shared object. ‘protected’ and ‘internal’ are pretty useless in real-world usage so the only other commonly used option is ‘hidden’. The default if -fvisibility isn't specified is ‘default’, i.e., make every symbol public—this causes the same behavior as previous versions of GCC. - Sedat - [1] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html - -fvisibility=[default|internal|hidden|protected] - Using the __has_attribute macro looks great, although I would suspect that it will take a while for GCC and others to adopt(?). Thanks for the insightful input Alan. -Emil https://docs.oracle.com/cd/E37069_01/html/E37074/gjzke.html https://docs.oracle.com/cd/E37069_01/html/E37074/gopqx.html http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c913207585191801a9a1603e ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 3:09 PM, Marc Dietrich marvi...@gmx.de wrote:
This patch simplifies the visibility compiler flag detection in configure and
makes it more generic to also support compilers other than gcc.
Cc: Emil Velikov emil.l.veli...@gmail.com
Signed-off-by: Marc Dietrich marvi...@gmx.de
[ CC Matt ]
What happened to 2/2 (mapi tls part)?
Was 2/2 dropped by a patch of Matt Turner (commit
76cd0f00f44c0935dc7d6a0e14e0515f08a8e1dc mapi: Don't rely on GNU void
pointer arithmetic.)?
Please clarify!
- Sedat -
---
configure.ac | 32 +++-
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5fbb7bc..7565c0c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,6 +189,7 @@ AX_GCC_FUNC_ATTRIBUTE([flatten])
AX_GCC_FUNC_ATTRIBUTE([format])
AX_GCC_FUNC_ATTRIBUTE([malloc])
AX_GCC_FUNC_ATTRIBUTE([packed])
+AX_GCC_FUNC_ATTRIBUTE([visibility])
AM_CONDITIONAL([GEN_ASM_OFFSETS], test x$GEN_ASM_OFFSETS = xyes)
@@ -223,6 +224,12 @@ cygwin*)
;;
esac
+# Enable -fvisibility=hidden if using a compiler that supports it
+if test x${ax_cv_have_func_attribute_visibility} = xyes; then
+ VISIBILITY_CFLAGS=-fvisibility=hidden
+ VISIBILITY_CXXFLAGS=-fvisibility=hidden
+fi
+
dnl Add flags for gcc and g++
if test x$GCC = xyes; then
CFLAGS=$CFLAGS -Wall
@@ -245,18 +252,6 @@ if test x$GCC = xyes; then
AC_MSG_RESULT([yes]),
[CFLAGS=$save_CFLAGS -Wmissing-prototypes;
AC_MSG_RESULT([no])]);
-
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CFLAGS=$CFLAGS
-AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
-VISIBILITY_CFLAGS=-fvisibility=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
-
# Work around aliasing bugs - developers should comment this out
CFLAGS=$CFLAGS -fno-strict-aliasing
@@ -267,19 +262,6 @@ fi
if test x$GXX = xyes; then
CXXFLAGS=$CXXFLAGS -Wall
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CXXFLAGS=$CXXFLAGS
-AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden])
-VISIBILITY_CXXFLAGS=-fvisibility=hidden
-CXXFLAGS=$CXXFLAGS $VISIBILITY_CXXFLAGS
-AC_LANG_PUSH([C++])
-AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
- [VISIBILITY_CXXFLAGS= ; AC_MSG_RESULT([no])]);
-AC_LANG_POP([C++])
-
-# Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed.
-CXXFLAGS=$save_CXXFLAGS
-
# Work around aliasing bugs - developers should comment this out
CXXFLAGS=$CXXFLAGS -fno-strict-aliasing
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 03/ 1/15 10:57 AM, Emil Velikov wrote: On 01/03/15 18:30, Matt Turner wrote: On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich marvi...@gmx.de wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. This simplification relies on the assumption that compilers support -fvisibility=... if and only if they support attribute(visibility(...)). Hmm you're correct. I've naively assumed they both go hand in hand. The latest Solaris Studio compilers support attribute(visibility), but not -fvisibility. The absolute latest (12.4, released a few months back) also support the clang has_attribute() extension for checking what's supported (which is one of the reasons it's used in the X11/Xfuncproto.h header in xproto 7.0.27 later). https://docs.oracle.com/cd/E37069_01/html/E37074/gjzke.html https://docs.oracle.com/cd/E37069_01/html/E37074/gopqx.html http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c913207585191801a9a1603e -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 1 March 2015 at 22:38, Sedat Dilek sedat.di...@gmail.com wrote: On Sun, Mar 1, 2015 at 11:31 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 01/03/15 21:05, Alan Coopersmith wrote: On 03/ 1/15 10:57 AM, Emil Velikov wrote: On 01/03/15 18:30, Matt Turner wrote: On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich marvi...@gmx.de wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. This simplification relies on the assumption that compilers support -fvisibility=... if and only if they support attribute(visibility(...)). Hmm you're correct. I've naively assumed they both go hand in hand. The latest Solaris Studio compilers support attribute(visibility), but not -fvisibility. The absolute latest (12.4, released a few months back) also support the clang has_attribute() extension for checking what's supported (which is one of the reasons it's used in the X11/Xfuncproto.h header in xproto 7.0.27 later). Ouch... so I was quite naive indeed. So here are some interesting bits: - HAVE_FUNC_ATTRIBUTE_VISIBILITY is likely to be undefined (0) with Solaris Studio compilers, as the m4 macro checks for __attribute__((visibility(default))); __attribute__((visibility(hidden))); __attribute__((visibility(internal))); __attribute__((visibility(protected))); As the last one does not appear in the 12.4 C User's Guide (linked below) the compiler will likely error/warn. Perhaps we can nuke the latter two, as they are unused presently, and add them back when needed ? - Considering the lack of -fvisibility, what is the normal visibility level - hidden or default ? If the latter this means that every library/module built exports a ton of internal symbols. From [1] for gcc: Despite the nomenclature, ‘default’ always means public; i.e., available to be linked against from outside the shared object. ‘protected’ and ‘internal’ are pretty useless in real-world usage so the only other commonly used option is ‘hidden’. The default if -fvisibility isn't specified is ‘default’, i.e., make every symbol public—this causes the same behavior as previous versions of GCC. I was talking/asking about the Solaris Studio compilers. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 01/03/15 21:05, Alan Coopersmith wrote: On 03/ 1/15 10:57 AM, Emil Velikov wrote: On 01/03/15 18:30, Matt Turner wrote: On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich marvi...@gmx.de wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. This simplification relies on the assumption that compilers support -fvisibility=... if and only if they support attribute(visibility(...)). Hmm you're correct. I've naively assumed they both go hand in hand. The latest Solaris Studio compilers support attribute(visibility), but not -fvisibility. The absolute latest (12.4, released a few months back) also support the clang has_attribute() extension for checking what's supported (which is one of the reasons it's used in the X11/Xfuncproto.h header in xproto 7.0.27 later). Ouch... so I was quite naive indeed. So here are some interesting bits: - HAVE_FUNC_ATTRIBUTE_VISIBILITY is likely to be undefined (0) with Solaris Studio compilers, as the m4 macro checks for __attribute__((visibility(default))); __attribute__((visibility(hidden))); __attribute__((visibility(internal))); __attribute__((visibility(protected))); As the last one does not appear in the 12.4 C User's Guide (linked below) the compiler will likely error/warn. Perhaps we can nuke the latter two, as they are unused presently, and add them back when needed ? - Considering the lack of -fvisibility, what is the normal visibility level - hidden or default ? If the latter this means that every library/module built exports a ton of internal symbols. - Using the __has_attribute macro looks great, although I would suspect that it will take a while for GCC and others to adopt(?). Thanks for the insightful input Alan. -Emil https://docs.oracle.com/cd/E37069_01/html/E37074/gjzke.html https://docs.oracle.com/cd/E37069_01/html/E37074/gopqx.html http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=ffd4a13042d24cb5c913207585191801a9a1603e ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
This patch simplifies the visibility compiler flag detection in configure and
makes it more generic to also support compilers other than gcc.
Cc: Emil Velikov emil.l.veli...@gmail.com
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
configure.ac | 32 +++-
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5fbb7bc..7565c0c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,6 +189,7 @@ AX_GCC_FUNC_ATTRIBUTE([flatten])
AX_GCC_FUNC_ATTRIBUTE([format])
AX_GCC_FUNC_ATTRIBUTE([malloc])
AX_GCC_FUNC_ATTRIBUTE([packed])
+AX_GCC_FUNC_ATTRIBUTE([visibility])
AM_CONDITIONAL([GEN_ASM_OFFSETS], test x$GEN_ASM_OFFSETS = xyes)
@@ -223,6 +224,12 @@ cygwin*)
;;
esac
+# Enable -fvisibility=hidden if using a compiler that supports it
+if test x${ax_cv_have_func_attribute_visibility} = xyes; then
+ VISIBILITY_CFLAGS=-fvisibility=hidden
+ VISIBILITY_CXXFLAGS=-fvisibility=hidden
+fi
+
dnl Add flags for gcc and g++
if test x$GCC = xyes; then
CFLAGS=$CFLAGS -Wall
@@ -245,18 +252,6 @@ if test x$GCC = xyes; then
AC_MSG_RESULT([yes]),
[CFLAGS=$save_CFLAGS -Wmissing-prototypes;
AC_MSG_RESULT([no])]);
-
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CFLAGS=$CFLAGS
-AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
-VISIBILITY_CFLAGS=-fvisibility=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
-
# Work around aliasing bugs - developers should comment this out
CFLAGS=$CFLAGS -fno-strict-aliasing
@@ -267,19 +262,6 @@ fi
if test x$GXX = xyes; then
CXXFLAGS=$CXXFLAGS -Wall
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CXXFLAGS=$CXXFLAGS
-AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden])
-VISIBILITY_CXXFLAGS=-fvisibility=hidden
-CXXFLAGS=$CXXFLAGS $VISIBILITY_CXXFLAGS
-AC_LANG_PUSH([C++])
-AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
- [VISIBILITY_CXXFLAGS= ; AC_MSG_RESULT([no])]);
-AC_LANG_POP([C++])
-
-# Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed.
-CXXFLAGS=$save_CXXFLAGS
-
# Work around aliasing bugs - developers should comment this out
CXXFLAGS=$CXXFLAGS -fno-strict-aliasing
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
Am Sonntag 01 März 2015, 10:30:08 schrieb Matt Turner: On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich marvi...@gmx.de wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. This simplification relies on the assumption that compilers support -fvisibility=... if and only if they support attribute(visibility(...)). I guess that might be the case, but the logic doesn't seem very sound. I think it's ok, because attribute(visibilty) is a gcc extension. So if any compiler supports this, it wants to be gcc compatible for some reason. Therefore -IMHO- this implicitly implies -fvisibility. Is the 'if test x$GCC = xyes; then' test actually rejecting clang? It doesn't seem so, since above there's a 'if test x$GCC = xyes -a x$acv_mesa_CLANG = xno; then' So, I guess it looks to me like we already support visibility detection for !gcc. clang reports itself as gcc 4.2.1 or so (clang -dumpversion). This is why there is an extra test. I see no obvious reason to keep it inside the if block because it should be generic (not gcc/clang specific). Marc signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
Am Sonntag 01 März 2015, 17:28:18 schrieb Sedat Dilek: On Sun, Mar 1, 2015 at 3:09 PM, Marc Dietrich marvi...@gmx.de wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. Cc: Emil Velikov emil.l.veli...@gmail.com Signed-off-by: Marc Dietrich marvi...@gmx.de [ CC Matt ] What happened to 2/2 (mapi tls part)? Was 2/2 dropped by a patch of Matt Turner (commit 76cd0f00f44c0935dc7d6a0e14e0515f08a8e1dc mapi: Don't rely on GNU void pointer arithmetic.)? Please clarify! I'll post another patch later which tries to fix the clang build error. For now, this patch is standalone and should not be applied together with other patches I sent before. Marc signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 01/03/15 14:09, Marc Dietrich wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. Cc: Emil Velikov emil.l.veli...@gmail.com Signed-off-by: Marc Dietrich marvi...@gmx.de Reviewed-by: Emil Velikov emil.l.veli...@gmail.com Looks great thank you. I'm assuming that you're short on commit access so I'm push this around Wednesday, unless there are further comments. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich marvi...@gmx.de wrote:
This patch simplifies the visibility compiler flag detection in configure and
makes it more generic to also support compilers other than gcc.
This simplification relies on the assumption that compilers support
-fvisibility=... if and only if they support
attribute(visibility(...)).
I guess that might be the case, but the logic doesn't seem very sound.
Is the 'if test x$GCC = xyes; then' test actually rejecting clang?
It doesn't seem so, since above there's a 'if test x$GCC = xyes -a
x$acv_mesa_CLANG = xno; then'
So, I guess it looks to me like we already support visibility
detection for !gcc.
Cc: Emil Velikov emil.l.veli...@gmail.com
Signed-off-by: Marc Dietrich marvi...@gmx.de
---
configure.ac | 32 +++-
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5fbb7bc..7565c0c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -189,6 +189,7 @@ AX_GCC_FUNC_ATTRIBUTE([flatten])
AX_GCC_FUNC_ATTRIBUTE([format])
AX_GCC_FUNC_ATTRIBUTE([malloc])
AX_GCC_FUNC_ATTRIBUTE([packed])
+AX_GCC_FUNC_ATTRIBUTE([visibility])
AM_CONDITIONAL([GEN_ASM_OFFSETS], test x$GEN_ASM_OFFSETS = xyes)
@@ -223,6 +224,12 @@ cygwin*)
;;
esac
+# Enable -fvisibility=hidden if using a compiler that supports it
+if test x${ax_cv_have_func_attribute_visibility} = xyes; then
+ VISIBILITY_CFLAGS=-fvisibility=hidden
+ VISIBILITY_CXXFLAGS=-fvisibility=hidden
Indent these the same amount as elsewhere.
+fi
+
dnl Add flags for gcc and g++
if test x$GCC = xyes; then
CFLAGS=$CFLAGS -Wall
@@ -245,18 +252,6 @@ if test x$GCC = xyes; then
AC_MSG_RESULT([yes]),
[CFLAGS=$save_CFLAGS -Wmissing-prototypes;
AC_MSG_RESULT([no])]);
-
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CFLAGS=$CFLAGS
-AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden])
-VISIBILITY_CFLAGS=-fvisibility=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
-
# Work around aliasing bugs - developers should comment this out
CFLAGS=$CFLAGS -fno-strict-aliasing
@@ -267,19 +262,6 @@ fi
if test x$GXX = xyes; then
CXXFLAGS=$CXXFLAGS -Wall
-# Enable -fvisibility=hidden if using a gcc that supports it
-save_CXXFLAGS=$CXXFLAGS
-AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden])
-VISIBILITY_CXXFLAGS=-fvisibility=hidden
-CXXFLAGS=$CXXFLAGS $VISIBILITY_CXXFLAGS
-AC_LANG_PUSH([C++])
-AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]),
- [VISIBILITY_CXXFLAGS= ; AC_MSG_RESULT([no])]);
-AC_LANG_POP([C++])
-
-# Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed.
-CXXFLAGS=$save_CXXFLAGS
-
# Work around aliasing bugs - developers should comment this out
CXXFLAGS=$CXXFLAGS -fno-strict-aliasing
--
2.3.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: simplify visibility compiler flag detection
On 01/03/15 18:30, Matt Turner wrote: On Sun, Mar 1, 2015 at 6:09 AM, Marc Dietrich marvi...@gmx.de wrote: This patch simplifies the visibility compiler flag detection in configure and makes it more generic to also support compilers other than gcc. This simplification relies on the assumption that compilers support -fvisibility=... if and only if they support attribute(visibility(...)). Hmm you're correct. I've naively assumed they both go hand in hand. I guess that might be the case, but the logic doesn't seem very sound. Is the 'if test x$GCC = xyes; then' test actually rejecting clang? It doesn't seem so, since above there's a 'if test x$GCC = xyes -a x$acv_mesa_CLANG = xno; then' So, I guess it looks to me like we already support visibility detection for !gcc. The HAVE_FUNC_ATTRIBUTE_VISIBILITY define should already be there, regardless of the compiler. On the -fvisibility... side we handle it for GCC and compatible (i.e. clang) compilers. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
