Fwd: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

Fwd: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[FX]

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

I'm forwarding this to the generic GCC development list, as more  
people might be of help there (including the darwin maintainers), as  
it's more of a darwin and build system issue.

FX


Début du message réexpédié :

> De : IainS <developer@sandoe-acoustics.co.uk>
> Date : 10 juin 2008 16:50:11 GMT+01:00
> À : Fortran List <fortran@gcc.gnu.org>
> Objet : [RFC, Patch, gfortran] make -static-libgfortran work on  
> darwin.
>
> The current implementation of -static-libgfortran has no effect on  
> darwin{8,9}
> [http://gcc.gnu.org/ml/fortran/2008-05/msg00365.html, http:// 
> gcc.gnu.org/ml/fortran/2008-06/msg00017.html ]
>
> Linking a static ".a" lib works fine on the platform.  However,  
> since the vendor doesn't provide a (userland) static system  
> library, it seems that collect2 must always be invoked with '- 
> dynamic' when building an executable.   [neglecting the special  
> case of kernel extensions].
>
> --
>
> The current '-static-libgfortran' implementation has the same  
> basename for the static and dynamic library versions, and "- 
> dynamic" is invoked by collect2.
>
> according to the (darwin8) ld man page:
> "-lx    This  option  is  an abbreviation for the library name  
> `libx.a',  where x is a string.  If -dynamic is specified the   
> abbreviation
>               for  the  library  name is first search as  
> `libx.dylib' and then `libx.a' is searched for."
>
> The man page for ld(64) on darwin9 is less categorical on the  
> subject - but it seems that the behavior is the same on 9.
>
> -----
> The solution is to name the libs differently (as is done elsewhere  
> in gcc).
>
> Even though this appears to be a simple issue, I don't know my way  
> around the gcc tree/build system very well...
> so I find it difficult to forecast if these proposed changes would  
> impact elsewhere.
>
> ==== proposed changes.
>
> I opted to call the static library "libgfortran_static" and to  
> leave the shared name unchanged.
>
> It would be great if libtool could be persuaded to change the  
> basename as well as the extension for the dynamic/static
> but despite RTFM and googling I can't seem to find any example of  
> how to achieve that in an easy manner.
> ====
>
> Patch1 modifies gfortranspec.c to use different lib names.
>
> It is possible to accommodate the required lib name change at  
> install time by renaming libgfortran.a and ranlib-ing the new one.
> however, I decided to leave the existing lib alone - and generate  
> what was wanted explicitly.
>
> Patch2  modifies the libgfortran/Makefile.am to generate a  
> libgfortran_static.
>
> ====
> regtested on powerpc-apple-darwin8 (m32)
>
> however, I'm not sure how to make a formal test case for the change:
> ...  since to prove that the static lib has been used requires  
> inspection of the generated executable.
>
> [ if you tested the current implementation then  "-static- 
> libgfortran" would compile and execute perfectly OK
> .... but the actual library being used would be libgfortran.3.dylib ]
>
> ====
>
> These are against 4.4.0/trunk - although pretty much the same  
> should be OK on 4.3.x
>
> Hopefully, at least this will start the ball rolling.
> Iain
>
>

