[patch,build] Build libgfortran and libgomp as DLL on win32

[patch,build] Build libgfortran and libgomp as DLL on win32

[François-Xavier Coudert]

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

The attached patch allows libgfortran and libgomp to be built as
shared libraries (DLL) on i386-pc-mingw32. It simply adds
-no-undefined to the linker flags, and checks for support in the
configure.ac: LT_INIT([shared static win32-dll dlopen]).

This was bootstrapped and manually tested on i386-pc-mingw32.
(Building libgomp requires using pthreads-win32 and explicitly
configuring with --enable-libgomp.) I think I need the approval of
build maintainers for this patch, but other opinions are welcome
(especially the windows maintainers).

FX


PS: I intend to do the same for libobjc and libstdc++-v3, but I can't
make it work for libobjc (I'm investigating) and libstdc++-v3 is
currently broken on mingw32. For libssp, I think I'd need some advice:
who maintains it? (there's no listed maintainer AFAICT)

[-- Attachment #2: win32-dll.ChangeLog --]
[-- Type: application/octet-stream, Size: 562 bytes --]

libgfortran/
2007-08-28  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

	* configure.ac: Add win32 DLL support.
	* Makefile.am: Add -no-undefined linker flag.
	* Makefile.in: Regenerate.
	* configure: Regenerate.


libgomp/
2007-08-28  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

	* libgomp/configure.ac: Add win32 DLL support.
	* libgomp/Makefile.am: Add -no-undefined linker flag.
	* libgomp/Makefile.in: Regenerate.
	* libgomp/testsuite/Makefile.in: Regenerate.
	* libgomp/config.h.in: Regenerate.
	* libgomp/configure: Regenerate.

[-- Attachment #3: win32-dll.diff --]
[-- Type: application/octet-stream, Size: 2136 bytes --]

Index: libgfortran/configure.ac
===================================================================
--- libgfortran/configure.ac	(revision 127831)
+++ libgfortran/configure.ac	(working copy)
@@ -146,8 +146,7 @@
 
 # Configure libtool
 #AC_MSG_NOTICE([====== Starting libtool configuration])
-AC_LIBTOOL_DLOPEN
-AM_PROG_LIBTOOL
+LT_INIT([shared static win32-dll dlopen])
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
 #AC_MSG_NOTICE([====== Finished libtool configuration]) ; sleep 10
Index: libgfortran/Makefile.am
===================================================================
--- libgfortran/Makefile.am	(revision 127831)
+++ libgfortran/Makefile.am	(working copy)
@@ -15,7 +15,7 @@
 
 toolexeclib_LTLIBRARIES = libgfortran.la
 libgfortran_la_LINK = $(LINK)
-libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lm $(extra_ldflags_libgfortran) $(version_arg)
+libgfortran_la_LDFLAGS = -no-undefined -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lm $(extra_ldflags_libgfortran) $(version_arg)
 
 myexeclib_LTLIBRARIES = libgfortranbegin.la
 myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
Index: libgomp/configure.ac
===================================================================
--- libgomp/configure.ac	(revision 127831)
+++ libgomp/configure.ac	(working copy)
@@ -139,7 +139,7 @@
 
 
 # Configure libtool
-AM_PROG_LIBTOOL
+LT_INIT([shared static win32-dll dlopen])
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
 
Index: libgomp/Makefile.am
===================================================================
--- libgomp/Makefile.am	(revision 127831)
+++ libgomp/Makefile.am	(working copy)
@@ -29,7 +29,7 @@
 libgomp_version_script =
 endif
 libgomp_version_info = -version-info $(libtool_VERSION)
-libgomp_la_LDFLAGS = $(libgomp_version_info) $(libgomp_version_script)
+libgomp_la_LDFLAGS = -no-undefined $(libgomp_version_info) $(libgomp_version_script)
 
 libgomp_la_SOURCES = alloc.c barrier.c critical.c env.c error.c iter.c \
 	loop.c ordered.c parallel.c sections.c single.c team.c work.c \

RE: [patch,build] Build libgfortran and libgomp as DLL on win32

[Danny Smith]

> From: François-Xavier Coudert 
> Sent: Wednesday, 29 August 2007 1:48 a.m.
> 
> The attached patch allows libgfortran and libgomp to be built as
> shared libraries (DLL) on i386-pc-mingw32. It simply adds
> -no-undefined to the linker flags, and checks for support in the
> configure.ac: LT_INIT([shared static win32-dll dlopen]).
> 
> This was bootstrapped and manually tested on i386-pc-mingw32.
> (Building libgomp requires using pthreads-win32 and explicitly
> configuring with --enable-libgomp.) I think I need the approval of
> build maintainers for this patch, but other opinions are welcome
> (especially the windows maintainers).
> 
How is versioning handled?

There are problems with testsuite.  In order to test the dll's they need
to be installed in PATH or the same directory as the executable.

For thread support you need to build dll with -mthreads
I believe that shared runtime dll's also need to be built with
shared-libgcc.  

How is dependency on pthread.dll handled for mingw>? Do you force use of
a specific version of the third-party prthreads-win32 dll?

If I understand the GPL correctly, if a user redistributes a binary that
depend on libgfortran.dll and so also redistribute the libgfortran.dll
library, the user must offer to supply source for the libgfortan.dll.
That is, the same rules apply to redistributing libgfortan.dll as
libgfortran.a
Is that correct?  That has been my answer when asked the question in the
past.


But apart from that, no problems

Danny
> FX
> 

Re: [patch,build] Build libgfortran and libgomp as DLL on win32

[François-Xavier Coudert]

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

OK, let's try to get all your questions answered. If my answers don't
make sense, please tell me. I'm rather new to windows shared
libraries, so I hope I don't mix things up too badly.

> How is versioning handled?

symbol versioning or library version-naming scheme? DLLs are named
according to their major version number: libgfortran-3.dll,
libstdc++-6.dll, etc.

For symbol versioning, configure checks that -shared
-Wl,--version-script is supported, and finds that it is. So, it's
passed as linker flags (e.g.,
-Wl,--version-script=$(srcdir)/gfortran.map). I don't know how to
check the resulting DLL to see if symbol versioning is indeed present,
but if you tell me how to do it, I will.

> There are problems with testsuite.  In order to test the dll's they need
> to be installed in PATH or the same directory as the executable.

As I said, I'm not setup for running the testsuite, but as soon as I
make it, I'll look into it. (For now, you can build for
--disable-shared.)

> For thread support you need to build dll with -mthreads

Hum, that one has me puzzled. The doc for this option says it's
required for thread-safe exception handling: wouldn't you need it also
for static libraries? In any case, I've looked and it's not currently
used (well, it is implied by -fopenmp when compiling user code, but
it's not used for compilation of our runtime libraries). Maybe this
could be put into a toplevel config/mt-mingw file?

> I believe that shared runtime dll's also need to be built with
> shared-libgcc.

Why? I did all my testing with a static libgcc, and it works fine.
Even on other systems, you can use -static-libgcc with shared runtime
libraries.

> How is dependency on pthread.dll handled for mingw? Do you force use of
> a specific version of the third-party prthreads-win32 dll?

I think this is orthogonal to the shared runtime libraries support. By
default, libgomp isn't built on mingw, but if you have a libpthread
accessible, you can configure with --enable-libgomp. I do it with
pthreads-win32, but it could be any pthreads library, really. In the
case of pthreads-win32, they have a libpthread.a and a pthreadGC2.dll.
Linking in libpthread.a creates a dependency on pthreadGC2.dll. From
what I understand, a libgomp built with a given version of
pthreads-win32 would work with any later version in the 2.x series,
but it's probably safer to use the same version.

However, this will not affect the standard mingw build in any way.
It's only that Windows gfortran users have shown interest in OpenMP,
so I'm doing my builds with it.

> If I understand the GPL correctly, if a user redistributes a binary that
> depend on libgfortran.dll and so also redistribute the libgfortran.dll
> library, the user must offer to supply source for the libgfortan.dll.
> That is, the same rules apply to redistributing libgfortan.dll as
> libgfortran.a
> Is that correct?  That has been my answer when asked the question in the
> past.

Well, I'm especially bad at this kind of things, but I suspect you're
right. A readme.txt file in the directory containing the libgfortran
DLL giving the URL for the library is probably a sufficient offer.

> But apart from that, no problems

OK, well, I've expanded my patch to also allow building DLLs for
libssp and libstdc++-v3. Please find attached the new patch and
ChangeLog. Build maintainers, OK to commit?

FX

[-- Attachment #2: dll2.ChangeLog --]
[-- Type: application/octet-stream, Size: 1216 bytes --]

libgfortran/
2007-08-29  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

	* configure.ac: Add win32 DLL support.
	* Makefile.am: Add -no-undefined linker flag.
	* configure: Regenerate.
	* Makefile.in: Regenerate.


libgomp/
2007-08-29  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

	* configure.ac: Add win32 DLL support.
	* Makefile.am: Add -no-undefined linker flag.
	* config.h.in: Regenerate.
	* configure: Regenerate.
	* Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.


libssp/
2007-08-29  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

	* configure.ac: Add win32 DLL support.
	* Makefile.am: Add -no-undefined linker flag.
	* config.h.in: Regenerate.
	* configure: Regenerate.
	* Makefile.in: Regenerate.


libstdc++-v3/
2007-08-29  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

	* configure.ac: Add win32 DLL support.
	* src/Makefile.am: Add -no-undefined linker flag.
	* configure: Regenerate.
	* Makefile.in: Regenerate.
	* include/Makefile.in: Regenerate.
	* libmath/Makefile.in: Regenerate.
	* libsupc++/Makefile.in: Regenerate.
	* po/Makefile.in: Regenerate.
	* src/Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.


[-- Attachment #3: dll2.diff --]
[-- Type: application/octet-stream, Size: 4025 bytes --]

Index: libgfortran/configure.ac
===================================================================
--- libgfortran/configure.ac	(revision 127859)
+++ libgfortran/configure.ac	(working copy)
@@ -146,8 +146,7 @@
 
 # Configure libtool
 #AC_MSG_NOTICE([====== Starting libtool configuration])
-AC_LIBTOOL_DLOPEN
-AM_PROG_LIBTOOL
+LT_INIT([shared static win32-dll dlopen])
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
 #AC_MSG_NOTICE([====== Finished libtool configuration]) ; sleep 10
Index: libgfortran/Makefile.am
===================================================================
--- libgfortran/Makefile.am	(revision 127859)
+++ libgfortran/Makefile.am	(working copy)
@@ -15,7 +15,7 @@
 
 toolexeclib_LTLIBRARIES = libgfortran.la
 libgfortran_la_LINK = $(LINK)
-libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lm $(extra_ldflags_libgfortran) $(version_arg)
+libgfortran_la_LDFLAGS = -no-undefined -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lm $(extra_ldflags_libgfortran) $(version_arg)
 
 myexeclib_LTLIBRARIES = libgfortranbegin.la
 myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
Index: libgomp/configure.ac
===================================================================
--- libgomp/configure.ac	(revision 127859)
+++ libgomp/configure.ac	(working copy)
@@ -139,7 +139,7 @@
 
 
 # Configure libtool
-AM_PROG_LIBTOOL
+LT_INIT([shared static win32-dll dlopen])
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
 
Index: libgomp/Makefile.am
===================================================================
--- libgomp/Makefile.am	(revision 127859)
+++ libgomp/Makefile.am	(working copy)
@@ -29,7 +29,7 @@
 libgomp_version_script =
 endif
 libgomp_version_info = -version-info $(libtool_VERSION)
-libgomp_la_LDFLAGS = $(libgomp_version_info) $(libgomp_version_script)
+libgomp_la_LDFLAGS = -no-undefined $(libgomp_version_info) $(libgomp_version_script)
 
 libgomp_la_SOURCES = alloc.c barrier.c critical.c env.c error.c iter.c \
 	loop.c ordered.c parallel.c sections.c single.c team.c work.c \
Index: libssp/configure.ac
===================================================================
--- libssp/configure.ac	(revision 127859)
+++ libssp/configure.ac	(working copy)
@@ -130,7 +130,7 @@
 fi
 AC_SUBST(ssp_have_usable_vsnprintf)
 
-AM_PROG_LIBTOOL
+LT_INIT([shared static win32-dll dlopen])
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
 
Index: libssp/Makefile.am
===================================================================
--- libssp/Makefile.am	(revision 127859)
+++ libssp/Makefile.am	(working copy)
@@ -34,7 +34,8 @@
 	vsnprintf-chk.c vsprintf-chk.c
 libssp_la_LIBADD = 
 libssp_la_DEPENDENCIES = $(version_dep) $(libssp_la_LIBADD)
-libssp_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` \
+libssp_la_LDFLAGS = -no-undefined \
+		    -version-info `grep -v '^\#' $(srcdir)/libtool-version` \
 		    $(version_arg)
 
 libssp_nonshared_la_SOURCES = \
Index: libstdc++-v3/configure.ac
===================================================================
--- libstdc++-v3/configure.ac	(revision 127743)
+++ libstdc++-v3/configure.ac	(working copy)
@@ -82,8 +82,7 @@
 # up critical shell variables.
 GLIBCXX_CONFIGURE
 
-AC_LIBTOOL_DLOPEN
-AM_PROG_LIBTOOL
+LT_INIT([shared static win32-dll dlopen])
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
 
Index: libstdc++-v3/src/Makefile.am
===================================================================
--- libstdc++-v3/src/Makefile.am	(revision 127743)
+++ libstdc++-v3/src/Makefile.am	(working copy)
@@ -186,7 +186,7 @@
 libstdc___la_DEPENDENCIES = ${version_dep} $(libstdc___la_LIBADD)
 
 libstdc___la_LDFLAGS = \
-	-version-info $(libtool_VERSION) ${version_arg} -lm 
+	-no-undefined -version-info $(libtool_VERSION) ${version_arg} -lm 
 
 # Use special rules for the deprecated source files so that they find
 # deprecated include files.

Re: [patch,build] Build libgfortran and libgomp as DLL on win32

[Brian Dessent]

François-Xavier Coudert wrote:

> For symbol versioning, configure checks that -shared
> -Wl,--version-script is supported, and finds that it is. So, it's
> passed as linker flags (e.g.,
> -Wl,--version-script=$(srcdir)/gfortran.map). I don't know how to
> check the resulting DLL to see if symbol versioning is indeed present,
> but if you tell me how to do it, I will.

This seems wrong.  There is no such thing as symbol versioning on PE so
this test should fail.

> I think this is orthogonal to the shared runtime libraries support. By
> default, libgomp isn't built on mingw, but if you have a libpthread
> accessible, you can configure with --enable-libgomp. I do it with
> pthreads-win32, but it could be any pthreads library, really. In the
> case of pthreads-win32, they have a libpthread.a and a pthreadGC2.dll.
> Linking in libpthread.a creates a dependency on pthreadGC2.dll. From
> what I understand, a libgomp built with a given version of
> pthreads-win32 would work with any later version in the 2.x series,
> but it's probably safer to use the same version.

IMO the best user experience would be achieved by assuming the user has
pthreads-win32 and adding -lpthreadGC2 via the specs file when -fopenmp
is specified.  If the user doesn't have the pthread library installed
they get a link error, but that's better than the alternative where the
user has to specify "-fopenmp -lpthreadGC2".

> > If I understand the GPL correctly, if a user redistributes a binary that
> > depend on libgfortran.dll and so also redistribute the libgfortran.dll
> > library, the user must offer to supply source for the libgfortan.dll.
> > That is, the same rules apply to redistributing libgfortan.dll as
> > libgfortran.a
> > Is that correct?  That has been my answer when asked the question in the
> > past.
> 
> Well, I'm especially bad at this kind of things, but I suspect you're
> right. A readme.txt file in the directory containing the libgfortran
> DLL giving the URL for the library is probably a sufficient offer.

libgfortran and all the other target libraries have the exception clause
which is specificically there to prevent this situation:

> In addition to the permissions in the GNU General Public License, the
> Free Software Foundation gives you unlimited permission to link the
> compiled version of this file into combinations with other programs,
> and to distribute those combinations without any restriction coming
> from the use of this file.  (The General Public License restrictions
> do apply in other respects; for example, they cover modification of
> the file, and distribution when not linked into a combine
> executable.)

Just using a GPL toolchain should not affect the license of binaries it
creates.  Now I guess the question is whether this term "combinations
with other programs" means statically linking or creating a shared
library that is distributed alongside the app, but I'm pretty sure the
intention of the wording was always that simply building an app with gcc
(and thus linking to gcc runtimes) doesn't impose any license
requirements on that code.  Otherwise, it would be impossible to build
any non-GPL programs with gcc since everything links to at least libgcc.

On the topic of actually providing source or just giving a link in a
README, the latter is only allowed if the link is on the same site as
where the binary was downloaded from -- you can't say "source is at
gcc.gnu.org if you want it".  On the Cygwin list we regularly deal with
violations where people distribute an unmodified cygwin1.dll with their
app and shrug off the source, with perhaps a just a mention that it's
available at cygwin.com if they are interested.  But that's not
sufficient, they have to actually host the source tarball themselves at
the same download site.


> OK, well, I've expanded my patch to also allow building DLLs for
> libssp and libstdc++-v3. Please find attached the new patch and
> ChangeLog. Build maintainers, OK to commit?

I think this issue is a lot more involved than simply adding
-no-undefined.  What about __declspec(dllimport) in the libstdc++
headers?  Otherwise you rely on auto-import which has its own problems.

Brian

Re: [patch,build] Build libgfortran and libgomp as DLL on win32

[François-Xavier Coudert]

>> For symbol versioning, configure checks that -shared
>> -Wl,--version-script is supported, and finds that it is. So, it's
>> passed as linker flags (e.g.,
>> -Wl,--version-script=$(srcdir)/gfortran.map). I don't know how to
>> check the resulting DLL to see if symbol versioning is indeed present,
>> but if you tell me how to do it, I will.
>
> This seems wrong.  There is no such thing as symbol versioning on PE so
> this test should fail.

Well, maybe --version-script is a no-op, but it's accepted by the linker.

> IMO the best user experience would be achieved by assuming the user has
> pthreads-win32 and adding -lpthreadGC2 via the specs file when -fopenmp
> is specified.  If the user doesn't have the pthread library installed
> they get a link error, but that's better than the alternative where the
> user has to specify "-fopenmp -lpthreadGC2".

There is no need to use -lpthreadGC2: -fopenmp gives -lpthread to the
linker, and libpthread.a implies that pthreadGC2.dll comes into play.
You never have to specify -lpthreadGC2.

>> OK, well, I've expanded my patch to also allow building DLLs for
>> libssp and libstdc++-v3. Please find attached the new patch and
>> ChangeLog. Build maintainers, OK to commit?
>
> I think this issue is a lot more involved than simply adding
> -no-undefined.  What about __declspec(dllimport) in the libstdc++
> headers?  Otherwise you rely on auto-import which has its own problems.

OK, I then withdraw the updated patch. I'll let C++ or mingw
maintainers deal with it.

Thanks,
FX

RE: [patch,build] Build libgfortran and libgomp as DLL on win32

[Danny Smith]

 Brian Dessent
 Thursday, 30 August 2007 12:33 a.m.
> libgfortran and all the other target libraries have the 
> exception clause
> which is specificically there to prevent this situation:
> 
> > In addition to the permissions in the GNU General Public 
> License, the
> > Free Software Foundation gives you unlimited permission to link the
> > compiled version of this file into combinations with other programs,
> > and to distribute those combinations without any restriction coming
> > from the use of this file.  (The General Public License restrictions
> > do apply in other respects; for example, they cover modification of
> > the file, and distribution when not linked into a combine
> > executable.)
> 
> Just using a GPL toolchain should not affect the license of 
> binaries it
> creates.  Now I guess the question is whether this term "combinations
> with other programs" means statically linking or creating a shared
> library that is distributed alongside the app, but I'm pretty sure the
> intention of the wording was always that simply building an 
> app with gcc
> (and thus linking to gcc runtimes) doesn't impose any license
> requirements on that code.  Otherwise, it would be impossible to build
> any non-GPL programs with gcc since everything links to at 
> least libgcc.


Thats not what I suggested.  If I distribute a static libgfortran.a
binary to other people, I am required to provide the source for that
library.  Correct?  The library is not a "combined executable"	

Now, if  build libgfortran.dll from the same source and distribute it, I
would expect that the obligation to provide the source for libgfortan
still remains.  It is not a combined executable.  (Oh I suppose we could
be tricky and and say because we've added a DllMain to the library it
technically is a combined executable, but I don't buy that) If I don't
need to distribute libgfortran.dll (the user got it from mingw.org or
some other package), then, as per the exception, just linking against
the dll does not add a GPL obligation.

Anyway, until I am informed otherwise by the copyright holder, that is
what I go by

Danny

RE: [patch,build] Build libgfortran and libgomp as DLL on win32

[Danny Smith]

> 
> > For thread support you need to build dll with -mthreads
> 
> Hum, that one has me puzzled. The doc for this option says it's
> required for thread-safe exception handling: wouldn't you need it also
> for static libraries? In any case, I've looked and it's not currently
> used (well, it is implied by -fopenmp when compiling user code, but
> it's not used for compilation of our runtime libraries). Maybe this
> could be put into a toplevel config/mt-mingw file?

Dll most have all symbols defined  If you build dll without -mthreads
the dll will resolve the variable _CRT_MT to the one in the static
libmingw.a. The value of this  variable is 0, which means single thread.
This is turn makes _gthread_active_p return false within the dll, so yes
everything will work if you don't need thread support, but a
multithread app that uses the libgfortan random may randomly crash.


> 
> > I believe that shared runtime dll's also need to be built with
> > shared-libgcc.
> 
> Why? I did all my testing with a static libgcc, and it works fine.
> Even on other systems, you can use -static-libgcc with shared runtime
> libraries.

Shared libgcc is required if you want to follow Dwarf2 unwind info
across dll/exe boundaries. 

> 
> > How is dependency on pthread.dll handled for mingw? Do you 
> force use of
> > a specific version of the third-party prthreads-win32 dll?
> 
> I think this is orthogonal to the shared runtime libraries support. By
> default, libgomp isn't built on mingw, but if you have a libpthread
> accessible, you can configure with --enable-libgomp. I do it with
> pthreads-win32, but it could be any pthreads library, really. In the
> case of pthreads-win32, they have a libpthread.a and a pthreadGC2.dll.
> Linking in libpthread.a creates a dependency on pthreadGC2.dll. From
> what I understand, a libgomp built with a given version of
> pthreads-win32 would work with any later version in the 2.x series,
> but it's probably safer to use the same version.

If you build libgomp as dll, the dll will depend on the specific pthread
dll that you name at dll-build time. The user must have a dll with at
least the same name in PATH

-lpthread will only imply pthreadGC2.dll if you rename libpthreadGC2.a
to libpthread.a

> 
> 
> OK, well, I've expanded my patch to also allow building DLLs for
> libssp and libstdc++-v3. Please find attached the new patch and
> ChangeLog.


You really do need to run these things through a testsuite. 
libstdc++.dll will not work for anything that reguires typeinfo as you
build it. 

Danny

 Build maintainers, OK to commit?
> 
> FX
>