[-- Attachment #2: gfortranspec.diff --]
[-- Type: application/octet-stream, Size: 3410 bytes --]

Index: gcc/fortran/gfortranspec.c
===================================================================
--- gcc/fortran/gfortranspec.c	(revision 136591)
+++ gcc/fortran/gfortranspec.c	(working copy)
@@ -62,21 +62,36 @@
 #define FORTRAN_INIT "-lgfortranbegin"
 #endif
 
-#ifndef FORTRAN_LIBRARY
-#define FORTRAN_LIBRARY "-lgfortran"
+#ifndef FORTRAN_SHARED_LIBRARY
+#define FORTRAN_SHARED_LIBRARY "-lgfortran"
 #endif
 
+#ifndef FORTRAN_STATIC_LIBRARY
+#define FORTRAN_STATIC_LIBRARY "-lgfortran_static"
+#endif
+
 #ifdef HAVE_LD_STATIC_DYNAMIC
-#define ADD_ARG_LIBGFORTRAN(arg) \
+#define ADD_ARG_LIBGFORTRAN \
   { \
-    if (static_lib && !static_linking) \
-      append_arg ("-Wl,-Bstatic"); \
-    append_arg (arg); \
-    if (static_lib && !static_linking) \
-      append_arg ("-Wl,-Bdynamic"); \
+  	if (static_lib) \
+  	  { \
+  	    if (!static_linking) append_arg ("-Wl,-Bstatic"); \
+  	  	append_arg(FORTRAN_STATIC_LIBRARY) ; \
+  	    if (!static_linking) append_arg ("-Wl,-Bdynamic"); \
+  	  } \
+  	else \
+  	  { \
+  	  	append_arg(FORTRAN_SHARED_LIBRARY) ; \
+  	  } \
   }
 #else
-#define ADD_ARG_LIBGFORTRAN(arg) append_arg (arg);
+#define ADD_ARG_LIBGFORTRAN \
+  { \
+  	if (static_lib) \
+      append_arg(FORTRAN_STATIC_LIBRARY) ; \
+  	else \
+      append_arg(FORTRAN_SHARED_LIBRARY) ; \
+  }
 #endif
 
 
@@ -265,9 +280,9 @@
   int skip;
   const char *arg;
 
-  /* This will be NULL if we encounter a situation where we should not
-     link in libf2c.  */
-  const char *library = FORTRAN_LIBRARY;
+  /* 0 => don't link libgfortran etc.
+     1 => link libgfortran version as determined by static_lib */
+  int should_link_libs = 1;
 
   /* 0 => -xnone in effect.
      1 => -xfoo in effect.  */
@@ -346,7 +361,7 @@
 	case OPTION_E:
 	  /* These options disable linking entirely or linking of the
 	     standard libraries.  */
-	  library = 0;
+	  should_link_libs = 0;
 	  break;
 
 	case OPTION_static_libgfortran:
@@ -411,7 +426,7 @@
 
   /* If there are no input files, no need for the library.  */
   if (n_infiles == 0)
-    library = 0;
+    should_link_libs = 0;
 
   /* Second pass through arglist, transforming arguments as appropriate.  */
 
@@ -511,15 +526,23 @@
 		      use_init = 1;
 		    }
 
-		  ADD_ARG_LIBGFORTRAN (FORTRAN_LIBRARY);
+		  ADD_ARG_LIBGFORTRAN ;
 		}
 	    }
-	  else if (strcmp (argv[i], FORTRAN_LIBRARY) == 0)
+	  else if (strcmp (argv[i], FORTRAN_SHARED_LIBRARY) == 0)
 	    {
 	      saw_library = 1;	/* -l<library>.  */
-	      ADD_ARG_LIBGFORTRAN (argv[i]);
+	      static_lib = 0 ;
+	      ADD_ARG_LIBGFORTRAN ;
 	      continue;
 	    }
+	  else if (strcmp (argv[i], FORTRAN_STATIC_LIBRARY) == 0)
+	    {
+	      saw_library = 1;	/* -l<library>.  */
+	      static_lib = 1 ;
+	      ADD_ARG_LIBGFORTRAN;
+	      continue;
+	    }
 	  else
 	    {			/* Other library, or filename.  */
 	      if (saw_library == 1 && need_math)
@@ -532,7 +555,7 @@
 
   /* Append `-lg2c -lm' as necessary.  */
 
-  if (library)
+  if (should_link_libs)
     {				/* Doing a link and no -nostdlib.  */
       if (saw_speclang)
 	append_arg ("-xnone");
@@ -545,7 +568,7 @@
 	      append_arg (FORTRAN_INIT);
 	      use_init = 1;
 	    }
-	  ADD_ARG_LIBGFORTRAN (library);
+	  ADD_ARG_LIBGFORTRAN ;
 	  /* Fall through.  */
 
 	case 1:
@@ -557,7 +580,7 @@
     }
 
 #ifdef ENABLE_SHARED_LIBGCC
-  if (library)
+  if (should_link_libs)
     {
       int i;
 

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

>
>

[-- Attachment #4: libgf-makefile-am.diff --]
[-- Type: application/octet-stream, Size: 1167 bytes --]

Index: libgfortran/Makefile.am
===================================================================
--- libgfortran/Makefile.am	(revision 136591)
+++ libgfortran/Makefile.am	(working copy)
@@ -19,11 +19,13 @@
 libgfortran_la_LINK = $(LINK)
 libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LTLDFLAGS) -lm $(extra_ldflags_libgfortran) $(version_arg)
 
-myexeclib_LTLIBRARIES = libgfortranbegin.la
+myexeclib_LTLIBRARIES = libgfortranbegin.la libgfortran_static.la
 myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
 libgfortranbegin_la_SOURCES = fmain.c
 libgfortranbegin_la_LDFLAGS = -static
 
+libgfortran_static_la_LDFLAGS = -static
+
 ## io.h conflicts with a system header on some platforms, so
 ## use -iquote
 AM_CPPFLAGS = -iquote$(srcdir)/io -I$(srcdir)/$(MULTISRCTOP)../gcc \
@@ -742,9 +744,11 @@
 #	$(LTPPFCCOMPILE) -c -o $@ $^ -combine
 
 libgfortran_la_SOURCES = libgfortran_c.c $(filter-out %.c,$(prereq_SRC))
+libgfortran_static_la_SOURCES = libgfortran_c.c $(filter-out %.c,$(prereq_SRC))
 
 else
 libgfortran_la_SOURCES = $(prereq_SRC)
+libgfortran_static_la_SOURCES = $(prereq_SRC)
 
 endif
 

[-- Attachment #5: Type: text/plain, Size: 82 bytes --]

>
>

-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Fwd: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[Ralf Wildenhues]

Hello,

* FX wrote on Tue, Jun 10, 2008 at 05:59:36PM CEST:
>> De : IainS <developer@sandoe-acoustics.co.uk>
>>
>> I opted to call the static library "libgfortran_static" and to leave 
>> the shared name unchanged.
>>
>> It would be great if libtool could be persuaded to change the basename 
>> as well as the extension for the dynamic/static
>> but despite RTFM and googling I can't seem to find any example of how 
>> to achieve that in an easy manner.

It doesn't do that because that breaks the abstraction.  It might also
increase a bit the risk of ending up with bits of the static library
included, and bits of shared deplibs you use pulling in the shared
version of the library.

Can the driver use path/to/libgfortran.a instead of '-Lpath/to
-lgfortran' to avoid being hindered by missing -Bstatic/-Bdynamic?

Independently, does anybody know whether odcctools is dead (homepage
seems to be down ATM)?
<http://thread.gmane.org/gmane.comp.gnu.libtool.general/7158/focus=7173>

>> It is possible to accommodate the required lib name change at install
>> time by renaming libgfortran.a and ranlib-ing the new one.

Don't try this on AIX, where libtool may create a shared archive with
that name.

>> however, I'm not sure how to make a formal test case for the change:
>> ...  since to prove that the static lib has been used requires
>> inspection of the generated executable.

This is what we use within the libtool testsuite (not fool-proof!):
- remove the shared library before running the executable.

To make it a bit more fool-proof:
- after generating the executable, create an incompatible shared
  library, install it in some temporary directory, let that directory
  be searched early by the runtime linker.

Not sure what level of overkill is suitable for GCC.  ;-)


I agree with FX that it would be nice to limit a change to Darwin if at
all.

Cheers,
Ralf

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[IainS]

On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:

> Hello,
>
> * FX wrote on Tue, Jun 10, 2008 at 05:59:36PM CEST:
>>> De : IainS <developer@sandoe-acoustics.co.uk>
>>>
>>> I opted to call the static library "libgfortran_static" and to leave
>>> the shared name unchanged.
>>>
>>> It would be great if libtool could be persuaded to change the  
>>> basename
>>> as well as the extension for the dynamic/static
>>> but despite RTFM and googling I can't seem to find any example of  
>>> how
>>> to achieve that in an easy manner.
>
> It doesn't do that because that breaks the abstraction.  It might also
> increase a bit the risk of ending up with bits of the static library
> included, and bits of shared deplibs you use pulling in the shared
> version of the library.

OK, I appreciate the first part;
I don't immediately understand how  libfoo-static.a  is any more  
dangerous than libfoo.a
or libfoo-s.dylib ....  libfoo.so

> Can the driver use path/to/libgfortran.a instead of '-Lpath/to
> -lgfortran' to avoid being hindered by missing -Bstatic/-Bdynamic?

this doesn't appear to work. [I've unset DYLD_LIBRARY_PATH in the  
following]

  ./dst-powerpc/usr/bin/gfortran-4.4.0 helloi.F90 /Volumes/UFSScratch/ 
GCC/gcc-44-build/dst-powerpc/usr/lib/gcc/powerpc-apple-darwin8/4.4.0/ 
libgfortran.a -o helloif

thor:/Volumes/UFSScratch/GCC/gcc-44-build $ ./helloif

dyld: Library not loaded: /usr/lib/gcc/powerpc-apple-darwin8/4.4.0/ 
libgfortran.3.dylib
   Referenced from: /Volumes/UFSScratch/GCC/gcc-44-build/./helloif
   Reason: image not found
Trace/BPT trap

it appears to be ignoring my directly-specified library and linking  
in the dynamic one anyway.

we could campaign for a different linker on OSX/Darwin I guess...
... but it seems that ld64 is the vendor's preferred solution (given  
the publicly released source for 10.5)

> Independently, does anybody know whether odcctools is dead (homepage
> seems to be down ATM)?
> <http://thread.gmane.org/gmane.comp.gnu.libtool.general/7158/ 
> focus=7173>

macports does install this; although it doesn't understand m64 mach-o  
(at least objdump doesn't)
The difficulty becomes that one cannot supply something that is  
compatible with the vendor's standard installation.

We start to require that the end user has administration rights to  
install into /usr simply in order to run a program?

>>> It is possible to accommodate the required lib name change at  
>>> install
>>> time by renaming libgfortran.a and ranlib-ing the new one.
>
> Don't try this on AIX, where libtool may create a shared archive with
> that name.

OK. - so the solution as I have it is in the right direction...  (bar  
removing the extra static lib).

> I agree with FX that it would be nice to limit a change to Darwin  
> if at
> all.

-static-libgcc works on darwin.
it's accommodated by different libnames.
I don't know if that change extends to other triplets - at present I  
only have OSX machines to hand.

> Cheers,
> Ralf

thanks for your responses,
Iain

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[Ralf Wildenhues]

* IainS wrote on Tue, Jun 10, 2008 at 09:42:29PM CEST:
> On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:
>
>> Can the driver use path/to/libgfortran.a instead of '-Lpath/to
>> -lgfortran' to avoid being hindered by missing -Bstatic/-Bdynamic?
>
> this doesn't appear to work. [I've unset DYLD_LIBRARY_PATH in the  
> following]
>
>  ./dst-powerpc/usr/bin/gfortran-4.4.0 helloi.F90 /Volumes/UFSScratch/ 
> GCC/gcc-44-build/dst-powerpc/usr/lib/gcc/powerpc-apple-darwin8/4.4.0/ 
> libgfortran.a -o helloif

Well, what I meant was that on Dargin, gfortran could pass the argument
  path/to/libgfortran.a

to collect2, instead of passing
  -Bstatic -lgfortran -Bdynamic

or the like, not that you should pass it on the command line.

> we could campaign for a different linker on OSX/Darwin I guess...

What's the problem with just using the shared library?
(Yeah, I knew that question was naive ... but hey, it works ;-)

>> Independently, does anybody know whether odcctools is dead (homepage
>> seems to be down ATM)?
>> <http://thread.gmane.org/gmane.comp.gnu.libtool.general/7158/ 
>> focus=7173>
>
> macports does install this; although it doesn't understand m64 mach-o  
> (at least objdump doesn't)

Bummer.

> The difficulty becomes that one cannot supply something that is  
> compatible with the vendor's standard installation.

Did you mean "incompatible" here?

> We start to require that the end user has administration rights to  
> install into /usr simply in order to run a program?

I'm not sure whether I understand this comment.  Isn't the link-time
location of a shared library added to the search path anyway?
(My experience with darwin is quite limited, so my memory may serve
me wrong here.)

Cheers,
Ralf

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[IainS]

On 10 Jun 2008, at 20:58, Ralf Wildenhues wrote:

> * IainS wrote on Tue, Jun 10, 2008 at 09:42:29PM CEST:
>> On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:
>>
>>> Can the driver use path/to/libgfortran.a instead of '-Lpath/to
>>> -lgfortran' to avoid being hindered by missing -Bstatic/-Bdynamic?
>>
>> this doesn't appear to work. [I've unset DYLD_LIBRARY_PATH in the
>> following]
>>
>>  ./dst-powerpc/usr/bin/gfortran-4.4.0 helloi.F90 /Volumes/UFSScratch/
>> GCC/gcc-44-build/dst-powerpc/usr/lib/gcc/powerpc-apple-darwin8/4.4.0/
>> libgfortran.a -o helloif
>
> Well, what I meant was that on Dargin, gfortran could pass the  
> argument
>   path/to/libgfortran.a
>
> to collect2, instead of passing
>   -Bstatic -lgfortran -Bdynamic

I guess.. [I'll have to try this another day ]
you can do "-nodefaultlibs" and then specify all the libs by hand.   
That works (I originally did this).
It seems then that the driver has to replicate the multilibs stuff...

I'm not sure that it would produce less darwin-specific code than  
renaming the lib.

>> we could campaign for a different linker on OSX/Darwin I guess...
>
> What's the problem with just using the shared library?
> (Yeah, I knew that question was naive ... but hey, it works ;-)

I'm also happy to file a radar for missing Bstatic/Bdynamic.

>> We start to require that the end user has administration rights to
>> install into /usr simply in order to run a program?
>
> I'm not sure whether I understand this comment.  Isn't the link-time
> location of a shared library added to the search path anyway?
> (My experience with darwin is quite limited, so my memory may serve
> me wrong here.)

fortran is not part of any standard installation on OSX (yet..., of  
course, that could change).
On darwin 8 the gcc version is 4.0.1
I don't know whether the 4.2.1 version [from darwin 9] will be  
officially released
...  I've back-ported it (but, that's not an end-user thing)

if you want to deliver any different you have to choose
(a) the end user must install with admin rights  [to put stuff in / 
usr etc.]
(b) static linking of the missing bits

(b) is a lot simpler for me...

ttfn,
Iain

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[Peter O'Gorman]

Ralf Wildenhues wrote:

>>> Independently, does anybody know whether odcctools is dead (homepage
>>> seems to be down ATM)?

odcctools is currently seeking a maintainer.

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[Ralf Wildenhues]

We're getting a bit off-list; if this loses connection to GCC we may
want to move to libtool@gnu.org.

* IainS wrote on Tue, Jun 10, 2008 at 09:42:29PM CEST:
> On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:
>>
>> It doesn't do that because that breaks the abstraction.  It might also
>> increase a bit the risk of ending up with bits of the static library
>> included, and bits of shared deplibs you use pulling in the shared
>> version of the library.
>
> OK, I appreciate the first part;
> I don't immediately understand how  libfoo-static.a  is any more  
> dangerous than libfoo.a
> or libfoo-s.dylib ....  libfoo.so

Well, it's certainly not more or less dangerous than libfoo-s.dylib vs.
libfoo.so.  However, it's more dangerous than libfoo.a vs libfoo.so.
For one, because usually libtool will uniquify listing identical -lfoo
on the command line.

> OK. - so the solution as I have it is in the right direction...  (bar  
> removing the extra static lib).

BTW, if it's decided to be like that: you can avoid bulding an extra
lib_LTLIBRARIES on systems other than darwin by using 
  lib_LTLIBRARIES += ...
inside of an automake conditional.

Cheers,
Ralf

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[FX]

> The solution is to name the libs differently (as is done elsewhere  
> in gcc).

Target libraries named differently? Which? libssp has three variants,  
which I don't really understand :)

$ ls libssp*
libssp.0.dylib      libssp.dylib        libssp_nonshared.a
libssp.a            libssp.la           libssp_nonshared.la

libgomp has shared and static libraries with the same name:

$ ls libgomp.*
libgomp.1.dylib libgomp.a       libgomp.dylib   libgomp.la       
libgomp.spec

Only libstdc++ has the naming patter you mention, as far as I can tell:

$ ls libstdc++*
libstdc++-static.a    libstdc++.6.0.4.dylib libstdc++.6.dylib

> I opted to call the static library "libgfortran_static" and to  
> leave the shared name unchanged.

I'd suggest "-static" instead of using an underscore, to follow  
libstdc++, but that's a minor point.


But more fundamentally, what is the reason that the linker can't be  
persuaded to link a static library instead of a shared one? The  
reason for that is that for darwin hosts, HAVE_LD_STATIC_DYNAMIC is  
not defined. The description for that macro is "Define if your linker  
supports -Bstatic/-Bdynamic option.". So, is there a way Darwin way  
to achieve the same goal (according to my googling, there isn't, but  
I might have missed something).

Otherwise, wrt your patch: doesn't it create three libraries:  
libgfortran.dylib, libgfortran.a and libgfortran_static.a? And, what  
happens now if you do a -static compilation, does it pick  
libgfortran_static automagically? Shouldn't we make that darwin- 
specific, in order to not change the situation on the majority of  
other systems that don't have a problem with the current situation?

Thanks,
FX

-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[IainS]

On 10 Jun 2008, at 17:11, FX wrote:

>> I opted to call the static library "libgfortran_static" and to  
>> leave the shared name unchanged.
>
> I'd suggest "-static" instead of using an underscore, to follow  
> libstdc++, but that's a minor point.

A minor point maybe, but, as you say, there seem to be several  
different schemes in use... a source of confusion for me whilst  
trying to figure out how to do this.

I was almost going to rename the shared one _s (as per libgcc) :-)

j/k aside is there a convention ?

I don't mind (I prefer '-' to '_' personally;    '_static'  and  
'_kext' were used in the 4.0.1 vendor release for darwin8).

> Otherwise, wrt your patch: doesn't it create three libraries:  
> libgfortran.dylib, libgfortran.a and libgfortran_static.a? And,  
> what happens now if you do a -static compilation, does it pick  
> libgfortran_static automagically? Shouldn't we make that darwin- 
> specific, in order to not change the situation on the majority of  
> other systems that don't have a problem with the current situation?

Yes, it does make three libs - only a temporary measure to avoid  
treading on anyone else whilst testing (see below).

The "-static-libgfortran" option causes it to pick up the _static  
version  (patch to gfortranspec.c).

AFAIK there is no point in doing a "-static" link on darwin [crt0 is  
not present] (unless you're making a kernel extension).
However, the proposed change makes no difference to what will happen  
if you do.

You are right;  of course, it should be darwin-specific (and only  
build the required libs per system)
-  but I am not familiar enough with the build process to know how  
best to achieve that... suggestions welcome.

Iain

RE: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[Dave Korn]

FX wrote on 10 June 2008 17:12:

>> The solution is to name the libs differently (as is done elsewhere
>> in gcc).
> 
> Target libraries named differently? Which? 

  Just frex:  When you build static libgcc, you get libgcc.a

  When you build it shared, you get libgcc_s.so (and a static libgcc_eh.a,
for reasons we won't go into here).


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....