Added mail directory.

CVS:
CVS:

13 files changed, 3365 insertions, 0 deletions

diff --git a/mail/aix b/mail/aix
new file mode 100644
index 00000000..98d9d453
--- /dev/null
+++ b/mail/aix
@@ -0,0 +1,104 @@
+From nobody Wed Oct 14 16:56:33 1998
+X-From-Line: gord@gnu.org Thu Aug 06 20:23:55 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 1251 invoked from network); 6 Aug 1998 20:23:54 -0000
+Received: from gen2-93ip34.cadvision.com (HELO bambam.m-tech.ab.ca) (209.91.93.34)
+  by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 6 Aug 1998 20:23:54 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id OAA21853 for <gord@m-tech.ab.ca>; Thu, 6 Aug 1998 14:21:27 -0600
+Received: from juliet.wcom.com by mescaline.gnu.org (8.8.5/8.6.12GNU) with SMTP id QAA20365 for <bug-libtool@gnu.org>; Thu, 6 Aug 1998 16:21:44 -0400
+Received: from moloko.wcom.com by juliet with ESMTP; Thu, 6 Aug 1998 15:17:19 -0500
+Received: from pinebilly.wcom.com (pinebilly.wcom.com [159.98.206.11])	by moloko.wcom.com (8.8.8/8.8.8) 
+          with SMTP id PAA27920	for <bug-libtool@gnu.org>; Thu, 6 Aug 1998 15:17:18 -0500 (CDT)
+X-Report-Problems-With-Moloko-To: brandon.black@wcom.com
+X-If-you-can-read-this-you-are-too-close: :)
+Date: Thu, 6 Aug 1998 15:17:11 -0500 (CDT)
+From: Ron Romero <ron.romero@wcom.com>
+Sender: rdromero@pinebilly.wcom.com
+Reply-To: ron.romero@wcom.com
+To: bug-libtool@gnu.org
+Subject: libtool Doesn't Export C++ Methods on AIX
+Message-ID: <Pine.A41.3.96.980806150532.36284A-100000@pinebilly.wcom.com>
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+Lines: 26
+Xref: trick.fig.org libtool:1552
+
+I'm trying to use libtool with C++ programs, and found that libtool
+wouldn't put any C++ methods into the shared library.  When I looked
+into it, I found that the nm command used to create the export list
+doesn't pass a -C flag.  On AIX, the -C flag says to leave C++ names
+mangled.  Since the function names weren't mangled, the sed line
+didn't recognize them as functions, so they weren't put into the .exp
+file.  I found that I could fix the problem by adding a -C flag to
+ac_cv_path_NM in config.guess.  I suppose the configure script should
+check for that and do it automatically.
+
+I'm running libtool version 1.2 on an AIX 4.2 box
+(powerpc-ibm-aix4.2.1.0).  
+
+I have some test files that I can give to anyone who wants to test
+this.  And I can test potential fixes on my machine.
+
+
+Thank you,
+
+Ron Romero
+ron.romero@wcom.com
+Object Developer
+WorldCom, Inc.
+
+
+
+From nobody Wed Oct 14 16:56:35 1998
+X-From-Line: gord@gnu.org Wed Jul 01 21:42:48 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 509 invoked from network); 1 Jul 1998 21:42:47 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 1 Jul 1998 21:42:47 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id OAA10874 for <gord@m-tech.ab.ca>; Wed, 1 Jul 1998 14:37:31 -0600
+Received: from tweedledumb.cygnus.com by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id QAA11117 for <bug-libtool@gnu.org>; Wed, 1 Jul 1998 16:44:46 -0400
+Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
+	by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id QAA29302
+	for <bug-libtool@gnu.org>; Wed, 1 Jul 1998 16:44:31 -0400 (EDT)
+Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id QAA25589; Wed, 1 Jul 1998 16:44:31 -0400
+Date: Wed, 1 Jul 1998 16:44:31 -0400
+Message-Id: <199807012044.QAA25589@subrogation.cygnus.com>
+From: Ian Lance Taylor <ian@cygnus.com>
+To: bug-libtool@gnu.org
+Subject: libtool on AIX with GNU ld
+Lines: 31
+Xref: trick.fig.org mail.libtool:1513
+
+libtool messes up on AIX when using GNU ld.  It doesn't set
+archive_cmds to anything useful.
+
+Here is a hack patch.  This should be fixed in a better way.  For one
+thing, GNU ld supports the -unix option to export all symbols, so the
+stuff using nm is probably not necessary.
+
+Ian
+
+Index: ltconfig.in
+===================================================================
+RCS file: /cvs/cvsfiles/devo/libtool/ltconfig.in,v
+retrieving revision 1.13
+diff -u -r1.13 ltconfig.in
+--- ltconfig.in	1998/05/28 23:06:07	1.13
++++ ltconfig.in	1998/07/01 20:28:50
+@@ -770,6 +770,13 @@
+ runpath_var=
+ fix_srcfile_path=
+ 
++case "$host_os" in
++aix3* | aix4*)
++  # On AIX, the GNU linker works like the native linker.
++  with_gnu_ld=no
++  ;;
++esac
++
+ ld_shlibs=yes
+ if test "$with_gnu_ld" = yes; then
+ 
+
diff --git a/mail/amiga b/mail/amiga
new file mode 100644
index 00000000..0e28c47c
--- /dev/null
+++ b/mail/amiga
@@ -0,0 +1,339 @@
+From nobody Sun Dec 14 10:48:09 1997
+X-From-Line: JoopvandeWege@mococo.nl Wed Dec 03 04:15:19 1997
+Return-Path: <JoopvandeWege@mococo.nl>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 1795 invoked from network); 3 Dec 1997 04:15:16 -0000
+Received: from localhost (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by localhost with SMTP; 3 Dec 1997 04:15:16 -0000
+Received: from mcc-server.mococo.nl (mail.mococo.nl [195.193.4.2]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with SMTP id GAA28567 for <gord@m-tech.ab.ca>; Tue, 2 Dec 1997 06:06:47 -0700
+Received: from laptop.mococo.nl (unverified [195.193.4.9]) by mcc-server.mococo.nl
+ (EMWAC SMTPRS 0.83) with SMTP id <B0000011089@mcc-server.mococo.nl>;
+ Tue, 02 Dec 1997 14:06:15 +0100
+Date: Tue, 02 Dec 1997 14:06:15 +0100
+Message-ID: <B0000011089@mcc-server.mococo.nl>
+From: Joop van de Wege <JoopvandeWege@mococo.nl>
+To: Gordon Matzigkeit <gord@m-tech.ab.ca>
+Subject: Re: AmigaOS libtool port
+In-Reply-To: <86oh339y7g.fsf@trick.profitpress.com>
+References: <86oh339y7g.fsf@trick.profitpress.com>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=US-ASCII
+Content-Transfer-Encoding: 7bit
+X-Mailer: Becky! ver 1.23
+Lines: 177
+Xref: trick.profitpress.com mail.libtool:816
+
+
+
+On 29 Nov 1997 14:39:31 -0700
+Gordon Matzigkeit <gord@m-tech.ab.ca> wrote:
+
+> Hi!
+> 
+> libtool-1.0g contains some preliminary AmigaOS support.  It is a
+> little different than the patches you sent me, simply because I
+> modified libtool slightly so that it would better accomodate your
+> changes.
+> 
+> Here are what I consider to be some unresolved issues:
+> 
+> * I have attempted to automatically generate $objdir/a2ixlibrary.data,
+> just as the OS/2 port does with $objdir/$libname.def.  It currently
+> looks like this:
+> 
+> #define NAME $libname
+> #define LIBRARY_ID 1
+> #define VERSION $major
+> #define REVISION $revision
+> 
+> So, for libhello.la in the libtool distribution, this would make an
+> a2ixlibrary.data that looks like:
+> 
+> #define NAME libhello
+> #define LIBRARY_ID 1
+> #define VERSION 2
+> #define REVISION 12
+> 
+> Is that alright?  My concerns are for the NAME definition, and the
+> LIBRARY_ID, as I don't know what is valid, or what they are used
+> for.
+I have done this also but removed it because there are indeed two
+problem. The NAME should be 'hello' but this can be solved but the
+second issue is not so easy. LIBRARY_ID is a uniquely assign number
+which needs to be different for each .ixlibrary build. The developer of
+the ixlibrary is maintaining a database of which numbers are assign to
+which library. Everything below 10 can be used for locally build
+libraries, thats why I used 1.
+So it is specific to the Amiga but it looks like overkill to me to
+include the whole list into Libtool (about 50 entries right now).
+
+> 
+> * What does `assign libs: SOMEDIR [add|remove]' do, exactly?  Is it
+> something like `ldconfig'?  If so, then we should do something cleaner
+> than in your current patch: it doesn't belong in archive_cmds or
+> finish_cmds, it belongs in the generated executable wrapper.
+Yes, it does something like ldconfig. I followed that thread about it
+and its very similar but also has some differences.
+LIBS: is a logical directory where all libraries are, but that doesn't
+mean that they reside physically in the same directory on disk.
+It is a way of telling the OS where to look when a program requests a
+library, something along these lines:
+main()
+{
+	GfxBase=OpenLibrary("graphics.library",37L);
+	HelloBase=OpenLibrary("libhello.ixlibrary",3L);
+}
+
+Graphics.library is in ROM and will just have its open count incremented
+but nothing else will happen. libhello.ixlibrary is loaded from disk if
+it isn't already in memory, but one needs to tell the system where to
+load it from. It will look in SYS:libs (another logical device (normally
+the boot partition ~= /usr ) containing a libs directory) but it is
+possible to add directories to this logical assignment with 'assign',
+like this:
+assign SOMEDIR LIBS: add
+or remove them like this:
+assign SOMEDIR LIBS: remove
+SOMEDIR is composed of DRIVE+DIRECTORY (absolute) or DIRECTORY
+(relative) from where the assign is executed.
+The reason I used the assignment was because 'make check' didn't work
+correctly because libhello.ixlibrary is generated in .libs which is not
+where 'hell' is started from. The system looks in the current directory
+for .libraries but I'm not sure about .ixlibraries. The alternative was
+to install them first before 'make check'. Bad idea.
+The assignment is not placed into a config file or so. The next reboot
+will destroy it, no ld.so.conf.
+
+Probably you're now more confused then ever :)
+
+
+> * I suspect you don't know what I mean by `hardcoding' a library
+> directory, so I've interpreted your patch, and come up with hardcode_*
+> settings that I believe will work.  We need to test that, during the
+> next release.
+I have already merged most things into lt-1.0h but I'm short on freetime
+this week. I hope to have a couple of hours but it could be that I can
+do only some work during the weekend.
+
+
+> * Could you please tell me more about the AmigaOS requirements?  Some
+> of your patch is impossible for me to decipher, because I have no idea
+> what you want to accomplish, and I don't think you're taking full
+> advantage of libtool's internal conventions.
+> 
+> In plain language, what are the answers to the following questions:
+> 
+> * What exactly are `$libname_ixlibrary.a', `$libname.ixlibrary', and
+> `$libname.a'?  Is `$libname.a' the same file and installed in the same
+> place when building static libraries?
+Just in case I don't manage to make this clear. Have a look at the
+readme of the following archive (and maybe the rest of it aswell:
+ftp://ftp.ninemoons.com/pub/geekgadgets/971125/amiga-src/a2ixlibrary-2.0-src.tgz
+(35Kb)
+
+Dynamic libraries on the Amiga (in short)
+first compile all object with the following additional CFLAGS:
+-resident32 -malways-restore-a4 (these are the safest, -resident and
+-m...restore.. can also be use but then certain limitations and
+restrictions are  imposed)
+AR and RANLIB these into libNAME.a (-->$libname.a)
+run a2ixlibrary on libNAME.a --> $libname_ixlibrary.a and $libname.ixlibrary
+where _ixlibrary.a contains stubs and .ixlibrary contains the real code.
+(NAME.h and NAME.x are also generated and automatically installed by
+a2ixlibrary and are used by collect2)
+libNAME.a can be discarded after running a2ixlibrary.
+libNAME_ixlibrary.a gets installed in /usr/lib together with all the
+other linker libraries.
+libNAME.ixlibrary should be installed somewhere in a directory belonging
+to LIBS: There is a subdirectory in /gg where the gnu-tools are
+installed called sys/libs which should be used for this, prevents
+cluttering the main libs directories.
+
+Static libraries on the Amiga:
+compile all objects with the CFLAGS of your choice
+AR and RANLIB these into libNAME.a
+install in /usr/lib
+done.
+
+> 
+> * How are each of them generated?
+> 
+> * Where do they need to be installed?
+Answered above, I hope.
+> 
+> * `shlibpath_var' is the name of the runtime library search path
+> environment variable.  On Linux, it is `LD_LIBRARY_PATH'.  So, if you
+> install libhello.so in /home/gord/lib, binaries won't be able to
+> execute unless you set `LD_LIBRARY_PATH=/home/gord/lib' before running
+> them.  Is there an equivalent variable under AmigaOS?
+Assign LIBS: home:gord/lib add
+Nope, ':' is NOT a typo. The root directory is ':' on the amiga and 
+cd / means move up one level, cd : means move to root.
+There is a unix emulation library, ixemul.library, which handles things
+like cd .. and cd / when one is using programs linked against it.
+Thats why almost, if not all gnu tools are available for the Amiga and
+they also work like on Unix. These leads to difficulties when mixing
+'native' Amiga programs and ixemul.library linked ones. The path
+differences are most prominent.
+
+Somewhere in my patches I use a native program 'assign' inside ksh.
+Further I have the gnu-tools installed under the 'gg' directory and
+reference them in ksh using /gg.
+Libtool libraries end up in /gg/lib (libNAME_ixlibrary.a, libNAME.a) and
+the dynamic library ends up in /gg/sys/libs (libNAME.ixlibrary)
+The system finds these because of the following statement:
+assign LIBS: gg:sys/libs add
+But some people like to specify --prefix=/local when configuring
+packages and they also want the dynamic library to appear under
+/local/sys/libs and thats why I have the sed substitution in postinstall_cmds
+(?). Those people are responsible that they have an assignment that
+tells the system to look into the proper directory for .ixlibraries.
+
+> Thanks!
+No thanks, hope this clears up a lot of things. If not, ask me and I'll
+try to clarify things.
+
+Joop
+
+----
+Joop van de Wege (JoopvandeWege@mail.mococo.nl)
+Mobile Computing Consultants
++31 (0) 318 553292
+
+From nobody Sun Dec 14 10:48:13 1997
+X-From-Line: JoopvandeWege@mococo.nl Sat Dec 13 03:05:34 1997
+Return-Path: <JoopvandeWege@mococo.nl>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 11049 invoked from network); 13 Dec 1997 03:05:32 -0000
+Received: from localhost (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by localhost with SMTP; 13 Dec 1997 03:05:32 -0000
+Received: from mcc-server.mococo.nl (mail.mococo.nl [195.193.4.2]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with SMTP id GAA11738 for <gord@m-tech.ab.ca>; Fri, 12 Dec 1997 06:47:52 -0700
+Received: from laptop.mococo.nl (unverified [195.193.4.9]) by mcc-server.mococo.nl
+ (EMWAC SMTPRS 0.83) with SMTP id <B0000011567@mcc-server.mococo.nl>;
+ Fri, 12 Dec 1997 14:48:06 +0100
+Date: Fri, 12 Dec 1997 14:48:06 +0100
+Message-ID: <B0000011567@mcc-server.mococo.nl>
+From: Joop van de Wege <JoopvandeWege@mococo.nl>
+To: Gordon Matzigkeit <gord@m-tech.ab.ca>
+Cc: gg@ninemoons.com
+Subject: Re: AmigaOS libtool port
+In-Reply-To: <86zpm8qm6o.fsf@trick.profitpress.com>
+References: <B0000011089@mcc-server.mococo.nl> <86zpm8qm6o.fsf@trick.profitpress.com>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=US-ASCII
+Content-Transfer-Encoding: 7bit
+X-Mailer: Becky! ver 1.23
+Lines: 111
+Xref: trick.profitpress.com mail.libtool:868
+
+
+
+On 11 Dec 1997 02:11:11 -0700
+Gordon Matzigkeit <gord@m-tech.ab.ca> wrote:
+
+> Hi!
+> 
+> >>>>> Joop van de Wege writes:
+> 
+>  >> Is that alright?  My concerns are for the NAME definition, and the
+>  >> LIBRARY_ID, as I don't know what is valid, or what they are used
+>  >> for.
+> 
+>  JvdW> I have done this also but removed it because there are indeed
+>  JvdW> two problem. The NAME should be 'hello' but this can be solved
+>  JvdW> but the second issue is not so easy. LIBRARY_ID is a uniquely
+>  JvdW> assign number which needs to be different for each .ixlibrary
+>  JvdW> build. The developer of the ixlibrary is maintaining a database
+>  JvdW> of which numbers are assign to which library. Everything below
+>  JvdW> 10 can be used for locally build libraries, thats why I used 1.
+>  JvdW> So it is specific to the Amiga but it looks like overkill to me
+>  JvdW> to include the whole list into Libtool (about 50 entries right
+>  JvdW> now).
+> 
+> I suggest that the ixlibrary maintainer come up with a hash function
+> that will map library names to numbers, so that if the LIBRARY_ID is
+> not specified, it will be automatically generated by this hash
+> function.
+> 
+> If two hashed library codes conflict, then libtool will still have to
+> provide a way for maintainers to specify the correct LIBRARY_ID.
+> 
+> However, the current design of ixlibrary is not good because it means
+> installing two libtool libraries will *always* cause a conflict,
+> unless both package maintainers cared enough to be assigned a
+> LIBRARY_ID.
+The current situation is that all packages on ftp.ninemoons.com are
+under CVS (amiga specific code added) and that for each snapshot Amiga
+specific patches are applied to the baseline sources, whether they
+originate from FSF or someplace else doesn't matter.
+This means that for each library which can be turned into a *.ixlibrary
+an a2ixlibrary.data{.in} exists.
+
+It would be nice if the LIBRARY_ID's could be maintained in one location
+and that location being libtool. On the other hand lots of people might
+have objections against such a special treatment to the Amiga.
+It might mean a lot of code just to support on platform.
+
+> 
+> When I accepted the patches for the AmigaOS shared libraries, I was
+> not aware of this limitation.  You are basically telling me that there
+> is no way for me to automatically generate correct shared libraries on
+> AmigaOS.
+No, unless I start digging into the a2ixlibrary source to see if I can
+find a way to automate things. The problem is in the fact that the ID is
+hardcoded into the library (like paths on some other platforms) and the
+ID must be unique, making distribution of binaries almost impossible.
+
+
+> Unless this issue can be resolved, I think I should remove the AmigaOS
+> support, because it will cause more problems than it solves.  Shared
+> libraries, IMO, are not worth the time and effort of every maintainer
+> having to register with the AmigaOS ixlibrary project.
+Libtool can still be a package useful for the Amiga but it will get the
+same treatment as all others, keep a baseline and apply patches when
+needed.
+
+> 
+>  JvdW> Somewhere in my patches I use a native program 'assign' inside
+>  JvdW> ksh.  Further I have the gnu-tools installed under the 'gg'
+>  JvdW> directory and reference them in ksh using /gg.  Libtool
+>  JvdW> libraries end up in /gg/lib (libNAME_ixlibrary.a, libNAME.a)
+>  JvdW> and the dynamic library ends up in /gg/sys/libs
+>  JvdW> (libNAME.ixlibrary)
+> 
+>  JvdW> But some
+>  JvdW> people like to specify --prefix=/local when configuring
+>  JvdW> packages and they also want the dynamic library to appear under
+>  JvdW> /local/sys/libs and thats why I have the sed substitution in
+>  JvdW> postinstall_cmds (?). Those people are responsible that they
+>  JvdW> have an assignment that tells the system to look into the
+>  JvdW> proper directory for .ixlibraries.
+> 
+> This is a problem.  Why do dynamic libraries have to go into a
+> separate directory?
+This way it doesn't clutter a directory where no executables belong in.
+It is also historical and because the Amiga isn't a real Unix machine.
+It uses ixemul.library for its unix emulation, something like cygwin32.dll
+
+> sys/libs sounds like a violation of the GNU directory conventions,
+> which is a problem.  It means that even GNU packages will not install
+> binaries according to their own conventions. :(
+> 
+> It seems to me to be much better if we just put everything into
+> libdir.  Can this work?
+Yes, it can.
+
+I'll forward this reply to some relevant Amiga mailinglists to see if
+people are willing to change things.
+
+Joop
+
+PS:
+Please comment on this, Fred, Hans?
+
+----
+
+Joop van de Wege (JoopvandeWege@mail.mococo.nl)
+Mobile Computing Consultants
++31 (0) 318 553292
+
diff --git a/mail/c++ b/mail/c++
new file mode 100644
index 00000000..4a27b247
--- /dev/null
+++ b/mail/c++
@@ -0,0 +1,796 @@
+From nobody Sat Sep 13 12:49:21 1997
+X-From-Line: gord@gnu.ai.mit.edu Fri Sep 12 11:33:52 1997
+Return-Path: <gord@gnu.ai.mit.edu>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 5853 invoked from network); 12 Sep 1997 11:33:52 -0000
+Received: from localhost (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by localhost with SMTP; 12 Sep 1997 11:33:52 -0000
+X-POP3-Rcpt: gord@bambam
+Received: from mescaline.gnu.ai.mit.edu (root@mescaline.gnu.ai.mit.edu [128.52.46.63]) by m-tech.ab.ca (8.6.12/8.6.9) with ESMTP id DAA32184 for <gord@m-tech.ab.ca>; Fri, 12 Sep 1997 03:29:36 -0600
+Received: from deneb.dfn.de by mescaline.gnu.ai.mit.edu (8.8.5/8.6.12GNU) with ESMTP id FAA15584 for <bug-libtool@gnu.ai.mit.edu>; Fri, 12 Sep 1997 05:26:22 -0400
+Received: from mail.iuk.tu-harburg.de (merlin.iuk.tu-harburg.de [134.28.37.139])
+	by deneb.dfn.de (8.8.7/8.8.7) with SMTP id LAA10284
+	for <bug-libtool@gnu.ai.mit.edu>; Fri, 12 Sep 1997 11:26:24 +0200 (MET DST)
+Received: from radagast.iuk.tu-harburg.de by mail.iuk.tu-harburg.de (SMI-8.6/SMI-SVR4)
+	id LAA03507; Fri, 12 Sep 1997 11:26:24 +0200
+Received: from radagast.iuk.tu-harburg.de by radagast.iuk.tu-harburg.de (SMI-8.6/SMI-SVR4)
+	id LAA09711; Fri, 12 Sep 1997 11:26:19 +0200
+Message-Id: <199709120926.LAA09711@radagast.iuk.tu-harburg.de>
+Date: Fri, 12 Sep 1997 11:26:19 +0200 (MET DST)
+From: Thomas Hiller <hiller@merlin.iuk.tu-harburg.de>
+Reply-To: Thomas Hiller <hiller@merlin.iuk.tu-harburg.de>
+Subject: libtool and c++
+To: bug-libtool@gnu.ai.mit.edu
+MIME-Version: 1.0
+Content-Type: TEXT/plain; charset=us-ascii
+Lines: 21
+Xref: trick.profitpress.com mail.libtool:497
+
+Content-MD5: PkFtlfmXLmdAHDrBATl72w==
+X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc
+
+Hi,
+
+I'm using - with success - libtool and c++ on linux 2.0.x.
+Now in the office I tried on solaris (with gcc) - without success. The culprit
+is the linker call. (I use the sun linker)
+
+Why does libtool use the direct call to ld and not gcc -shared ?
+Or collect2 from the gcc distribution ?
+
+Thanks in advance
+
+Thomas Hiller				email: hiller@tu-harburg.d400.de
+TU Hamburg-Harburg
+Zentrallabor Informations- und Kommunikationstechnik
+Harburger Schloss-Str. 20		Tel.: +49-40-7718-3448
+D - 21071 Hamburg			Fax : +49-40-7718-2579
+
+
+From nobody Sat Sep 13 12:49:24 1997
+X-From-Line: gord@gnu.ai.mit.edu Fri Sep 12 11:33:54 1997
+Return-Path: <gord@gnu.ai.mit.edu>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 5858 invoked from network); 12 Sep 1997 11:33:53 -0000
+Received: from localhost (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by localhost with SMTP; 12 Sep 1997 11:33:53 -0000
+X-POP3-Rcpt: gord@bambam
+Received: from mescaline.gnu.ai.mit.edu (root@mescaline.gnu.ai.mit.edu [128.52.46.63]) by m-tech.ab.ca (8.6.12/8.6.9) with ESMTP id DAA32233 for <gord@m-tech.ab.ca>; Fri, 12 Sep 1997 03:51:50 -0600
+Received: from deneb.dfn.de by mescaline.gnu.ai.mit.edu (8.8.5/8.6.12GNU) with ESMTP id FAA16004 for <bug-libtool@gnu.ai.mit.edu>; Fri, 12 Sep 1997 05:48:38 -0400
+Received: from mail.iuk.tu-harburg.de (merlin.iuk.tu-harburg.de [134.28.37.139])
+	by deneb.dfn.de (8.8.7/8.8.7) with SMTP id LAA10810
+	for <bug-libtool@gnu.ai.mit.edu>; Fri, 12 Sep 1997 11:48:40 +0200 (MET DST)
+Received: from radagast.iuk.tu-harburg.de by mail.iuk.tu-harburg.de (SMI-8.6/SMI-SVR4)
+	id LAA11251; Fri, 12 Sep 1997 11:48:41 +0200
+Received: from radagast.iuk.tu-harburg.de by radagast.iuk.tu-harburg.de (SMI-8.6/SMI-SVR4)
+	id LAA11083; Fri, 12 Sep 1997 11:48:36 +0200
+Message-Id: <199709120948.LAA11083@radagast.iuk.tu-harburg.de>
+Date: Fri, 12 Sep 1997 11:48:36 +0200 (MET DST)
+From: Thomas Hiller <hiller@merlin.iuk.tu-harburg.de>
+Reply-To: Thomas Hiller <hiller@merlin.iuk.tu-harburg.de>
+Subject: libtool and c++ (follow-up)
+To: bug-libtool@gnu.ai.mit.edu
+MIME-Version: 1.0
+Content-Type: TEXT/plain; charset=us-ascii
+Lines: 50
+Xref: trick.profitpress.com mail.libtool:498
+
+Content-MD5: pYKoLEegluk256lZh3GEEg==
+X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc
+
+Hi,
+
+after further investigation I found the difference is not the linker itself, but
+the call of the linker especially the start and endfiles:
+crti crtbegin crtend crtn are not linked in.
+
+libtool:
+/usr/ccs/bin/ld -G -z text -h libbase.so.1 -o .libs/libbase.so.1.1.0
+./dloadlib.lo ./caches.lo ./damages.lo ./debug.lo ./displays.lo ./drawings.lo
+./externaliz.lo ./fresco_lib.lo ./glyphs.lo ./memory.lo ./names.lo ./octetbuf.lo
+./os.lo ./painters.lo ./proxyobs.lo ./rasters.lo ./styles.lo ./threads.lo
+./typess.lo ./viewers.lo ./windows.lo
+
+gcc -shared:
+
+radagast{hiller}107: gcc -v -shared ...
+Reading specs from /tools/gcc-2.7/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs
+gcc version 2.7.2.3
+ /usr/ccs/bin/ld -V -G -dy -z text -h libbase.la
+-R/home/radagast/hiller/work/Fresco97/Fresco/Build/lib
+-R/home/radagast/hiller/work/Fresco97/Fresco/Build/lib -Y
+P,/usr/ccs/lib:/usr/lib -Qy -o libbase.la
+/tools/gcc-2.7/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/crti.o
+/usr/ccs/lib/values-Xa.o
+/tools/gcc-2.7/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/crtbegin.o
+-L/tools/gcc-2.7/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3 -L/usr/ccs/bin
+-L/usr/ccs/lib -L/tools/gcc-2.7/lib ./dloadlib.lo ./caches.lo ./damages.lo
+./debug.lo ./displays.lo ./drawings.lo ./externaliz.lo ./fresco_lib.lo
+./glyphs.lo ./memory.lo ./names.lo ./octetbuf.lo ./os.lo ./painters.lo
+./proxyobs.lo ./rasters.lo ./styles.lo ./threads.lo ./typess.lo ./viewers.lo
+./windows.lo /tools/gcc-2.7/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/crtend.o
+/tools/gcc-2.7/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/crtn.o
+ld: Software Generation Utilities - Solaris/ELF (3.0)
+
+Platform: Solaris 2.6
+Compiler: gcc-2.7.2.3 (with SUN linker)
+Libtool: 1.0b
+
+Greetings
+
+Thomas Hiller				email: hiller@tu-harburg.d400.de
+TU Hamburg-Harburg
+Zentrallabor Informations- und Kommunikationstechnik
+Harburger Schloss-Str. 20		Tel.: +49-40-7718-3448
+D - 21071 Hamburg			Fax : +49-40-7718-2579
+
+
+From nobody Sat Sep 13 12:49:26 1997
+X-From-Line: gord@gnu.ai.mit.edu Sat Sep 13 06:08:19 1997
+Return-Path: <gord@gnu.ai.mit.edu>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 3043 invoked from network); 13 Sep 1997 06:08:19 -0000
+Received: from localhost (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by localhost with SMTP; 13 Sep 1997 06:08:19 -0000
+X-POP3-Rcpt: gord@bambam
+Received: from ethanol.gnu.ai.mit.edu (root@ethanol.gnu.ai.mit.edu [128.52.46.64]) by m-tech.ab.ca (8.6.12/8.6.9) with ESMTP id LAA24598 for <gord@m-tech.ab.ca>; Fri, 12 Sep 1997 11:42:10 -0600
+Received: from rztsun.rz.tu-harburg.de by ethanol.gnu.ai.mit.edu (8.8.5/8.6.12GNU) with SMTP id NAA27280 for <bug-libtool@gnu.ai.mit.edu>; Fri, 12 Sep 1997 13:38:42 -0400
+Date: Fri, 12 Sep 1997 18:43:39 +0000 (met)
+From: Thomas Hiller <hiller@tu-harburg.d400.de>
+Reply-To: Thomas Hiller <hiller@tu-harburg.d400.de>
+Subject: libtool and solaris (and c++)
+To: bug-libtool@gnu.ai.mit.edu
+Message-ID: <Roam2.0.6.874089819.24146.hiller@mail.iuk.tu-harburg.de>
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+Lines: 16
+Xref: trick.profitpress.com mail.libtool:502
+
+Hi,
+
+I found a bug on solaris_x86:
+    'printf %s\n'
+should read
+    'printf %s\\n'
+in ltmain.sh.
+
+Another follow-up to c++:
+I changed the script to use c++ -shared and AFAIK all works. Maybe the script
+could use '$CC <platform switches>' or - with gcc - 'gcc -shared'.
+
+Greetings
+    Thomas
+(hiller@tu-harburg.d400.de)
+
+From nobody Tue Oct  7 19:29:17 1997
+X-From-Line: gord@gnu.org Wed Oct 08 00:03:13 1997
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 13926 invoked from network); 8 Oct 1997 00:03:12 -0000
+Received: from localhost (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by localhost with SMTP; 8 Oct 1997 00:03:12 -0000
+X-POP3-Rcpt: gord@bambam
+Received: from mescaline.gnu.org (root@mescaline.gnu.org [158.121.106.21]) by m-tech.ab.ca (8.6.12/8.6.9) with ESMTP id LAA01054 for <gord@m-tech.ab.ca>; Tue, 7 Oct 1997 11:58:02 -0600
+Received: from listserv.ucalgary.ca by mescaline.gnu.org (8.8.5/8.6.12GNU) with SMTP id NAA18464 for <bug-libtool@gnu.ai.mit.edu>; Tue, 7 Oct 1997 13:53:36 -0400
+Received: from ts3-port-52.acs.ucalgary.ca by listserv.ucalgary.ca (AIX 3.2/UCB 5.64/4.03)
+          id AA15145; Tue, 7 Oct 1997 11:53:10 -0600
+Received: (qmail 11153 invoked by uid 1001); 7 Oct 1997 17:52:59 -0000
+Sender: gord@trick.profitpress.com
+To: Akim Demaille <demaille@inf.enst.fr>
+Cc: bug-libtool@gnu.org
+Subject: Re: Shared libs before installation
+References: <qylg1qstg1o.fsf@gargantua.enst.fr>
+X-Attribution:  Gord
+Mime-Version: 1.0 (generated by tm-edit 7.92)
+Content-Type: text/plain; charset=US-ASCII
+From: Gordon Matzigkeit <gord@m-tech.ab.ca>
+Date: 07 Oct 1997 11:52:59 -0600
+In-Reply-To: Akim Demaille's message of 26 Sep 1997 14:28:51 +0200
+Message-Id: <86201xcves.fsf@trick.profitpress.com>
+X-Mailer: Gnus v5.4.42/Emacs 19.34
+Lines: 41
+Xref: trick.profitpress.com mail.libtool:570
+
+Hi!
+
+>>>>> Akim Demaille writes:
+
+ AD> 	We once talked about this, but let's do it again :)
+
+Okay! ;)
+
+ AD> 	I know this is the kind of things version numbers should
+ AD> solve.  Nevertheless, to avoid having quickly too big a version
+ AD> number, the version should be set right before a _public_
+ AD> distribution (correct?).  Not when sharing with
+ AD> testers/maintainers.
+
+ AD> 	But then they are most likely to link with an old installed
+ AD> version of the .so, failing to compile correctly.
+
+Actually, you may consider having *huge* version numbers for testers,
+and using tiny ones for public releases.
+
+For testing releases use a major version corresponding with the
+current date:  -version-info 19971007
+
+Then for the public release, figure out what has actually changed
+since last time:  -version-info 3:0:1
+
+The huge test release major numbers will guarantee that every new test
+release will require relinking, but the public versions will be
+smarter and possibly backwards-compatible.
+
+ AD> 	I am no system guy, so I may say stupid things :)
+
+Nothing stupid.  These are legitimate questions that I will have to
+answer eventually in the documentation.
+
+Thanks for your questions,
+
+--
+  Gord Matzigkeit   | Proudly running pieces of the GNU operating system.
+ gord@m-tech.ab.ca  |  Jacques Cousteau loved programming in assembler.
+
+From nobody Wed Oct 15 00:04:31 1997
+X-From-Line: coolo@itm.mu-luebeck.de Wed Oct 15 00:11:44 1997
+Return-Path: <coolo@itm.mu-luebeck.de>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 4396 invoked from network); 15 Oct 1997 00:11:42 -0000
+Received: from localhost (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by localhost with SMTP; 15 Oct 1997 00:11:42 -0000
+X-POP3-Rcpt: gord@bambam
+Received: from itm.mu-luebeck.de (wotan.itm.mu-luebeck.de [141.83.21.121]) by m-tech.ab.ca (8.6.12/8.6.9) with ESMTP id MAA12037 for <gord@m-tech.ab.ca>; Tue, 14 Oct 1997 12:59:53 -0600
+Received: from buri.itm.mu-luebeck.de (coolo@buri [141.83.21.130]) by itm.mu-luebeck.de (8.8.7/8.7.1) with ESMTP id UAA12900 for <gord@m-tech.ab.ca>; Tue, 14 Oct 1997 20:54:08 +0200 (MET DST)
+From: Stephan Kulow <coolo@itm.mu-luebeck.de>
+Received: (from coolo@localhost)
+          by buri.itm.mu-luebeck.de (8.8.4/8.8.4)
+	  id UAA01692 for gord@m-tech.ab.ca; Tue, 14 Oct 1997 20:55:19 +0200
+Message-Id: <199710141855.UAA01692@buri.itm.mu-luebeck.de>
+Subject: Re: dlopen [was: libs dependencies]
+To: gord@m-tech.ab.ca (Gordon Matzigkeit)
+Date: Tue, 14 Oct 1997 20:55:19 +0200 (MET DST)
+In-Reply-To: <86wwjg1av8.fsf@trick.profitpress.com> from "Gordon Matzigkeit" at Oct 14, 97 12:02:35 pm
+Content-Type: text
+Lines: 88
+Xref: trick.profitpress.com mail.libtool:589
+
+>
+> Hi!
+>
+> >>>>> Stephan Kulow writes:
+>
+> I think we've adequately discussed your library dependencies, but I
+> wanted to comment on the dlopen support that you mention below:
+>
+>  SK> BTW: I made some efforts to use the dlopen support in libtool. I
+>  SK> think, it works the way I tried it. I link staticly, if dlfcn.h
+>  SK> or libdl is not supported. For this I patched libtool.m4 to
+>  SK> support this.  I had to remove the --enable-shared/static options
+>  SK> and replaced it with --disable-dlopen option, since it looks
+>  SK> somewhat strange, if you have --enable-shared in a package, where
+>  SK> you do not expect libs.
+>
+> Yes, you are right.  When I fully support dlopen emulation, I will
+> need to make a configure flag that can turn things on and off.
+>
+>  SK> We create a binary, that loads libraries, that contain C++
+>  SK> classes derived from a specific class. So, it's not necessary,
+>  SK> that the binary knows, which "applets" are there while compile
+>  SK> time.
+>
+> Okay, this makes sense.  This is why I generate the `symbol file' when
+> -export-dynamic is given, which contains a list of symbols mapped to
+> pointers in a C source file.
+>
+> Your solution is acceptable, and if it works for your application,
+> congratulations!  As I've said before, my eventual solution will be
+> generic and application-independent: I will write a true dlopen
+> implementation that uses a libtool `symbol file' to resolve pointers
+> rather than dynamic loading of code.
+>
+> The C++ portion of this will need to understand name mangling, which
+> is probably why you chose the easier way, of making your dlopening
+> application-specific.
+You say, you will write code? I tried to imagine a solution without
+new code, but I failed. So you write a new linker or just a library,
+that I can use in my own code?
+>
+>  SK> This is somewhat a problem and I don't know a solution, how to
+>  SK> solve this.  So, I added a header file, that contains all
+>  SK> currently known modules and this is only used, if no dlopen is
+>  SK> available.
+>
+> Okay, I think I understand.  You are saying that when dlopen is not
+> available, you emulate it by knowing in advance which modules have
+> been linked into the executable (SANE calls this `preloading'), and
+> changing your application to refer to specific C++ modules.
+Yes. I have to know while compilation time of the binary, which libraries
+get linked.
+>
+> As I've said above, when I release DLD 4.0 I'll let you know, but
+> until then, your application-specific preloading is acceptable, and
+> the Right Thing To Do.
+Thanks, it's a pleasure to hear such comments ;)
+>
+>  SK> Thanks for writing libtool, Stephan
+>
+> My pleasure!  Thanks for using it, :)
+BTW: Perhaps you remember, I once contacted you because of some problems
+with C++ and static objects in shared libs. I found out (or read in a
+news group), that most compilers on such plattforms do some magic before
+calling the linker. So, what libtool have to do to support such plattforms
+(Solaris, FreeBSD and perhaps some more), is to call the compiler and not
+the linker to create C++ shared libs.
+CC (under Solaris) has the same options then the linker, but should create
+correct libraries.
+Currently I set CC to CXX before I run AM_PROG_LIBTOOL to let libtool
+find the correct linker options for the C++ compiler instead of the C
+compiler.
+
+I just wanted to let you know, what I found out. I thought about patching
+libtool to have better support for C++, but this would mean some drastic
+changes, so I left it up to you ;)
+
+Greets, Stephan
+
+--
+Stephan Kulow (coolo@kde.org)
+Student of medical CS
+Medical University of Luebeck
+
+GCS/M/MD d-x s++: a-- C+++$ ULS+++ P--- L++ E W- N- o? K--? w
+!O-- !M !V PS++ !PE Y PGP++ t+ 5 X+ !R tv+ b+ DI? D- G e+>$
+h--(++) r y
+
+
+From nobody Thu Aug 20 09:31:03 1998
+X-From-Line: gord@gnu.org Wed Aug 05 11:02:23 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 6829 invoked from network); 5 Aug 1998 11:02:23 -0000
+Received: from gen2-93ip34.cadvision.com (HELO bambam.m-tech.ab.ca) (209.91.93.34)
+  by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 5 Aug 1998 11:02:23 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id EAA09526 for <gord@m-tech.ab.ca>; Wed, 5 Aug 1998 04:59:58 -0600
+Received: from uranus.ubs.com by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id HAA22473 for <bug-libtool@gnu.org>; Wed, 5 Aug 1998 07:00:29 -0400
+From: alois.camenzind@ubs.com
+Received: by uranus.ubs.com; id MAA10838; Wed, 5 Aug 1998 12:56:10 +0200 (MET DST)
+Received: from <alois.camenzind@ubs.com> (svscan [192.168.85.11]) by uranus via smap (V2.1)
+	id xma010753; Wed, 5 Aug 98 12:55:53 +0200
+Received: from localhost by svscan.ubinet.ubs.com (SMI-8.6/SMI-SVR4)
+	id MAA01005; Wed, 5 Aug 1998 12:58:25 +0200
+Received: from localhost (root@localhost)
+	by svcastor.flur.zuerich.ubs.ch (8.8.6 (PHNE_12836)/8.8.6) with SMTP id MAA21146
+	for bug-libtool@gnu.org; Wed, 5 Aug 1998 12:58:23 +0200 (METDST)
+X-OpenMail-Hops: 2
+Date: Wed, 5 Aug 1998 12:58:13 +0200
+Message-Id: <5499F13A@MHS>
+Subject: libtool bug/problem
+MIME-Version: 1.0
+TO: bug-libtool@gnu.org
+Content-Type: multipart/mixed; boundary="MimeMultipartBoundary"
+Lines: 33
+Xref: trick.fig.org libtool:1548
+
+--MimeMultipartBoundary
+Content-Type: text/plain; charset=US-ASCII; name="PUBLIC:"
+Content-Disposition: inline; filename="PUBLIC:"
+Content-Transfer-Encoding: 7bit
+
+Hi
+
+I'd like to use libtool (ltmain.sh (GNU libtool) 1.2 togheter with the SUN C++
+compiler (CC: WorkShop Compilers 4.2 30 Oct 1996 C++ 4.2) on Solaris 5.5.1.
+
+Everything works good  except if I'm trying to use C++ templates in my code and
+put this in a shared library. The linker is afterwards always complaining
+about missing references.  The problem occurs because libtool renames
+the object
+files from xxx.o to xxx.lo. The SUN C++ compiler builds for himself a
+Template.DB
+and this somehow doens't match anymore with the object file.
+
+Have you ever heard of this problem and do you eventually allready have
+a solution?
+
+I search in Deja News but couldn't find anything.
+A solution I could think of would be to rename the xxx.lo file back to
+xxx.o  before
+the linking phase.
+
+Thanks for any hints.
+
+ciao
+Alois
+
+--MimeMultipartBoundary--
+From nobody Wed Oct 14 17:08:59 1998
+X-From-Line: gord@mescaline.gnu.org Mon Oct 05 20:10:38 1998
+Return-Path: <gord@mescaline.gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 2026 invoked from network); 5 Oct 1998 20:10:30 -0000
+Received: from gen2-93ip34.cadvision.com (HELO bambam.m-tech.ab.ca) (209.91.93.34)
+  by ip223.net247210.cr.sk.ca with SMTP; 5 Oct 1998 20:10:30 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1])
+	by bambam.m-tech.ab.ca (8.8.7/8.8.7) with ESMTP id OAA31749
+	for <gord@m-tech.ab.ca>; Mon, 5 Oct 1998 14:13:57 -0600
+Received: from proxy.grad.kiev.ua (grad-UTC-28k8.ukrtel.net [195.5.25.54])
+	by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id PAA26247
+	for <bug-libtool@gnu.org>; Mon, 5 Oct 1998 15:57:59 -0400
+Received: from Shevchenko.Kiev.UA (cam [10.0.0.50])
+	by proxy.grad.kiev.ua (8.8.8/8.8.7) with ESMTP id WAA07178
+	for <bug-libtool@gnu.org>; Mon, 5 Oct 1998 22:56:50 +0300 (EEST)
+	(envelope-from Ruslan@Shevchenko.Kiev.UA)
+Sender: rssh@proxy.grad.kiev.ua
+Message-ID: <3619242C.C441DA29@Shevchenko.Kiev.UA>
+Date: Mon, 05 Oct 1998 22:55:24 +0300
+From: Ruslan Shevchenko <Ruslan@Shevchenko.Kiev.UA>
+Reply-To: rssh@grad.kiev.ua
+X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.5-STABLE i386)
+MIME-Version: 1.0
+To: bug-libtool@gnu.org
+Subject: C++ libs on Solaris 2.6 with Sun CC 4.2
+Content-Type: multipart/mixed; boundary="------------48AE685394F01B5105112CF0"
+Lines: 109
+Xref: trick.fig.org libtool:1646
+
+This is a multi-part message in MIME format.
+--------------48AE685394F01B5105112CF0
+Content-Type: text/plain; charset=us-ascii
+Content-Transfer-Encoding: 7bit
+
+envirowment:
+
+uname -a:
+
+SunOS satory 5.6 Generic_105181-06 sun4u sparc SUNW,Ultra-4
+
+Sun CC 4.1
+
+libtool 1.2
+
+Problem:
+
+  building of shared libraries not supported.
+ (output of simple conffigure is attached.)
+
+  and in reality, the process of linking CC library is different,
+ becouse generation of templates can be doing on stage of linking.
+
+ In general, command for linking is 
+ CC -xar -o$(LIBNAME) $(CXXFLAGS) $(OBJECTS)
+
+ If anybody will tell me, from what I must begin, I will help to
+add such support.
+
+ Thanks.
+
+
+-- 
+    @=                                   
+     //RSSH                             
+mailto:Ruslan@Shevchenko.Kiev.UA
+
+CORBA in Ukraine & ex-USSR: http://www.corbadev.kiev.ua
+--------------48AE685394F01B5105112CF0
+Content-Type: text/plain; charset=us-ascii; name="errs"
+Content-Transfer-Encoding: 7bit
+Content-Disposition: inline; filename="errs"
+
+creating cache ./config.cache
+checking host system type... sparc-sun-solaris2.6
+checking target system type... sparc-sun-solaris2.6
+checking build system type... sparc-sun-solaris2.6
+checking for a BSD compatible install... config/install-sh -c
+checking whether build environment is sane... yes
+checking whether make sets ${MAKE}... yes
+checking for working aclocal... found
+checking for working autoconf... found
+checking for working automake... found
+checking for working autoheader... found
+checking for working makeinfo... missing
+checking for c++... no
+checking for g++... no
+checking for gcc... no
+checking for CC... CC
+checking whether the C++ compiler (CC  ) works... yes
+checking whether the C++ compiler (CC  ) is a cross-compiler... no
+checking whether we are using GNU C++... no
+checking how to run the C++ preprocessor... CC -E
+checking for ranlib... ranlib
+checking for gcc... no
+checking for cc... cc
+checking whether the C compiler (cc  ) works... yes
+checking whether the C compiler (cc  ) is a cross-compiler... no
+checking whether we are using GNU C... no
+checking for non-GNU ld... /usr/ucb/ld
+checking if the linker (/usr/ucb/ld) is GNU ld... no
+checking for BSD-compatible nm... /usr/ccs/bin/nm -p
+checking whether ln -s works... yes
+checking whether we are using GNU C... no
+checking for cc option to produce PIC... -KPIC
+checking if cc PIC flag -KPIC works... no
+checking if cc static flag -Bstatic works... -Bstatic
+checking if the linker (/usr/ucb/ld) is GNU ld... no
+checking whether the linker (/usr/ucb/ld) supports shared libraries... yes
+checking command to parse /usr/ccs/bin/nm -p output... yes
+checking how to hardcode library paths into programs... immediate
+checking for /usr/ucb/ld option to reload object files... -r
+checking dynamic linker characteristics... solaris2.6 ld.so
+checking if libtool supports shared libraries... no
+checking whether to build shared libraries... no
+checking whether to build static libraries... yes
+checking for objdir... .libs
+creating libtool
+checking for a BSD compatible install... config/install-sh -c
+CPPFLAGS= -I/usr/local/include
+checking for OB/CORBA.h... yes
+
+checking for JTC/JTC.h... yes
+checking for OB/CosNaming.h... yes
+checking for nanosleep in -lposix4... yes
+solaris2.6
+checking for socket in -lsocket... yes
+updating cache ./config.cache
+creating ./config.status
+creating Makefile
+creating src/Makefile
+creating include/Makefile
+creating tests/Makefile
+creating tests/naming/Makefile
+creating include/SyntaxShugarConfig.h
+include/SyntaxShugarConfig.h is unchanged
+
+--------------48AE685394F01B5105112CF0--
+
+From nobody Wed Oct 14 17:11:47 1998
+X-From-Line: gord@mescaline.gnu.org Tue Oct 13 18:11:55 1998
+Return-Path: <gord@mescaline.gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 694 invoked from network); 13 Oct 1998 18:11:25 -0000
+Received: from gen2-93ip34.cadvision.com (HELO bambam.m-tech.ab.ca) (209.91.93.34)
+  by ip223.net247210.cr.sk.ca with SMTP; 13 Oct 1998 18:11:25 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1])
+	by bambam.m-tech.ab.ca (8.8.7/8.8.7) with ESMTP id MAA30151
+	for <gord@m-tech.ab.ca>; Tue, 13 Oct 1998 12:14:55 -0600
+Received: from proxy.grad.kiev.ua (grad-UTC-28k8.ukrtel.net [195.5.25.54])
+	by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id NAA14314
+	for <bug-libtool@gnu.org>; Tue, 13 Oct 1998 13:56:26 -0400
+Received: from Shevchenko.Kiev.UA (cam [10.0.0.50])
+	by proxy.grad.kiev.ua (8.8.8/8.8.7) with ESMTP id UAA04080
+	for <bug-libtool@gnu.org>; Tue, 13 Oct 1998 20:54:29 +0300 (EEST)
+	(envelope-from Ruslan@Shevchenko.Kiev.UA)
+Sender: rssh@proxy.grad.kiev.ua
+Message-ID: <3623937C.7E903DF8@Shevchenko.Kiev.UA>
+Date: Tue, 13 Oct 1998 20:53:00 +0300
+From: Ruslan Shevchenko <Ruslan@shevchenko.kiev.ua>
+Reply-To: rssh@grad.kiev.ua
+X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.5-STABLE i386)
+MIME-Version: 1.0
+To: bug-libtool@gnu.org
+Subject: overriding ARFLAGS.
+Content-Type: multipart/mixed; boundary="------------E06156B73BE5D4D4AD2BF900"
+Lines: 221
+Xref: trick.fig.org libtool:1683
+
+This is a multi-part message in MIME format.
+--------------E06156B73BE5D4D4AD2BF900
+Content-Type: text/plain; charset=koi8-r
+Content-Transfer-Encoding: 7bit
+
+As I noted few days ago, the process of building a library (static or
+shared)
+with C++ can include addition steps, such as template instaniation.
+
+In libtool AR can be overrided from configure ${AR}, but ${ARFLAGS}
+(cru)
+is hardcoded into ltconfig.sh
+
+setting ${ARFLAGS} as variable (or cru if "$ARFLAGS" is empty ) actually
+enable
+building of templated C++ variables (static only yet) by overriding AR
+and ARFLAGS
+from configure.
+
+So, I attached to this messages  diff, which change cru to ${ARFLAGS} in 
+ltconfig.in (and therefore in ltconfig)
+
+Also, I think somewhere in documentation must exists the  next note
+about 
+Sun Solaris Workshop:
+/--------
+  When you want build libraries with implicit templates instaniated in, 
+  You must puss to ltconfig next envirowmnent variables:
+  AR=CC
+  ARFLAGS=$CXXFLAGS -xar -o
+----------/ 
+
+
+
+
+
+  
+
+
+-- 
+    @=                                   
+     //RSSH                             
+mailto:Ruslan@Shevchenko.Kiev.UA
+
+CORBA in Ukraine & ex-USSR: http://www.corbadev.kiev.ua
+--------------E06156B73BE5D4D4AD2BF900
+Content-Type: text/plain; charset=koi8-r; name="libtool.diff"
+Content-Transfer-Encoding: 7bit
+Content-Disposition: inline; filename="libtool.diff"
+
+Only in libtool-1.2-patched: Makefile
+Only in libtool-1.2-patched: config.cache
+Only in libtool-1.2-patched: config.log
+Only in libtool-1.2-patched: config.status
+Common subdirectories: libtool-1.2/demo and libtool-1.2-patched/demo
+Common subdirectories: libtool-1.2/doc and libtool-1.2-patched/doc
+Only in libtool-1.2-patched: libtool
+Only in libtool-1.2-patched: libtoolize
+diff -c libtool-1.2/ltconfig libtool-1.2-patched/ltconfig
+*** libtool-1.2/ltconfig	Fri Mar 20 10:00:29 1998
+--- libtool-1.2-patched/ltconfig	Tue Oct 13 20:01:31 1998
+***************
+*** 89,95 ****
+--- 89,101 ----
+  with_gcc=no
+  with_gnu_ld=no
+  
++ if test "x$ARFLAGS" = x
++ then
++  ARFLAGS=cru
++ fi
++ 
+  old_AR="$AR"
++ old_ARFLAGS="$ARFLAGS"
+  old_CC="$CC"
+  old_CFLAGS="$CFLAGS"
+  old_CPPFLAGS="$CPPFLAGS"
+***************
+*** 320,326 ****
+  esac
+  
+  # Determine commands to create old-style static archives.
+! old_archive_cmds='$AR cru $oldlib$oldobjs'
+  old_postinstall_cmds='chmod 644 $oldlib'
+  old_postuninstall_cmds=
+  
+--- 326,332 ----
+  esac
+  
+  # Determine commands to create old-style static archives.
+! old_archive_cmds='$AR $ARFLAGS $oldlib$oldobjs'
+  old_postinstall_cmds='chmod 644 $oldlib'
+  old_postuninstall_cmds=
+  
+***************
+*** 732,738 ****
+    case "$host_os" in
+    aix3*)
+      allow_undefined_flag=unsupported
+!     archive_cmds='$NM$libobjs | $global_symbol_pipe | sed '\''s/.* //'\'' > $lib.exp;$LD -o $objdir/$soname$libobjs -bE:$lib.exp -T512 -H512 -bM:SRE;$AR cru $lib $objdir/$soname'
+      # Note: this linker hardcodes the directories in LIBPATH if there
+      # are no directories specified by -L.
+      hardcode_minus_L=yes
+--- 738,744 ----
+    case "$host_os" in
+    aix3*)
+      allow_undefined_flag=unsupported
+!     archive_cmds='$NM$libobjs | $global_symbol_pipe | sed '\''s/.* //'\'' > $lib.exp;$LD -o $objdir/$soname$libobjs -bE:$lib.exp -T512 -H512 -bM:SRE;$AR $ARFLAGS $lib $objdir/$soname'
+      # Note: this linker hardcodes the directories in LIBPATH if there
+      # are no directories specified by -L.
+      hardcode_minus_L=yes
+***************
+*** 745,757 ****
+  
+    aix4*)
+      allow_undefined_flag=unsupported
+!     archive_cmds='$NM$libobjs | $global_symbol_pipe | sed '\''s/.* //'\'' > $lib.exp;$CC -o $objdir/$soname$libobjs ${wl}-bE:$lib.exp ${wl}-bM:SRE ${wl}-bnoentry;$AR cru $lib $objdir/$soname'
+      hardcode_direct=yes
+      hardcode_minus_L=yes
+      ;;
+  
+    amigaos*)
+!     archive_cmds='$rm $objdir/a2ixlibrary.data;$echo "#define NAME $libname" > $objdir/a2ixlibrary.data;$echo "#define LIBRARY_ID 1" >> $objdir/a2ixlibrary.data;$echo "#define VERSION $major" >> $objdir/a2ixlibrary.data;$echo "#define REVISION $revision" >> $objdir/a2ixlibrary.data;$AR cru $lib$libobjs;$RANLIB $lib;(cd $objdir && a2ixlibrary -32)'
+      hardcode_libdir_flag_spec='-L$libdir'
+      hardcode_minus_L=yes
+      ;;
+--- 751,763 ----
+  
+    aix4*)
+      allow_undefined_flag=unsupported
+!     archive_cmds='$NM$libobjs | $global_symbol_pipe | sed '\''s/.* //'\'' > $lib.exp;$CC -o $objdir/$soname$libobjs ${wl}-bE:$lib.exp ${wl}-bM:SRE ${wl}-bnoentry;$AR $ARFLAGS $lib $objdir/$soname'
+      hardcode_direct=yes
+      hardcode_minus_L=yes
+      ;;
+  
+    amigaos*)
+!     archive_cmds='$rm $objdir/a2ixlibrary.data;$echo "#define NAME $libname" > $objdir/a2ixlibrary.data;$echo "#define LIBRARY_ID 1" >> $objdir/a2ixlibrary.data;$echo "#define VERSION $major" >> $objdir/a2ixlibrary.data;$echo "#define REVISION $revision" >> $objdir/a2ixlibrary.data;$AR $ARFLAGS $lib$libobjs;$RANLIB $lib;(cd $objdir && a2ixlibrary -32)'
+      hardcode_libdir_flag_spec='-L$libdir'
+      hardcode_minus_L=yes
+      ;;
+diff -c libtool-1.2/ltconfig.in libtool-1.2-patched/ltconfig.in
+*** libtool-1.2/ltconfig.in	Wed Mar 11 18:10:51 1998
+--- libtool-1.2-patched/ltconfig.in	Tue Oct 13 20:44:56 1998
+***************
+*** 320,331 ****
+  esac
+  
+  # Determine commands to create old-style static archives.
+! old_archive_cmds='$AR cru $oldlib$oldobjs'
+  old_postinstall_cmds='chmod 644 $oldlib'
+  old_postuninstall_cmds=
+  
+  # Set a sane default for `AR'.
+  test -z "$AR" && AR=ar
+  
+  # If RANLIB is not set, then run the test.
+  if test "${RANLIB+set}" != "set"; then
+--- 320,332 ----
+  esac
+  
+  # Determine commands to create old-style static archives.
+! old_archive_cmds='$AR $ARFLAGS $oldlib$oldobjs'
+  old_postinstall_cmds='chmod 644 $oldlib'
+  old_postuninstall_cmds=
+  
+  # Set a sane default for `AR'.
+  test -z "$AR" && AR=ar
++ test -z "$ARFLAGS" && ARFLAGS=cru
+  
+  # If RANLIB is not set, then run the test.
+  if test "${RANLIB+set}" != "set"; then
+***************
+*** 732,738 ****
+    case "$host_os" in
+    aix3*)
+      allow_undefined_flag=unsupported
+!     archive_cmds='$NM$libobjs | $global_symbol_pipe | sed '\''s/.* //'\'' > $lib.exp;$LD -o $objdir/$soname$libobjs -bE:$lib.exp -T512 -H512 -bM:SRE;$AR cru $lib $objdir/$soname'
+      # Note: this linker hardcodes the directories in LIBPATH if there
+      # are no directories specified by -L.
+      hardcode_minus_L=yes
+--- 733,739 ----
+    case "$host_os" in
+    aix3*)
+      allow_undefined_flag=unsupported
+!     archive_cmds='$NM$libobjs | $global_symbol_pipe | sed '\''s/.* //'\'' > $lib.exp;$LD -o $objdir/$soname$libobjs -bE:$lib.exp -T512 -H512 -bM:SRE;$AR $ARFLAGS $lib $objdir/$soname'
+      # Note: this linker hardcodes the directories in LIBPATH if there
+      # are no directories specified by -L.
+      hardcode_minus_L=yes
+***************
+*** 745,757 ****
+  
+    aix4*)
+      allow_undefined_flag=unsupported
+!     archive_cmds='$NM$libobjs | $global_symbol_pipe | sed '\''s/.* //'\'' > $lib.exp;$CC -o $objdir/$soname$libobjs ${wl}-bE:$lib.exp ${wl}-bM:SRE ${wl}-bnoentry;$AR cru $lib $objdir/$soname'
+      hardcode_direct=yes
+      hardcode_minus_L=yes
+      ;;
+  
+    amigaos*)
+!     archive_cmds='$rm $objdir/a2ixlibrary.data;$echo "#define NAME $libname" > $objdir/a2ixlibrary.data;$echo "#define LIBRARY_ID 1" >> $objdir/a2ixlibrary.data;$echo "#define VERSION $major" >> $objdir/a2ixlibrary.data;$echo "#define REVISION $revision" >> $objdir/a2ixlibrary.data;$AR cru $lib$libobjs;$RANLIB $lib;(cd $objdir && a2ixlibrary -32)'
+      hardcode_libdir_flag_spec='-L$libdir'
+      hardcode_minus_L=yes
+      ;;
+--- 746,758 ----
+  
+    aix4*)
+      allow_undefined_flag=unsupported
+!     archive_cmds='$NM$libobjs | $global_symbol_pipe | sed '\''s/.* //'\'' > $lib.exp;$CC -o $objdir/$soname$libobjs ${wl}-bE:$lib.exp ${wl}-bM:SRE ${wl}-bnoentry;$AR $ARFLAGS $lib $objdir/$soname'
+      hardcode_direct=yes
+      hardcode_minus_L=yes
+      ;;
+  
+    amigaos*)
+!     archive_cmds='$rm $objdir/a2ixlibrary.data;$echo "#define NAME $libname" > $objdir/a2ixlibrary.data;$echo "#define LIBRARY_ID 1" >> $objdir/a2ixlibrary.data;$echo "#define VERSION $major" >> $objdir/a2ixlibrary.data;$echo "#define REVISION $revision" >> $objdir/a2ixlibrary.data;$AR $ARFLAGS $lib$libobjs;$RANLIB $lib;(cd $objdir && a2ixlibrary -32)'
+      hardcode_libdir_flag_spec='-L$libdir'
+      hardcode_minus_L=yes
+      ;;
+Common subdirectories: libtool-1.2/tests and libtool-1.2-patched/tests
+
+--------------E06156B73BE5D4D4AD2BF900--
+
diff --git a/mail/cygwin32 b/mail/cygwin32
new file mode 100644
index 00000000..edbaabc8
--- /dev/null
+++ b/mail/cygwin32
@@ -0,0 +1,311 @@
+From nobody Wed Oct 14 16:45:23 1998
+X-From-Line: gord@gnu.org Fri Apr 17 23:33:23 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 23433 invoked from network); 17 Apr 1998 23:33:18 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 17 Apr 1998 23:33:18 -0000
+Received: from mescaline.gnu.org (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id OAA06968 for <gord@m-tech.ab.ca>; Fri, 17 Apr 1998 14:24:44 -0600
+Received: from tweedledumb.cygnus.com by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id QAA24530 for <bug-libtool@gnu.org>; Fri, 17 Apr 1998 16:28:50 -0400
+Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
+	by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id QAA18910
+	for <bug-libtool@gnu.org>; Fri, 17 Apr 1998 16:28:46 -0400 (EDT)
+Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id QAA08423; Fri, 17 Apr 1998 16:28:45 -0400
+Date: Fri, 17 Apr 1998 16:28:45 -0400
+Message-Id: <199804172028.QAA08423@subrogation.cygnus.com>
+From: Ian Lance Taylor <ian@cygnus.com>
+To: bug-libtool@gnu.org
+Subject: cygwin32 support in libtool
+Lines: 290
+Xref: trick.profitpress.com mail.libtool:1336
+
+Here are the libtool patches I've worked up for cygwin32 support.
+These should be relative to the 1.2 release.
+
+These patches have some bogosities.
+
+I needed to build a C file to compile when building the DLL.  That C
+file naturally includes semicolons.  I could not figure out how to get
+a semicolon into archive_cmds; the various approaches I tried all
+failed, because ltmain splits archive_cmds at semicolons.  So I wound
+up just creating libtool.c in ltconfig.  This libtool.c file never
+gets deleted.
+
+Both archive_cmds and old_archive_from_new_cmds need to use the same
+definitions file.  I created it in archive_cmds and deleted it in
+old_archive_from_new_cmds.
+
+Ian
+
+Index: ltconfig.in
+===================================================================
+RCS file: /cvs/cvsfiles/devo/libtool/ltconfig.in,v
+retrieving revision 1.6
+retrieving revision 1.8
+diff -p -r1.6 -r1.8
+*** ltconfig.in	1998/03/23 18:28:53	1.6
+--- ltconfig.in	1998/04/17 20:20:13	1.8
+*************** old_LD="$LD"
+*** 97,102 ****
+--- 97,104 ----
+  old_LN_S="$LN_S"
+  old_NM="$NM"
+  old_RANLIB="$RANLIB"
++ old_DLLTOOL="$DLLTOOL"
++ old_AS="$AS"
+  
+  # Parse the command line options.
+  args=
+*************** if test -n "$RANLIB"; then
+*** 351,356 ****
+--- 353,362 ----
+    old_postinstall_cmds="\$RANLIB \$oldlib;$old_postinstall_cmds"
+  fi
+  
++ # Set sane defaults for `DLLTOOL' and `AS', used on cygwin32.
++ test -z "$DLLTOOL" && DLLTOOL=dlltool
++ test -z "$AS" && AS=as
++ 
+  # Check to see if we are using GCC.
+  if test "$with_gcc" != yes || test -z "$CC"; then
+    # If CC is not set, then try to find GCC or a usable CC.
+*************** if test "$with_gcc" = yes; then
+*** 456,462 ****
+    aix3* | aix4* | irix5* | irix6* | osf3* | osf4*)
+      # PIC is the default for these OSes.
+      ;;
+!   os2*)
+      # We can build DLLs from non-PIC.
+      ;;
+    amigaos*)
+--- 462,468 ----
+    aix3* | aix4* | irix5* | irix6* | osf3* | osf4*)
+      # PIC is the default for these OSes.
+      ;;
+!   cygwin32* | os2*)
+      # We can build DLLs from non-PIC.
+      ;;
+    amigaos*)
+*************** else
+*** 490,496 ****
+      # PIC (with -KPIC) is the default.
+      ;;
+  
+!   os2*)
+      # We can build DLLs from non-PIC.
+      ;;
+  
+--- 496,502 ----
+      # PIC (with -KPIC) is the default.
+      ;;
+  
+!   cygwin32* | os2*)
+      # We can build DLLs from non-PIC.
+      ;;
+  
+*************** hardcode_shlibpath_var=unsupported
+*** 702,708 ****
+  runpath_var=
+  
+  case "$host_os" in
+! amigaos* | sunos4*)
+    # On these operating systems, we should treat GNU ld like the system ld.
+    gnu_ld_acts_native=yes
+    ;;
+--- 708,714 ----
+  runpath_var=
+  
+  case "$host_os" in
+! amigaos* | sunos4* | cygwin32*)
+    # On these operating systems, we should treat GNU ld like the system ld.
+    gnu_ld_acts_native=yes
+    ;;
+*************** else
+*** 756,761 ****
+--- 762,788 ----
+      hardcode_minus_L=yes
+      ;;
+  
++   cygwin32*)
++     # hardcode_libdir_flag_spec is actually meaningless, as there is
++     # no search path for DLLs.
++     hardcode_libdir_flag_spec='-L$libdir'
++     allow_undefined_flag=unsupported
++     # Very, very bogus.
++     echo '
++ #include <windows.h>
++ 
++ struct _reent *_impure_ptr;
++ extern struct _reent *__imp_reent_data;
++ BOOL APIENTRY
++ __dll_entry (HINSTANCE hinst, DWORD reason, LPVOID reserved)
++ {
++   _impure_ptr = __imp_reent_data;
++ }
++ ' > libtool.c
++     archive_cmds='$CC -c libtool.c;echo EXPORTS > $soname-def;$NM$libobjs | $global_symbol_pipe | sed '\''s/.* //'\'' >> $soname-def;$LD -s --base-file $soname-base --dll -e ___dll_entry@12 -o $lib libtool.o$libobjs$deplibs;$DLLTOOL --as=$AS --dllname $soname --def $soname-def --base-file $soname-base --output-exp $soname-exp;$LD -s --base-file $soname-base $soname-exp --dll -e ___dll_entry@12 -o $lib libtool.o$libobjs$deplibs;$DLLTOOL --as=$AS --dllname $soname --def $soname-def --base-file $soname-base --output-exp $soname-exp;$LD $soname-exp --dll -e ___dll_entry@12 -o $lib libtool.o$libobjs$deplibs;$rm libtool.o $soname-base $soname-exp'
++     old_archive_from_new_cmds='$DLLTOOL --as=$AS --dllname $soname --def $soname-def --output-lib $objdir/$libname.a;$rm $soname-def'
++     ;;
++ 
+    # FreeBSD 2.2.[012] allows us to include c++rt0.o to get C++ constructor
+    # support.  Future versions do this automatically, but an explicit c++rt0.o
+    # does not break anything, and helps significantly (at the cost of a little
+*************** case "$host_os" in
+*** 936,941 ****
+--- 963,972 ----
+  aix*)
+    symcode='[BCDTU]'
+    ;;
++ cygwin32*)
++   sympat='_\([_A-Za-z][_A-Za-z0-9]*\)'
++   symxfrm='_\1 \1'
++   ;;
+  irix*)
+    # Cannot use undefined symbols on IRIX because inlined functions mess us up.
+    symcode='[BCDEGRST]'
+*************** if $NM -V 2>&1 | egrep '(GNU|with BFD)' 
+*** 950,955 ****
+--- 981,994 ----
+    symcode='[ABCDGISTUW]'
+  fi
+  
++ case "$host_os" in
++ cygwin32*)
++   # We do not want undefined symbols on cygwin32.  The user must
++   # arrange to define them via -l arguments.
++   symcode='[ABCDGISTW]'
++   ;;
++ esac
++ 
+  # Write the raw and C identifiers.
+  global_symbol_pipe="sed -n -e 's/^.* $symcode $sympat$/$symxfrm/p'"
+  
+*************** amigaos*)
+*** 1123,1128 ****
+--- 1162,1174 ----
+    finish_eval='for lib in `ls $libdir/*.ixlibrary 2>/dev/null`; do libname=`$echo "X$lib" | $Xsed -e '\''s%^.*/\([^/]*\)\.ixlibrary$%\1%'\''`; test $rm /sys/libs/${libname}_ixlibrary.a; $show "(cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a)"; (cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a) || exit 1; done'
+    ;;
+  
++ cygwin32*)
++   version_type=windows
++   library_names_spec='${libname}`echo ${release} | sed -e 's/[.]/-/g'`${versuffix}.dll $libname.a'
++   dynamic_linker='Win32 ld.exe'
++   shlibpath_var=PATH
++   ;;
++ 
+  freebsd2* | freebsd3*)
+    version_type=sunos
+    library_names_spec='${libname}${release}.so.$versuffix $libname.so'
+*************** ltecho="$echo"
+*** 1285,1293 ****
+  
+  # Now quote all the things that may contain metacharacters.
+  for var in ltecho old_CC old_CFLAGS old_CPPFLAGS old_LD old_NM old_RANLIB \
+!   old_LN_S AR CC LD LN_S NM reload_flag reload_cmds wl pic_flag \
+!   link_static_flag no_builtin_flag export_dynamic_flag_spec \
+!   libname_spec library_names_spec soname_spec RANLIB \
+    old_archive_cmds old_archive_from_new_cmds old_postinstall_cmds \
+    old_postuninstall_cmds archive_cmds postinstall_cmds postuninstall_cmds \
+    allow_undefined_flag no_undefined_flag \
+--- 1331,1339 ----
+  
+  # Now quote all the things that may contain metacharacters.
+  for var in ltecho old_CC old_CFLAGS old_CPPFLAGS old_LD old_NM old_RANLIB \
+!   old_LN_S old_DLLTOOL old_AS AR CC LD LN_S NM DLLTOOL AS reload_flag \
+!   reload_cmds wl pic_flag link_static_flag no_builtin_flag \
+!   export_dynamic_flag_spec libname_spec library_names_spec soname_spec RANLIB \
+    old_archive_cmds old_archive_from_new_cmds old_postinstall_cmds \
+    old_postuninstall_cmds archive_cmds postinstall_cmds postuninstall_cmds \
+    allow_undefined_flag no_undefined_flag \
+*************** cat <<EOF > $ofile
+*** 1345,1350 ****
+--- 1391,1397 ----
+  #
+  # CC="$old_CC" CFLAGS="$old_CFLAGS" CPPFLAGS="$old_CPPFLAGS" \\
+  # LD="$old_LD" NM="$old_NM" RANLIB="$old_RANLIB" LN_S="$old_LN_S" \\
++ # DLLTOOL="$old_DLLTOOL" AS="$old_AS" \\
+  #   $0$ltconfig_args
+  #
+  # Compiler and other test output produced by $progname, useful for
+*************** LN_S="$LN_S"
+*** 1390,1395 ****
+--- 1437,1448 ----
+  
+  # A BSD-compatible nm program.
+  NM="$NM"
++ 
++ # Used on cygwin32: DLL creation program.
++ DLLTOOL="$DLLTOOL"
++ 
++ # Used on cygwin32: assembler.
++ AS="$AS"
+  
+  # The name of the directory that contains temporary libtool files.
+  objdir="$objdir"
+Index: ltmain.in
+===================================================================
+RCS file: /cvs/cvsfiles/devo/libtool/ltmain.in,v
+retrieving revision 1.3
+retrieving revision 1.4
+diff -p -r1.3 -r1.4
+*** ltmain.in	1998/03/20 23:35:33	1.3
+--- ltmain.in	1998/04/17 20:20:14	1.4
+*************** if test -z "$show_help"; then
+*** 967,972 ****
+--- 967,980 ----
+          versuffix="$current.$revision"
+          ;;
+  
++       windows)
++         # Like Linux, but with '-' rather than '.', and with a leading
++         # '-', since we only want one extension on Windows 95.
++         version_vars="$version_vars major versuffix"
++         major=`expr $current - $age`
++         versuffix="-$major-$age-$revision"
++         ;;
++ 
+        *)
+          $echo "$modename: unknown library version type \`$version_type'" 1>&2
+          echo "Fatal configuration error.  See the $PACKAGE docs for more information." 1>&2
+Index: libtool.m4
+===================================================================
+RCS file: /cvs/cvsfiles/devo/libtool/libtool.m4,v
+retrieving revision 1.11
+retrieving revision 1.12
+diff -p -r1.11 -r1.12
+*** libtool.m4	1998/04/13 16:09:14	1.11
+--- libtool.m4	1998/04/13 20:44:46	1.12
+*************** case "$host" in
+*** 70,80 ****
+--- 70,86 ----
+    # On SCO OpenServer 5, we need -belf to get full-featured binaries.
+    CFLAGS="$CFLAGS -belf"
+    ;;
++ 
++ *-*-cygwin32*)
++   AM_SYS_LIBTOOL_CYGWIN32
++   ;;
++ 
+  esac
+  
+  # Actually configure libtool.  ac_aux_dir is where install-sh is found.
+  CC="$CC" CFLAGS="$CFLAGS" CPPFLAGS="$CPPFLAGS" \
+  LD="$LD" NM="$NM" RANLIB="$RANLIB" LN_S="$LN_S" \
++ DLLTOOL="$DLLTOOL" AS="$AS" \
+  ${CONFIG_SHELL-/bin/sh} $ac_aux_dir/ltconfig \
+  $libtool_flags --no-verify $ac_aux_dir/ltmain.sh $host \
+  || AC_MSG_ERROR([libtool configure failed])
+*************** fi])
+*** 255,258 ****
+--- 261,270 ----
+  NM="$ac_cv_path_NM"
+  AC_MSG_RESULT([$NM])
+  AC_SUBST(NM)
++ ])
++ 
++ # AM_SYS_LIBTOOL_CYGWIN32 - find tools needed on cygwin32
++ AC_DEFUN(AM_SYS_LIBTOOL_CYGWIN32,
++ [AC_CHECK_TOOL(DLLTOOL, dlltool, false)
++ AC_CHECK_TOOL(AS, as, false)
+  ])
+
diff --git a/mail/deplibs b/mail/deplibs
new file mode 100644
index 00000000..c757ec65
--- /dev/null
+++ b/mail/deplibs
@@ -0,0 +1,604 @@
+From nobody Wed Oct 14 16:43:54 1998
+X-From-Line: badger@prtr-13.ucsc.edu Sat Mar 07 06:09:15 1998
+Return-Path: <badger@prtr-13.ucsc.edu>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 29304 invoked from network); 7 Mar 1998 06:09:10 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 7 Mar 1998 06:09:10 -0000
+Received: from mail.cwo.com (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id WAA18468 for <gord@m-tech.ab.ca>; Fri, 6 Mar 1998 22:55:43 -0700
+Received: from Greyeyes.ucsc.edu (badger@port-sac31.cwo.com [207.173.173.146])
+	by mail.cwo.com (8.8.8/8.8.8) with ESMTP id VAA08756
+	for <gord@m-tech.ab.ca>; Fri, 6 Mar 1998 21:59:21 -0800
+Received: (from badger@localhost)
+	by Greyeyes.ucsc.edu (8.8.7/8.8.7) id VAA27714;
+	Fri, 6 Mar 1998 21:54:09 -0800
+Message-ID: <19980306215408.59334@prtr-13.ucsc.edu>
+Date: Fri, 6 Mar 1998 21:54:08 -0800
+From: Toshio Kuratomi <badger@prtr-13.ucsc.edu>
+To: Gordon Matzigkeit <gord@m-tech.ab.ca>
+Subject: Re: InterLibrary Dependency
+References: <19980225175901.56084@prtr-13.ucsc.edu> <8690qzyqqx.fsf@trick.profitpress.com> <19980225214804.59179@prtr-13.ucsc.edu> <863eh2547a.fsf@trick.profitpress.com> <19980303213204.27408@prtr-13.ucsc.edu> <86k9a9du5z.fsf@trick.profitpress.com>
+Mime-Version: 1.0
+Content-Type: multipart/signed; protocol="application/pgp-signature";
+	micalg=pgp-md5; boundary="Ew/8QCHSq3SnV5pl"
+X-Mailer: Mutt 0.88
+In-Reply-To: <86k9a9du5z.fsf@trick.profitpress.com>; from Gordon Matzigkeit on Thu, Mar 05, 1998 at 08:38:48AM -0700
+Lines: 366
+Xref: trick.profitpress.com mail.libtool:1135
+
+
+--Ew/8QCHSq3SnV5pl
+Content-Type: multipart/mixed; boundary="D7pdK0Ng3jPPYy/f"
+
+
+--D7pdK0Ng3jPPYy/f
+Content-Type: text/plain; charset=us-ascii
+
+Okay!  Here's a complete patch!  It works well for me -- I haven't had it do
+anything unexpected.
+
+The best thing to do is probably just to look at the patch itself.  But the
+basic architecture is this:
+in ltconfig.in, the person who writes libtool makes sure $deplibs is included
+in $archive_cmds somewhere and also sets the $check_shared_deplibs_method.
+check_shared_deplibs_method can be any of five things:
+    test_compile
+    file_regex
+    file_magic [regex]
+    pass_all
+    none
+
+I think that file_magic works the best:  It looks in the library link path for
+libraries that have the right libname.  Then it runs file on the library and
+checks for a match against [regex] using expr.  I currently have linux-elf
+looking for the string: "ELF 32-bit LSB shared object" which seems to work well.
+(I don't know whether the "32-bit" would have to change on linux-alpha
+though....  change to 'ELF [0-9]+-bit LSB shared object' might work.  I don't
+know.)
+
+file_regex will look for a filename in the link path.  It doesn't take an
+argument because I use the libname_spec and library_names_spec variables to
+create the string to look for.  I don't like it because symlinks and random
+files can make it give false positives.
+
+test_compile has been overhauled since the last patch.  It now handles -L
+correctly, I hope.  It also takes the names of it's libraries from
+libname_spec instead of a hardcoded lib`expr $a_deplib : '-l/(.*/)'`.so line.
+
+pass_all will pass everything without any checking.  I put it in because
+osf3&4 appear to be treated that way right now... It might be wise to perform
+checks here to see if the libraries exist on the system, but I don't know how
+osf3&4 handle that, so I thought it would be better just to do it the way the
+current code does.
+
+none is the default for all systems unless overridden in ltconfig.in
+(Currently, linux-elf is the only system that overrides.)  It causes deplibs
+to be reassigned deplibs="".  That way archive_cmds can contain deplibs on all
+platforms, but not have deplibs used unless needed.
+
+Okay:: Then in ltmain.in we have the real workhorse: a litle initialization
+and postprocessing (to setup/release variables for use with eval echo
+libname_spec etc.) and a case statement that decides which method is being
+used.  This is the real code... I wish I could condense it a little more, but
+I don't think I can without function calls.  I've mostly optimized it (moved
+things out of loops, etc.) but there is probably some fat left.  I thought I
+should stop while I was ahead, work on whatever bugs you discover, etc before
+thinking about more than obvious optimizations.
+
+Uhm... Anything else?  Ahh -- I can't seem to access my mail server right now,
+I have a feeling the network between it and the outside world has gone down
+again.  I hope this situation is resolved soon, but I have no assurancances
+(These things always happen on a Friday, no?)
+
+If you need to reach me and your mail bounces off my normal address, you can
+send mail to my parent's account mrk-chri@cwo.com and they'll see that I get
+it.
+
+-Toshio
+
+(This patch is against libtool-1.0i)
+-- 
+badger  \"The Difference between today and yesterday is not so much what has
+@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
+.ucsc.edu  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
+
+--D7pdK0Ng3jPPYy/f
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: attachment; filename="libtool-interlibdep.diff"
+
+--- libtool-1.0i/ltconfig.in.orig	Fri Feb  6 00:23:19 1998
++++ libtool-1.0i/ltconfig.in	Fri Mar  6 20:34:39 1998
+@@ -709,7 +709,7 @@
+ 
+   # See if GNU ld supports shared libraries.
+   if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+-    archive_cmds='$CC -shared ${wl}-soname $wl$soname -o $lib$libobjs'
++    archive_cmds='$CC -shared ${wl}-soname $wl$soname -o $lib$libobjs$deplibs'
+     runpath_var=LD_RUN_PATH
+     ld_shlibs=yes
+   else
+@@ -1098,6 +1098,19 @@
+ shlibpath_var=
+ version_type=none
+ dynamic_linker="$host_os ld.so"
++check_shared_deplibs_method='none'
++# Need to set the preceding variable on all platforms that support
++# interlibrary dependencies.
++# 'none' -- dependencies disabled.
++# 'pass_all' -- all dependencies passed with no checks.
++# 'test_compile' -- check by making test program.
++# 'file_regex' -- check by looking for filenames that look like the shared
++# library in the library path.
++# 'file_magic [regex]' -- check by looking for files in library path which
++# responds to the "file" command with a given regex.  This is actually a
++# superset of the file_regex command.  If you have file on your system, you'll
++# want to use this instead.
++# Notes: regexes are run through expr.
+ 
+ echo $ac_n "checking dynamic linker characteristics... $ac_c" 1>&6
+ case "$host_os" in
+@@ -1160,6 +1173,7 @@
+   soname_spec='${libname}${release}.so.$major'
+   finish_cmds='PATH="$PATH:/sbin" ldconfig -n $libdir'
+   shlibpath_var=LD_LIBRARY_PATH
++  check_shared_deplibs_method='file_magic ELF 32-bit LSB shared object'
+ 
+   if test -f /lib/ld.so.1; then
+     dynamic_linker='GNU ld.so'
+@@ -1191,6 +1205,7 @@
+   soname_spec='${libname}${release}.so'
+   library_names_spec='${libname}${release}.so.$versuffix $libname.so'
+   shlibpath_var=LD_LIBRARY_PATH
++  check_shared_deplibs_method='pass_all'
+   ;;
+ 
+ sco3.2v5*)
+@@ -1411,6 +1426,9 @@
+ archive_cmds="$archive_cmds"
+ postinstall_cmds="$postinstall_cmds"
+ postuninstall_cmds="$postuninstall_cmds"
++
++# Method to check whether dependent libraries are shared objects.
++check_shared_deplibs_method="$check_shared_deplibs_method"
+ 
+ # Flag that allows shared libraries with undefined symbols to be built.
+ allow_undefined_flag="$allow_undefined_flag"
+--- libtool-1.0i/ltmain.in.orig	Fri Feb  6 00:06:22 1998
++++ libtool-1.0i/ltmain.in	Fri Mar  6 20:56:51 1998
+@@ -363,6 +363,9 @@
+     compile_shlibpath=
+     finalize_shlibpath=
+     deplibs=
++    extradeplibs=
++    lib_search_path="/lib /usr/lib"
++    
+     dlfiles=
+     dlprefiles=
+     export_dynamic=no
+@@ -492,9 +495,12 @@
+           ;;
+         esac
+         deplibs="$deplibs $arg"
++        extradeplibs="$extradeplibs $arg"
++        lib_search_path="$lib_search_path `expr $arg : '-L\(.*\)'`"
+         ;;
+ 
+       -l*) deplibs="$deplibs $arg" ;;
++      -El*) extradeplibs="$extradeplibs -`expr $arg : '-E\(.*\)'`" ;;
+ 
+       -no-undefined)
+ 	allow_undefined=no
+@@ -987,6 +993,185 @@
+       fi
+ 
+       if test "$build_libtool_libs" = yes; then
++        # Transform deplibs into only deplibs that can be linked in shared.
++        ## Gordon: Do you check for the existence of the libraries in deplibs
++        ## on the system?  That should maybe be merged in here someplace....
++        ## Actually: I think test_compile and file_magic do this... file_regex
++        ## sorta does this. Only pas_all needs to be changed.  -Toshio
++        name_save=$name
++        libname_save=$libname
++        release_save=$release
++        versuffix_save=$versuffix
++        major_save=$major
++        # I'm not sure if I'm treating the release correctly.  I think
++        # release should show up in the -l (ie -lgmp5) so we don't want to
++        # add it in twice.  Is that correct?
++        release=""
++        versuffix=""
++        major=""
++        newdeplibs=
++        case "$check_shared_deplibs_method" in
++        pass_all)   ;; # Don't check for shared/static.  Everything works.
++                       # This might be a little naive.  We might want to check
++                       # whether the library exists or not.  But this is on
++                       # osf3 & osf4 and I'm not really sure... Just
++                       # implementing what was already the behaviour.
++        test_compile)
++          # This code stresses the "libraries are programs" paradigm to its
++          # limits. Maybe even breaks it.  We compile a program, linking it
++          # against the deplibs as a proxy for the library.  Then we can check
++          # whether they linked in statically or dynamically with ldd.
++          $rm conftest.c
++          cat > conftest.c <<EOF
++          int main() { return 0; }
++EOF
++          $rm a.out
++          $CC conftest.c $deplibs $extradeplibs
++          if test $? -eq 0 ; then
++            ldd_output=`ldd a.out`
++            for i in $deplibs; do
++              name="`expr $i : '-l\(.*\)'`"
++              # If $name is empty we are operating on a -L argument.
++              if test "$name" != "" ; then
++                libname=`eval \\$echo \"$libname_spec\"`
++                deplib_matches=`eval \\$echo \"$library_names_spec\"`
++                set dummy $deplib_matches
++                deplib_match=$2
++                if test `expr "$ldd_output" : ".*$deplib_match"` -ne 0 ; then
++                  newdeplibs="$newdeplibs $i"
++                else
++                  echo
++                  echo "*** Warning: This library needs some functionality provided by $i."
++                  echo "*** I have the capability to make that library automatically link in when"
++                  echo "*** you link to this library.  But I can only do this if you have a"
++                  echo "*** shared version of the library, which you do not appear to have."
++                fi
++              else
++                newdeplibs="$newdeplibs $i"
++              fi
++            done
++          else
++          # Error occured in the first compile.  Let's try to salvage the situation:
++            # 1) Is the error in the extradeplibs?
++            $rm a.out
++            $CC conftest.c $extradeplibs
++            if test $? -ne 0 ; then
++              echo
++              echo "*** Warning! Not all libraries necessary to the dependent libraries are"
++              echo "*** working!  You will probably need to install some of:"
++              echo "*** $extradeplibs"
++              echo "*** before this library will be fully functional.  Installing these"
++              echo "***  libraries before continuing would be even better."
++              newextradeplibs=
++              for i in $extradeplibs; do
++                if test `expr "$i" : '-L'` -ne 0 ; then
++                  newextradeplibs="$newextradeplibs $i"
++                fi
++              done
++              extradeplibs=$newextradeplibs
++            fi
++            # 2) Compile a seperate program for each library.
++            for i in $deplibs; do
++              name="`expr $i : '-l\(.*\)'`"
++             # If $name is empty we are operating on a -L argument.
++              if test "$name" != "" ; then
++                $rm a.out
++                $CC conftest.c $i $extradeplibs
++                # Did it work?
++                if test $? -eq 0 ; then
++                  ldd_output=`ldd a.out`
++                    libname=`eval \\$echo \"$libname_spec\"`
++                    deplib_matches=`eval \\$echo \"$library_names_spec\"`
++                    set dummy $deplib_matches
++                    deplib_match=$2
++                    if test `expr "$ldd_output" : ".*$deplib_match"` -ne 0 ; then
++                      newdeplibs="$newdeplibs $i"
++                    else
++                      echo
++                      echo "*** Warning: This library needs some functionality provided by $i."
++                      echo "*** I have the capability to make that library automatically link in when"
++                      echo "*** you link to this library.  But I can only do this if you have a"
++                      echo "*** shared version of the library, which you do not appear to have."
++                    fi
++                else
++                  echo
++                  echo "*** Warning!  Library $i is needed by this library but I was not able to"
++                  echo "***  make it link in!  You will probably need to install it or some"
++                  echo "*** library that it depends on before this library will be fully"
++                  echo "*** functional.  Installing it before continuing would be even better."
++                fi
++              else
++                newdeplibs="$newdeplibs $i"
++              fi
++            done
++          fi
++          deplibs=$newdeplibs
++          ;;
++        file_magic* | file_regex)
++          set dummy $check_shared_deplibs_method
++          file_magic_regex="`expr \"$check_shared_deplibs_method\" : \"$2\(.*\)\"`"
++          for a_deplib in $deplibs; do
++            name="`expr $a_deplib : '-l\(.*\)'`"
++            # If $name is empty we are operating on a -L argument.
++            if test "$name" != "" ; then
++              libname=`eval \\$echo \"$libname_spec\"`
++              case "$check_shared_deplibs_method" in
++                file_magic*)
++                  for i in $lib_search_path; do
++                   # This needs to be more general than file_regex in order to
++                   # catch things like glibc on linux.  Maybe file_regex
++                   # should be more general as well, but maybe not.  Since
++                   # library names are supposed to conform to
++                   # library_name_spec, I think file_regex should remain
++                   # strict.  What do you think Gordon?
++                    potential_libs=`ls $i/$libname[.-]* 2>/dev/null`
++                    for potent_lib in $potential_libs; do
++                      file_output=`file $potent_lib`
++                      if test `expr "$file_output" : ".*$file_magic_regex"` -ne 0 ; then
++                        newdeplibs="$newdeplibs $a_deplib"
++                        a_deplib=""
++                        break 2
++                      fi
++                    done
++                  done
++                  ;;
++                file_regex)
++                  deplib_matches=`eval \\$echo \"$library_names_spec\"`
++                  set dummy $deplib_matches
++                  deplib_match=$2
++                  for i in $lib_search_path; do
++                    potential_libs=`ls $i/$deplib_match* 2>/dev/null`
++                    if test "$potential_libs" != "" ; then
++                      newdeplibs="$newdeplibs $a_deplib"
++                      a_deplib=""
++                      break
++                    fi
++                  done
++                  ;;
++              esac
++              if test "$a_deplib" != "" ; then
++                echo
++                echo "*** Warning: This library needs some functionality provided by $a_deplib."
++                echo "*** I have the capability to make that library automatically link in when"
++                echo "*** you link to this library.  But I can only do this if you have a"
++                echo "*** shared version of the library, which you do not appear to have."
++              fi
++            else
++              # Add a -L argument.
++              newdeplibs="$newdeplibs $a_deplib"
++            fi
++          done # Gone through all deplibs.
++          ;;
++        none | *)  deplibs="" ;;
++        esac
++        versuffix=$versuffix_save
++        major=$major_save
++        release=$release_save
++        libname=$libname_save
++        name=$name_save
++        deplibs=$newdeplibs
++       # Done checking deplibs!
++
+         # Get the real and link names of the library.
+         library_names=`eval \\$echo \"$library_names_spec\"`
+         set dummy $library_names
+
+--D7pdK0Ng3jPPYy/f--
+
+--Ew/8QCHSq3SnV5pl
+Content-Type: application/pgp-signature
+
+-----BEGIN PGP SIGNATURE-----
+Version: 2.6.3ia
+
+iQCVAwUBNQDg/2I4kZK9uLMpAQGQfwQAo5wbFpHA4588S6R+zTjgIYPa1caMFZhM
+ehwKr0JSyu8mSkp9tSavavTkyq/AE6+NnvZeNU5NpWxvfCk32f5lhEzWaU69HFfy
+CjpxiDUi/74EeQrobfchoYeC6KhN66Y6JsSi1ayZa52P7hFibS674ORVXxw2zNq3
+NUfJkmb2mTY=
+=q0bH
+-----END PGP SIGNATURE-----
+
+--Ew/8QCHSq3SnV5pl--
+
+From nobody Wed Oct 14 16:45:01 1998
+X-From-Line: ian@cygnus.com Fri Apr 17 23:33:18 1998
+Return-Path: <ian@cygnus.com>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 23427 invoked from network); 17 Apr 1998 23:33:17 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 17 Apr 1998 23:33:17 -0000
+Received: from tweedledumb.cygnus.com (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id OAA06912 for <gord@profitpress.com>; Fri, 17 Apr 1998 14:17:39 -0600
+Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
+	by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id QAA18613;
+	Fri, 17 Apr 1998 16:18:12 -0400 (EDT)
+Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id QAA08387; Fri, 17 Apr 1998 16:18:11 -0400
+Date: Fri, 17 Apr 1998 16:18:11 -0400
+Message-Id: <199804172018.QAA08387@subrogation.cygnus.com>
+From: Ian Lance Taylor <ian@cygnus.com>
+To: gord@profitpress.com
+CC: bug-libtool@gnu.org
+In-reply-to: <86k98oh6fy.fsf@trick.profitpress.com> (message from Gordon
+	Matzigkeit on 17 Apr 1998 08:24:33 -0600)
+Subject: Re: libtool on cygwin32
+Lines: 30
+Xref: trick.profitpress.com mail.libtool:1335
+
+   From: Gordon Matzigkeit <gord@profitpress.com>
+   Date: 17 Apr 1998 08:24:33 -0600
+
+   >>>>> Ian Lance Taylor writes:
+
+   [...]
+
+    ILT> So, my choices are to use -no-undefined -lbfd everywhere, or to
+    ILT> use it only on Windows.
+
+   Would `-avoid-deps' (a proposed flag) give you what you want?
+
+   default = record inter-library dependencies on all platforms, if
+   possible.
+
+   -no-undefined = the dependency info provided is complete.  Build
+   shared libraries on AIX and windows.
+
+   -avoid-deps = implies `-no-undefined'.  However, avoid recording
+   inter-library dependencies unless they are required for building a
+   shared library.
+
+Yes, that sounds like it will do what I need.
+
+Somebody someday may want to record some library dependencies but not
+others, in which case you would want
+    -avoid-deps -lfoo -no-avoid-deps -lbar
+
+Ian
+
+From nobody Wed Oct 14 16:45:40 1998
+X-From-Line: ian@cygnus.com Mon Apr 27 16:24:19 1998
+Return-Path: <ian@cygnus.com>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 136 invoked from network); 27 Apr 1998 16:24:18 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by localhost with SMTP; 27 Apr 1998 16:24:18 -0000
+Received: from tweedledumb.cygnus.com (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id JAA21924 for <gord@m-tech.ab.ca>; Mon, 27 Apr 1998 09:42:43 -0600
+Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
+	by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id LAA02934;
+	Mon, 27 Apr 1998 11:48:04 -0400 (EDT)
+Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id LAA01776; Mon, 27 Apr 1998 11:48:03 -0400
+Date: Mon, 27 Apr 1998 11:48:03 -0400
+Message-Id: <199804271548.LAA01776@subrogation.cygnus.com>
+From: Ian Lance Taylor <ian@cygnus.com>
+To: gord@m-tech.ab.ca
+CC: robbe@orcus.priv.at, bug-libtool@gnu.org
+In-reply-to: <86bttpvbqd.fsf@trick.profitpress.com> (message from Gordon
+	Matzigkeit on 25 Apr 1998 15:21:30 -0600)
+Subject: Re: libtool 1.2: Why no inter-lib dependencies on ELF?
+Lines: 27
+Xref: trick.profitpress.com mail.libtool:1388
+
+   From: Gordon Matzigkeit <gord@m-tech.ab.ca>
+   Date: 25 Apr 1998 15:21:30 -0600
+
+   There are still some unresolved issues (see
+   http://www.profitpress.com/libtool/deplibs.html).  Full inter-library
+   dependency support is scheduled for libtool 1.3, though, and should
+   appear in the next beta-testing release.
+
+I read that page, and here are a few quick notes.
+
+1) On any platform which does not require -fpic you can link
+static libraries into shared libraries.  These platforms include
+AIX, Irix 5/6, and Windows.
+
+2) On any functioning ELF platform you can include code which was not
+compiled with -fpic in a shared library, and you can link with a
+static library when creating a shared library.  You say that Solaris
+won't let you link a shared library against a static one, but it
+appears to work for me.  What type of test are you using?
+
+3) On SunOS you can not correctly link a static library into a shared
+library.  It will mostly work, but I believe that certain operations,
+such as overriding a shared library function in the main executable,
+will fail.
+
+Ian
+
+From nobody Wed Oct 14 16:48:43 1998
+X-From-Line: gord@gnu.org Thu Sep 10 04:39:20 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 30644 invoked from network); 10 Sep 1998 04:39:18 -0000
+Received: from gen2-93ip34.cadvision.com (HELO bambam.m-tech.ab.ca) (209.91.93.34)
+  by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 10 Sep 1998 04:39:18 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id WAA26741 for <gord@m-tech.ab.ca>; Wed, 9 Sep 1998 22:38:15 -0600
+Received: from mailhost.cyberramp.net (root@mailhost.cyberramp.net [207.158.64.11]) by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id AAA11165 for <bug-libtool@gnu.org>; Thu, 10 Sep 1998 00:38:17 -0400
+Received: from fuzzylog.simple.dallas.tx.us (dal-tsa11-49.cyberramp.net [207.158.111.49])
+	by mailhost.cyberramp.net (8.9.1a/8.9.1/ler-980825-0832-PM) with ESMTP id XAA13581;
+	Wed, 9 Sep 1998 23:37:41 -0500 (CDT)
+Received: from scooby (scooby [192.168.1.3])
+	by fuzzylog.simple.dallas.tx.us (8.8.8/8.8.8) with SMTP id XAA27692;
+	Wed, 9 Sep 1998 23:37:38 -0500 (CDT)
+Date: Wed, 9 Sep 1998 23:37:38 -0500 (CDT)
+From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
+To: Libtool Bugs <bug-libtool@gnu.org>
+Subject: Late-binding looses space efficiency ...
+Message-ID: <Pine.SO4.4.02.9809092322490.808-100000@scooby.simple.dallas.tx.us>
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+Lines: 27
+Xref: trick.fig.org libtool:1605
+
+On most systems, libtool does not supply the dependency libraries (-llib) when
+it creates the shared library in spite of these being supplied on the libtool
+command line.  The ImageMagick package uses quite a few dependency libraries.
+The ImageMagick library uses these libraries directly but utilities built
+using the ImageMagick library only link against these libraries because the
+ImageMagick library demands it.
+
+Through testing we have found that if the 'ltconfig' archive_cmds definition
+is ammended to include $deplibs that linked programs become much smaller (1/3
+to 1/4 the original size).  This appears to be because more code is included
+in the shared library itself, avoiding the need for this to be part of the
+program.
+
+The distributed 'ltconfig' only supplies $deplibs for systems matching osf3* |
+osf4*. Is there a reason why $deplibs is not supplied for all systems that can
+support inter-library dependencies?  Reducing overall package size is highly
+desireable in order to reduce disk-space consumption and binary distribution
+size.
+
+Thanks,
+
+Bob
+======================================
+Bob Friesenhahn
+bfriesen@simple.dallas.tx.us
+http://www.cyberramp.net/~bfriesen
+
+From nobody Wed Oct 14 16:52:40 1998
+X-From-Line: ddj@hks.net Thu Sep 17 21:29:13 1998
+Return-Path: <ddj@hks.net>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 22994 invoked by uid 1003); 17 Sep 1998 21:29:12 -0000
+Delivered-To: jana-profitpress-gord@profitpress.com
+Received: (qmail 22991 invoked from network); 17 Sep 1998 21:29:11 -0000
+Received: from dali.hks.net (ddj@208.203.175.210)
+  by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 17 Sep 1998 21:29:11 -0000
+Received: (from ddj@localhost)
+	by dali.hks.net (8.8.5/8.8.5) id RAA04020;
+	Thu, 17 Sep 1998 17:26:28 -0400
+Received: from BatMail.robin.v2.15.CUILIB.3.45.SNAP.NOT.LINKED.dali..none..ix86.Linux
+          via MS.5.6.dali.(none).ix86_Linux;
+          Thu, 17 Sep 1998 17:26:27 -0400 (EDT)
+Message-ID: <oq0Lu3Jz000185PkIG@hks.net>
+Date: Thu, 17 Sep 1998 17:26:27 -0400 (EDT)
+From: Doug DeJulio <ddj@hks.net>
+To: gord@profitpress.com
+Subject: Re: Libtool Inter-library Dependencies
+Lines: 32
+Xref: trick.fig.org libtool:1611
+
+I read your discussion of why libtool can't handle inter-library
+dependencies and how people might be able to help fix this.  I found
+an error in item #1 of "The Solution".  I quote:
+
+> Finally, there are some systems which won't even allow you to link a
+> shared library against a static one: 
+>          Solaris 2.x 
+
+This is only true in most cases.  If all of the accessed individual
+object files in the static library *could* have been put in a shared
+library, things will work just fine.  It's not the type of library
+that matters, but the type of object files.
+
+Our commercial product includes a library and a few
+dynamically-loadable modules that make that library accessible to
+various interpretetd languages (TCL, Perl, PHP3 and Python at the
+moment, with more coming).  We don't distribute a shared library
+anymore because when we did this caused a ton of trouble (most people
+just couldn't get it configured correctly).  I haven't yet found a
+platform on which linking dynamically-loadable object file against a
+static "ar" archive containing relocatable object files causes any
+trouble (and we support SCO, Digital Unix, SCO, Solaris, Linux, and
+FreeBSD, so this isn't because of narrow experience).
+
+So, the main point is that just deciding whether it'll work based on
+looking at the library file will in some cases fail when it should
+have succeeded (and the software we sell is such a case).
+
+-- 
+Doug DeJulio      | mailto:ddj@hks.net
+HKS, Incorporated | http://www.hks.net/
+
diff --git a/mail/docs b/mail/docs
new file mode 100644
index 00000000..c0dee749
--- /dev/null
+++ b/mail/docs
@@ -0,0 +1,47 @@
+From nobody Wed Oct 14 17:14:44 1998
+X-From-Line: rms@santafe.edu Mon Jun 01 19:52:46 1998
+Return-Path: <rms@santafe.edu>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 15232 invoked from network); 1 Jun 1998 19:52:45 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 1 Jun 1998 19:52:45 -0000
+Received: from sfi.santafe.edu (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with SMTP id MAA32739 for <gord@m-tech.ab.ca>; Mon, 1 Jun 1998 12:09:11 -0600
+Received: from wijiji.santafe.edu by sfi.santafe.edu (4.1/SMI-4.1)
+	id AA03877; Mon, 1 Jun 98 11:55:41 MDT
+Received: by wijiji.santafe.edu (SMI-8.6/SMI-SVR4)
+	id LAA04106; Mon, 1 Jun 1998 11:55:40 -0600
+Date: Mon, 1 Jun 1998 11:55:40 -0600
+Message-Id: <199806011755.LAA04106@wijiji.santafe.edu>
+From: Richard Stallman <rms@santafe.edu>
+To: gord@m-tech.ab.ca
+In-Reply-To: <86hg27twsh.fsf@trick.profitpress.com> (message from Gordon
+	Matzigkeit on 30 May 1998 12:53:50 -0600)
+Subject: Re: libtool manual comments
+Reply-To: rms@gnu.org
+References: <199805240500.XAA01237@wijiji.santafe.edu> <86hg27twsh.fsf@trick.profitpress.com>
+Lines: 23
+Xref: trick.profitpress.com mail.libtool:1476
+
+      Regarless, it needs to have a light touch on the option
+    namespace, since it forwards any unrecognized options to the
+    underlying compiler.  This is so that people can pass arbitrary flags
+    that libtool doesn't know about.
+
+Sorry, I don't follow the logic.
+
+Long-named options are the GNU standard, so every a GNU program should
+provide a long-named version of every option name.
+
+If you think there is some practical reason why libtool should not support
+long-named versions of its own options, would you please spell it out?
+I don't see why it would cause any problem.
+
+     RMS> In section 5.3.1 there is a table of environment variable names,
+     RMS> that should be @table @code.  Section 12.4 has one too.
+
+    Actually, these are not tables, they are lists of `@defvar' blocks.
+    What would you recommend in this situation?
+
+I'd recommend @table @code.  We don't use @defvar for environment
+variables.
+
diff --git a/mail/egcs b/mail/egcs
new file mode 100644
index 00000000..4c9c8943
--- /dev/null
+++ b/mail/egcs
@@ -0,0 +1,114 @@
+From nobody Wed Oct 14 16:45:31 1998
+From: Alexandre Oliva <oliva@dcc.unicamp.br>
+Subject: libtool 1.2a broken on egcs (IRIX)
+To: bug-libtool@gnu.org
+Date: 21 Apr 1998 00:57:51 -0300
+X-From-Line: gord@gnu.org Tue Apr 21 04:21:22 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 25010 invoked from network); 21 Apr 1998 04:21:20 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 21 Apr 1998 04:21:20 -0000
+Received: from mescaline.gnu.org (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id VAA25050 for <gord@m-tech.ab.ca>; Mon, 20 Apr 1998 21:59:01 -0600
+Received: from grande.dcc.unicamp.br by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id AAA22629 for <bug-libtool@gnu.org>; Tue, 21 Apr 1998 00:04:34 -0400
+Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11])
+	by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id BAA08201
+	for <bug-libtool@gnu.org>; Tue, 21 Apr 1998 01:04:18 -0300 (EST)
+Received: from cuca.lsd.dcc.unicamp.br (cuca.lsd.dcc.unicamp.br [143.106.24.139])
+	by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with SMTP id BAA08156
+	for <bug-libtool@gnu.org>; Tue, 21 Apr 1998 01:04:19 -0300 (EST)
+Message-ID: <or3ef7aksg.fsf@cuca.lsd.dcc.unicamp.br>
+X-Mailer: Gnus v5.6.4/XEmacs 20.4 - "Emerald"
+X-Emacs: 20.4 "Emerald" XEmacs  Lucid without mule
+MIME-Version: 1.0 (generated by SEMI 1.2.4 - "Arimagawa")
+Content-Type: multipart/mixed;
+ boundary="Multipart_Tue_Apr_21_00:57:51_1998-1"
+Content-Transfer-Encoding: 7bit
+Xref: trick.profitpress.com mail.libtool:1364
+Lines: 84
+
+[1  <text/plain; US-ASCII (7bit)>]
+Hi!
+
+I've just installed and tested libtool 1.2a on several platforms.  It
+worked beautifully and passed all tests on Solaris 2.[56] and RedHat
+Linux 4.0 and 5.0/x86 and 5.0/alpha.
+
+It failed to pass some tests on IRIX 5.2 and 6.3 because, although
+ltconfig detected that print was available on ksh only, it somehow
+tried to run print with sh in some situation.  I haven't investigated
+the problem any further, but I managed to fix it by defining echo as
+`/bin/ksh print -r'.  The attached patch caused libtool to pass all
+tests on both platforms.
+
+On SunOS 4.1.3 (with egcs 1.0.2 and GNU ld from binutils 2.9), libtool 
+1.2a failed to pass the following tests:
+
+FAIL: demo-exec.test
+FAIL: hardcode.test
+
+Running tests with VERBOSE=yes produced the following additional
+messages for these two tests:
+
+=== Running demo-exec.test
+Executing uninstalled programs in ../demo
+Welcome to GNU Hell!
+ld.so: open error 2 for .libs/libhello.so.3.12
+./demo-exec.test: cannot execute ../demo/hell
+-dlopen is unsupported
+FAIL: demo-exec.test
+
+=== Running hardcode.test
+= Running make hardcode in ../demo
+make[4]: Entering directory `/l/dsk01/temp/install-libtool-1.2a-atibaia-15206/libtool-1.2a/demo'
+You may ignore any linking errors from the following command:
+gcc  -o hc-direct main.o ./.libs/libhello.so.3.12 -lm || echo unsupported > hc-direct
+rm -rf hc-libflag _hclibs
+mkdir _hclibs
+objdir=`sed -n -e 's/^objdir=\"\(.*\)\"$/\1/p' ./libtool`; cd _hclibs && for lib in ../$objdir/libhello*; do \
+  ln -s $lib `echo "$lib" | sed 's%^.*/%%'` || exit 1; \
+done
+gcc  -o hc-libflag main.o -Wl,--rpath -Wl,/l/dsk01/temp/install-libtool-1.2a-atibaia-15206/libtool-1.2a/demo/.libs -L./_hclibs -lhello -lm
+rm -rf _hclibs
+You may ignore any linking errors from the following command:
+LD_LIBRARY_PATH=./.libs gcc  -o hc-libpath main.o -lhello -lm || echo unsupported > hc-libpath
+gcc  -o hc-minusL main.o -L./`sed -n -e 's/^objdir=\"\(.*\)\"$/\1/p' ./libtool` -lhello -lm
+make[4]: Leaving directory `/l/dsk01/temp/install-libtool-1.2a-atibaia-15206/libtool-1.2a/demo'
+= Finding ltconfig's guesses at hardcoding values
+= Searching for hardcoded library directories in each program
+.libs was hardcoded in `hc-direct', which fooled libtool
+.libs was hardcoded in `hc-libflag', as libtool expected
+.libs was not hardcoded in `hc-libpath', which fooled libtool
+.libs was hardcoded in `hc-minusL', which fooled libtool
+FAIL: hardcode.test
+
+This must have something to do with SunOS's hard-coding of -L dirs
+into binary programs.  `ldd ../demo/.libs/hell', for example, prints:
+
+        .libs/libhello.so.3.12 (not found)
+        -lc.1 => /usr/lib/libc.so.1.8
+        -ldl.1 => /usr/lib/libdl.so.1.0
+
+-- 
+Alexandre Oliva
+mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
+http://www.dcc.unicamp.br/~oliva
+Universidade Estadual de Campinas, SP, Brasil
+[2 .patch-libtool-1.2a <application/octet-stream>]
+--- ltconfig.in~	Sun Apr 19 16:35:49 1998
++++ ltconfig.in	Mon Apr 20 17:44:34 1998
+@@ -61,11 +61,8 @@
+     if test "X`(print -r '\t') 2>/dev/null`" = 'X\t'; then
+       # This shell has a builtin print -r that does the trick.
+       echo='print -r'
+-    elif test -f /bin/ksh && test "X$CONFIG_SHELL" != X/bin/ksh; then
+-      # If we have ksh, try running ltconfig again with it.
+-      CONFIG_SHELL=/bin/ksh
+-      export CONFIG_SHELL
+-      exec "$CONFIG_SHELL" "$0" --no-reexec ${1+"$@"}
++    elif test -x /bin/ksh && test "X`(/bin/ksh print -r '\t') 2>/dev/null`" = 'X\t'; then
++      echo='/bin/ksh print -r'
+     else
+       # Try using printf.
+       echo='printf %s\n'
+
diff --git a/mail/freebsd b/mail/freebsd
new file mode 100644
index 00000000..81829d19
--- /dev/null
+++ b/mail/freebsd
@@ -0,0 +1,111 @@
+From nobody Wed Oct 14 17:09:19 1998
+X-From-Line: ben@ben.com Mon Oct 05 10:00:53 1998
+Return-Path: <ben@ben.com>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 19417 invoked from network); 5 Oct 1998 10:00:52 -0000
+Received: from www.m-tech.ab.ca (HELO bambam.m-tech.ab.ca) (209.91.93.34)
+  by www.fig.org with SMTP; 5 Oct 1998 10:00:52 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1])
+	by bambam.m-tech.ab.ca (8.8.7/8.8.7) with ESMTP id EAA19363
+	for <gord@m-tech.ab.ca>; Mon, 5 Oct 1998 04:03:29 -0600
+Received: from jumping-spider.aracnet.com (IDENT:root@jumping-spider.aracnet.com [205.159.88.14])
+	by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id GAA31532
+	for <gord@gnu.ai.mit.edu>; Mon, 5 Oct 1998 06:02:54 -0400
+Received: from pulsar.ben.com (pdx-max1-18.aracnet.com [209.95.33.19])
+	by jumping-spider.aracnet.com (8.9.1/8.9.0) with ESMTP id CAA03831
+	for <gord@gnu.ai.mit.edu>; Mon, 5 Oct 1998 02:58:27 -0700
+Received: from localhost (localhost [127.0.0.1]) by pulsar.ben.com (8.8.8/8.6.12) with SMTP id DAA12980 for <gord@gnu.ai.mit.edu>; Mon, 5 Oct 1998 03:00:50 -0700 (PDT)
+Message-Id: <199810051000.DAA12980@pulsar.ben.com>
+To: gord@gnu.org
+Subject: freebsd libtool bugs
+Date: Mon, 05 Oct 1998 03:00:49 -0700
+From: Ben Jackson <ben@ben.com>
+Lines: 11
+Xref: trick.fig.org libtool:1642
+
+I'm building developtment versions of GTK+ and GIMP which come with
+ltconfig and ltmain.sh version 1.2b.  GTK+ 1.1 is actually trying to
+use the $release tag on its libraries, which exposes a bug in the freebsd
+2.2 support.  A link named `libfoo.so' is not used by the system at all.
+All shared libraries have a version suffix.  To install `libgtk-1.1.so.2.0'
+and make `-lgtk' work, the link must be named `libgtk.so.2.0':
+
+  library_names_spec='${libname}${release}.so$versuffix $libname.so$versuffix'
+
+--Ben
+
+From nobody Wed Oct 14 17:09:30 1998
+X-From-Line: gord@gnu.org Thu Sep 24 04:23:48 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 10420 invoked from network); 24 Sep 1998 04:23:42 -0000
+Received: from gen2-93ip34.cadvision.com (HELO bambam.m-tech.ab.ca) (209.91.93.34)
+  by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 24 Sep 1998 04:23:42 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1])
+	by bambam.m-tech.ab.ca (8.8.7/8.8.7) with ESMTP id WAA31967
+	for <gord@m-tech.ab.ca>; Wed, 23 Sep 1998 22:26:43 -0600
+Received: from CirX.ORG (genius.cirx.org [140.112.240.59]) by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id AAA23595 for <bug-libtool@gnu.org>; Thu, 24 Sep 1998 00:25:59 -0400
+Received: (from clkao@localhost)
+	by CirX.ORG (8.9.1/8.8.8) id MAA18825;
+	Thu, 24 Sep 1998 12:23:15 +0800 (CST)
+	(envelope-from clkao@CirX.ORG)
+Date: Thu, 24 Sep 1998 12:23:15 +0800 (CST)
+Message-Id: <199809240423.MAA18825@CirX.ORG>
+X-Authentication-Warning: genius.cirx.org: clkao set sender to clkao@CirX.ORG using -f
+From: Chia-liang Kao <clkao@CirX.ORG>
+To: bug-libtool@gnu.org
+Subject: FreeBSD 3 support
+Lines: 51
+Xref: trick.fig.org libtool:1628
+
+
+Greetings, 
+	   Due to the recent ELF transistion on FreeBSD 3, The shared
+library version policy has been changed. Here is a patch from
+Vanilla I. Shu <vanilla@FreeBSD.ORG> to support the new elf world on FreeBSD3.
+
+--- ltmain.sh.orig	Wed Sep 23 23:37:14 1998
++++ ltmain.sh	Wed Sep 23 23:38:02 1998
+@@ -967,6 +967,16 @@
+         versuffix="$current.$revision"
+         ;;
+ 
++      freebsd)
++        version_vars="$version_vars major versuffix"
++        major="$current"
++	if [ $PORTOBJFORMAT = elf ]; then
++        versuffix="$current";
++	else
++        versuffix="$current.$revision";
++	fi
++        ;;
++
+       *)
+         $echo "$modename: unknown library version type \`$version_type'" 1>&2
+         echo "Fatal configuration error.  See the $PACKAGE docs for more information." 1>&2
+--- ltconfig.orig	Wed Sep 23 23:37:18 1998
++++ ltconfig	Wed Sep 23 23:39:06 1998
+@@ -1123,10 +1123,21 @@
+   finish_eval='for lib in `ls $libdir/*.ixlibrary 2>/dev/null`; do libname=`$echo "X$lib" | $Xsed -e '\''s%^.*/\([^/]*\)\.ixlibrary$%\1%'\''`; test $rm /sys/libs/${libname}_ixlibrary.a; $show "(cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a)"; (cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a) || exit 1; done'
+   ;;
+ 
+-freebsd2* | freebsd3*)
++freebsd2*)
+   version_type=sunos
+   library_names_spec='${libname}${release}.so.$versuffix $libname.so'
+   finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'
++  shlibpath_var=LD_LIBRARY_PATH
++  ;;
++
++freebsd3*)
++  version_type=freebsd
++  library_names_spec='${libname}${release}.so.$versuffix $libname.so'
++  if [ $PORTOBJFORMAT = elf ]; then
++  finish_cmds='PATH="$PATH:/sbin" OBJFORMAT="$PORTOBJFORMAT" ldconfig -m $libdir'
++  else
++  finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'
++  fi
+   shlibpath_var=LD_LIBRARY_PATH
+   ;;
+ 
+
diff --git a/mail/libc_s b/mail/libc_s
new file mode 100644
index 00000000..49a2d226
--- /dev/null
+++ b/mail/libc_s
@@ -0,0 +1,139 @@
+From nobody Wed Jul  2 19:28:31 1997
+X-From-Line: norm@connectware.ca Wed Jul 02 22:32:39 1997
+Return-Path: <norm@connectware.ca>
+Delivered-To: gord@profitpress.com
+Received: (qmail 5508 invoked from network); 2 Jul 1997 22:32:38 -0000
+Received: from localhost (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by localhost with SMTP; 2 Jul 1997 22:32:38 -0000
+X-POP3-Rcpt: gord@bambam
+Return-Path: norm@connectware.ca
+Received: from bunker.connectware.ca (norm.HIP.CAM.ORG [199.84.42.109]) by m-tech.ab.ca (8.6.12/8.6.9) with ESMTP id KAA07116 for <gord@m-tech.ab.ca>; Wed, 2 Jul 1997 10:12:18 -0600
+Received: from castle.connectware.ca (castle.connectware.ca [204.19.223.2])
+	by bunker.connectware.ca (8.8.5/8.8.5) with SMTP id MAA02233
+	for <gord@m-tech.ab.ca>; Wed, 2 Jul 1997 12:15:54 -0400 (EDT)
+Received: by castle.connectware.ca (AIX 3.2/UCB 5.64/4.03)
+          id AA21851; Wed, 2 Jul 1997 12:08:56 -0400
+Date: Wed, 2 Jul 1997 12:08:53 -0400 (EDT)
+From: Normand McGuire <norm@connectware.ca>
+To: Gordon Matzigkeit <gord@m-tech.ab.ca>
+Subject: Re: -lc_s shared libraries
+In-Reply-To: <86yb7qipsd.fsf_-_@trick.profitpress.com>
+Message-Id: <Pine.A32.3.91.970702113816.24858A-100000@castle.connectware.ca>
+Mime-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+Xref: trick.profitpress.com mail.libtool:299
+Lines: 113
+
+
+
+On 1 Jul 1997, Gordon Matzigkeit wrote:
+
+> Are you sure that on SCO Openserver 5 you need to specify
+> /lib/libc.so?  From what I understood about that platform, specifying
+> `-lc' (which is what the C compiler does by default) is good enough,
+> and links in the shared version if it exists.
+
+>From my experience, definitely. Look below.
+
+> Do you know otherwise?  Can you show the results of specific tests to
+> me that would prove your point?
+
+Here is a sample of a session demonstrating this on my system. I show the 
+source code, default cc file and three compiles with three a.out file 
+sizes. See for yourself:
+
+Script started on Wed Jul  2 11:21:58 1997
+$ cat t.c
+main()
+
+	{
+	printf("Hello, world\n");
+	}
+$ cat /etc/default/cc
+#	@(#) cc.default 20.1 94/12/04 
+#	
+#	Copyright (C) The Santa Cruz Operation, Inc. 1994-1995.
+#	This Module contains Proprietary Information of
+#	The Santa Cruz Operation, and should be treated as Confidential.
+#
+#	Core development /bin/cc reads /etc/default/cc.
+#	Cross development /usr/ods30/bin/cc reads /etc/default/crossdevcc.
+#	If a prefix is specified, cc reads /etc/default/<prefix>cc instead.
+#
+FLAGS=
+LIBS=
+$ cc t.c
+$ l a.out
+-rwxrwxr-x   1 root     sys        46334 Jul  2 11:22 a.out
+$ cc t.c -lc
+$ l a.out
+-rwxrwxr-x   1 root     sys        46334 Jul  2 11:22 a.out
+$ cc t.c /lib/libc.so
+$ l a.out
+-rwxrwxr-x   1 root     sys         3988 Jul  2 11:22 a.out
+$ exit
+
+script done on Wed Jul  2 11:22:32 1997
+
+And believe me, this script session is not a fake.
+
+> The reason I'm asking is that I, too, would like to know how Autoconf
+> packages can best take advantage of shared libraries, especially in a
+> general, rather than a test-by-test way.
+
+The section of my configure.in script that takes care of shared libraries
+is short and not annoying to repeat. You may want to incorporate it into 
+the AC_PROG_CC macro or create a new one for it. So far, I've seen only 
+two kinds of behaviors regarding shared libraries: if they are not used 
+automatically when invoking cc, just include them when linking the 
+program. And it worked so far. However, you guys may have a whole lot 
+more flavors of system to run on compared to me.
+
+Here is the portion of the shared library check in my configure.in script:
+
+# STEP 2 - Check for libraries
+
+AC_MSG_CHECKING([for libc.so])
+if test -r /lib/libc.so; then
+    AC_MSG_RESULT([yes (/lib/libc.so)])
+    LIBS="$LIBS /lib/libc.so"
+elif test -r /usr/lib/libc.so; then
+    AC_MSG_RESULT([yes (/usr/lib/libc.so)])
+    LIBS="$LIBS /usr/lib/libc.so"
+else
+    AC_MSG_RESULT(no)
+    AC_CHECK_LIB(c_s, main)
+    fi
+
+> Could you be more specific when you mention `some other System V Unix
+> systems'?  What are their canonical system names (i.e. *-*-sco3.2v4*)?
+
+By 'some other Unix systems' requiring that you explicitely specify the 
+shared library name when linking the program, I meant specifically:
+
+o Bull Open Software (Unix System V Release 4, but don't remember if it is x86)
+
+o Interactive Unix System V/386 all versions
+
+o SCO Unix 3.2v4 and SCO OpenServer 5
+
+o Sun Solaris 2.3 / SunOS 5.3
+
+All others that we've compiled and run on will automatically use shared 
+libraries when available, namely:
+
+IBM's AIX 3.2.* and 4.*
+HP's HPUX 8.*, 9.* and 10.*
+DEC Ultrix, OSF/1 and DEC Unix all versions tried
+DataGeneral's DGUX all versions tried
+Sequent's DYNIX/ptx 2.1 and 4
+Linux all versions tried
+SGI's Irix all versions tried
+NCR and AT&T Unix System V/386 Release 4
+Sun Solaris 2.4 (SunOS 5.4) and Solaris 2.5 (SunOS 5.5)
+SunOS 4.1*
+Unisys Unix System V/386
+Unixware all versions
+
+Normand McGuire
+
diff --git a/mail/perms b/mail/perms
new file mode 100644
index 00000000..5c4d778c
--- /dev/null
+++ b/mail/perms
@@ -0,0 +1,152 @@
+From nobody Wed Oct 14 17:00:26 1998
+X-From-Line: gord@gnu.org Wed Sep 16 02:36:19 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 16983 invoked from network); 16 Sep 1998 02:36:18 -0000
+Received: from gen2-93ip34.cadvision.com (HELO bambam.m-tech.ab.ca) (209.91.93.34)
+  by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 16 Sep 1998 02:36:18 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id UAA21823 for <gord@m-tech.ab.ca>; Tue, 15 Sep 1998 20:33:36 -0600
+Received: from creche.cygnus.com (2Cust11.tnt22.dfw5.da.uu.net [208.254.195.11]) by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id WAA25991 for <bug-libtool@gnu.org>; Tue, 15 Sep 1998 22:34:08 -0400
+Received: (from tromey@localhost) by creche.cygnus.com (8.7.6/8.7.3) id UAA02812; Tue, 15 Sep 1998 20:29:44 -0600
+Sender: tromey@creche.cygnus.com
+To: Libtool Bugs <bug-libtool@gnu.org>
+Subject: [pacman@cqc.com] permission problems on things installed by automake
+X-Zippy:  Did you move a lot of KOREAN STEAK KNIVES this trip, Dingy?
+X-Attribution:  Tom
+Reply-To: tromey@cygnus.com
+From: Tom Tromey <tromey@cygnus.com>
+Date: 15 Sep 1998 20:29:42 -0600
+Message-ID: <m1yark7pt5.fsf@creche.cygnus.com>
+X-Mailer: Red Gnus v0.34/Emacs 19.34
+Lines: 28
+Xref: trick.fig.org libtool:1609
+
+The second paragraph applies to libtool.  I was recently asked this
+same question by the Gtk developers as well.  I don't know the answer;
+automake just follows you guys where libtool is concerned.
+
+Tom
+------- Start of forwarded message -------
+From: pacman@cqc.com
+Message-ID: <19980909050926.23045.qmail@defiant.cqc.com>
+Subject: permission problems on things installed by automake
+To: automake-bugs@gnu.org
+Date: Wed, 9 Sep 1998 00:09:26 -0500 (EST)
+
+Two separate problems here. The first, I have complained about before, but
+nobody took any interest in fixing it. mkinstalldirs creates directories with
+bad permissions. Specifically, it creates directories by just using mkdir and
+assuming that they the Public Directory Fairy will come along and make them
+755. This does not happen. Please, stop making unwarranted assumptions about
+my umask.
+
+The second problem is that automake installs LTLIBRARIES by running libtool
+install -m 644 (also known as $INSTALL_DATA). Shared libraries should really
+be 755. If you just say "libtool install" without any -m, it will set the
+right permissions on installed libraries: 644 for .a's and 755 for .so's.
+-- 
+Alan Curry
+
+------- End of forwarded message -------
+
+From nobody Wed Oct 14 17:00:27 1998
+X-From-Line: gord@gnu.org Wed Sep 16 03:22:10 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 17099 invoked from network); 16 Sep 1998 03:21:53 -0000
+Received: from gen2-93ip34.cadvision.com (HELO bambam.m-tech.ab.ca) (209.91.93.34)
+  by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 16 Sep 1998 03:21:53 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id VAA22252 for <gord@m-tech.ab.ca>; Tue, 15 Sep 1998 21:19:11 -0600
+Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.1.11]) by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id XAA27401 for <bug-libtool@gnu.org>; Tue, 15 Sep 1998 23:19:47 -0400
+Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11])
+	by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id AAA21803;
+	Wed, 16 Sep 1998 00:17:29 -0300 (EST)
+Received: from tiete.dcc.unicamp.br (tiete.dcc.unicamp.br [143.106.7.1])
+	by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with SMTP id AAA10695;
+	Wed, 16 Sep 1998 00:17:30 -0300 (EST)
+Sender: oliva@tiete.dcc.unicamp.br
+To: tromey@cygnus.com
+Cc: Libtool Bugs <bug-libtool@gnu.org>
+Subject: Re: [pacman@cqc.com] permission problems on things installed by automake
+References: <m1yark7pt5.fsf@creche.cygnus.com>
+From: Alexandre Oliva <oliva@dcc.unicamp.br>
+Date: 16 Sep 1998 00:17:26 +-300
+In-Reply-To: Tom Tromey's message of "15 Sep 1998 20:29:42 -0600"
+Message-ID: <or1zpcsq49.fsf@tiete.dcc.unicamp.br>
+User-Agent: Gnus/5.070024 (Pterodactyl Gnus v0.24) XEmacs/20.4 (Emerald)
+X-Emacs: 20.4 "Emerald" XEmacs  Lucid with mule
+MIME-Version: 1.0 (generated by SEMI 1.8.5 - "Nishi-Takaoka")
+Content-Type: text/plain; charset=US-ASCII
+Lines: 27
+Xref: trick.fig.org libtool:1610
+
+Tom Tromey <tromey@cygnus.com> writes:
+
+> From: pacman@cqc.com
+
+> The second problem is that automake installs LTLIBRARIES by running libtool
+> install -m 644 (also known as $INSTALL_DATA).
+
+this is wrong, it was probably just cut&pasted from the rule for
+LIBRARIES.  libtools knows what is the right default permission to
+assign to libraries, automake doesn't have to do it.  Unless someone
+has a good reason to do it.  Maybe automake should define a macro such
+as INSTALL_LTLIBRARY, empty by default, but that one could override
+with additional arguments for libtool --mode=install
+
+Another alternative, that I don't like very much, is to let libtool
+modify the modes of libraries: if they must be executable in the final
+target, it just ensures that the installed .so has the executable bit
+enabled wherever the read bit is enabled too.
+
+What do you think?
+
+-- 
+Alexandre Oliva
+mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
+http://www.dcc.unicamp.br/~oliva
+Universidade Estadual de Campinas, SP, Brasil
+
+From nobody Wed Oct 14 17:00:28 1998
+X-From-Line: otaylor@fresnel.labs.redhat.com Sun Sep 20 22:12:22 1998
+Return-Path: <otaylor@fresnel.labs.redhat.com>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 1616 invoked from network); 20 Sep 1998 22:12:21 -0000
+Received: from gen2-93ip36.cadvision.com (HELO mail.fig.org) (209.91.93.36)
+  by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 20 Sep 1998 22:12:21 -0000
+Received: (qmail 9059 invoked by uid 500); 20 Sep 1998 22:09:20 -0000
+Delivered-To: gord@fig.org
+Received: (qmail 9056 invoked from network); 20 Sep 1998 22:09:19 -0000
+Received: from fresnel.labs.redhat.com (207.175.45.22)
+  by www.fig.org with SMTP; 20 Sep 1998 22:09:19 -0000
+Received: (from otaylor@localhost)
+	by fresnel.labs.redhat.com (8.8.7/8.8.7) id SAA25598;
+	Sun, 20 Sep 1998 18:18:38 -0400
+To: gord@fig.org
+Subject: Automake and ltlibraries installation
+From: Owen Taylor <otaylor@redhat.com>
+Date: 20 Sep 1998 18:18:38 -0400
+Message-ID: <ybeww6yqvgh.fsf@fresnel.labs.redhat.com>
+X-Mailer: Gnus v5.5/Emacs 20.2
+Lines: 19
+Xref: trick.fig.org libtool:1621
+
+
+Recently, we've been using a modified version of libtool that enables
+shared library dependencies on Linux. With that change, it becomes
+desirable to be able to run ldd on the installed libraries.
+
+However, the libraries are installed without executable permissions.
+
+The relevant changelog entry seems to be:
+
+Tue Nov 25 14:20:42 1997  Tom Tromey  <tromey@cygnus.com>
+
+	* ltlib.am: Use INSTALL_DATA, not INSTALL_PROGRAM.  From Gord
+	Matzigkeit.
+
+Do you happen to remember why this change was made?
+
+Thanks,
+                                        Owen
+
diff --git a/mail/rpath b/mail/rpath
new file mode 100644
index 00000000..5f8729e6
--- /dev/null
+++ b/mail/rpath
@@ -0,0 +1,110 @@
+From nobody Wed Oct 14 16:48:15 1998
+X-From-Line: manfred@s-direktnet.de Fri Jun 05 23:07:19 1998
+Return-Path: <manfred@s-direktnet.de>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 21857 invoked from network); 5 Jun 1998 23:07:19 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 5 Jun 1998 23:07:19 -0000
+Received: from dallas.seitz.de (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id LAA21368 for <gord@profitpress.com>; Fri, 5 Jun 1998 11:20:42 -0600
+Received: from saturn.hollstein.net
+          (pf-net-host-248.seitz.de [193.155.171.248]) by dallas.seitz.de
+          (Netscape Mail Server v2.02) with ESMTP id AAD28613;
+          Fri, 5 Jun 1998 19:25:21 +0200
+Received: (from manfred@localhost)
+	by saturn.hollstein.net (8.8.7/8.8.7) id TAA00796;
+	Fri, 5 Jun 1998 19:03:53 +0200
+Date: Fri,  5 Jun 1998 19:03:53 +0200 (MEST)
+From: Manfred Hollstein <manfred@s-direktnet.de>
+To: ddsinc09@ix.netcom.com, gord@profitpress.com
+Cc: egcs@cygnus.com
+Subject: Issues for libtool and/vs egcs (was: Re: can't resolve symbol '__register_frame_info')
+In-Reply-To: <3576FDAF.EE503B4B@datadesign.com>
+References: <35757FE9.87EEC06D@datadesign.com>
+	<13686.53201.340176.596631@saturn.hollstein.net>
+	<3576FDAF.EE503B4B@datadesign.com>
+X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
+Message-ID: <13688.9050.615440.687287@saturn.hollstein.net>
+Reply-To: manfred@s-direktnet.de, Manfred.Hollstein@ks.sel.alcatel.de
+Mime-Version: 1.0 (generated by tm-edit 7.108)
+Content-Type: text/plain; charset=US-ASCII
+Lines: 41
+Xref: trick.profitpress.com mail.libtool:1479
+
+On Thu, 4 June 1998, 13:03:59, korbb@datadesign.com wrote:
+
+ > Manfred Hollstein wrote:
+ > 
+ > > To fix the problem, you should
+ > >
+ > >   1. Add all directories which contain _your_ private shared libs
+ > >      to LD_RUN_PATH prior to linking your executables, and/or
+ > >   2. Add a -Wl,-rpath,<dir> for all these directories, or
+ > >   3. Remove all your own lib*.so files from your private directories.
+ > >
+ > > Since  I didn't want  to use  KDE4's libjpeg.so,  I removed libjpeg.so
+ > > (and libgdbm.so) from my  private installation directory and re-linked
+ > > the particular applications; now ImageMagick is running like a charm.
+ > 
+ > Excuse me?  What happened to LD_LIBRARY_PATH?
+ > Are there *two* ways of specifying the same information?
+ > Also, for the particular application, I am using :
+ > 
+ >     ltmain.sh (GNU libtool) 1.2
+ > 
+ > which builds a shared lib for me and a magical shell script that
+ > is supposed to do the right thing when invoking the uninstalled
+ > program.  So, does libtool need updating to work with egcs?
+ > 
+ > 
+
+Yep, some days ago the libtool maintainer asked about details what
+need to be done in this area.
+
+I guess, the main reason for the problems is inconsistent usage of
+`-Wl,-rpath,somedir' vs. LD_RUN_PATH; AFAIK, `-Wl,-rpath,...' disables 
+LD_RUN_PATH at linktime and LD_LIBRARY_PATH at runtime.
+
+I don't know, which way libtool is using, but I tend to strongly
+recommend against using -Wl,-rpath.
+
+Other thoughts?
+
+manfred
+
+From nobody Wed Oct 14 16:48:18 1998
+X-From-Line: ian@cygnus.com Sat Jun 06 19:44:17 1998
+Return-Path: <ian@cygnus.com>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 28443 invoked from network); 6 Jun 1998 19:44:15 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 6 Jun 1998 19:44:15 -0000
+Received: from tweedledumb.cygnus.com (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id KAA32693 for <gord@profitpress.com>; Sat, 6 Jun 1998 10:38:53 -0600
+Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
+	by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id MAA08502;
+	Sat, 6 Jun 1998 12:44:42 -0400 (EDT)
+Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id MAA20367; Sat, 6 Jun 1998 12:44:42 -0400
+Date: Sat, 6 Jun 1998 12:44:42 -0400
+Message-Id: <199806061644.MAA20367@subrogation.cygnus.com>
+From: Ian Lance Taylor <ian@cygnus.com>
+To: manfred@s-direktnet.de, Manfred.Hollstein@ks.sel.alcatel.de
+CC: ddsinc09@ix.netcom.com, gord@profitpress.com, egcs@cygnus.com
+In-reply-to: <13688.9050.615440.687287@saturn.hollstein.net> (message from
+	Manfred Hollstein on Fri, 5 Jun 1998 19:03:53 +0200 (MEST))
+Subject: Re: Issues for libtool and/vs egcs (was: Re: can't resolve symbol '__register_frame_info')
+Lines: 14
+Xref: trick.profitpress.com mail.libtool:1480
+
+   Date: Fri,  5 Jun 1998 19:03:53 +0200 (MEST)
+   From: Manfred Hollstein <manfred@s-direktnet.de>
+
+   I guess, the main reason for the problems is inconsistent usage of
+   `-Wl,-rpath,somedir' vs. LD_RUN_PATH; AFAIK, `-Wl,-rpath,...' disables 
+   LD_RUN_PATH at linktime and LD_LIBRARY_PATH at runtime.
+
+Using -rpath will indeed cause the linker to ignore LD_RUN_PATH (at
+least, that is how the GNU linker behaves).  However, it does not
+cause the dynamic linker to ignore LD_LIBRARY_PATH when the executable
+is run.
+
+Ian
+
diff --git a/mail/sgi b/mail/sgi
new file mode 100644
index 00000000..533f79f0
--- /dev/null
+++ b/mail/sgi
@@ -0,0 +1,218 @@
+X-From-Line: Janos.Farkas-nouce/priv-#5HYEEI07/9C6uVbFUutOXk6szqe@lk9qw.mail.eon.ml.org Tue Mar 31 15:39:15 1998
+Return-Path: <Janos.Farkas-nouce/priv-#5HYEEI07/9C6uVbFUutOXk6szqe@lk9qw.mail.eon.ml.org>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 903 invoked from network); 31 Mar 1998 15:39:14 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 31 Mar 1998 15:39:14 -0000
+Received: from mi5.satimex.tvnet.hu (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with SMTP id DAA25302 for <gord@m-tech.ab.ca>; Mon, 30 Mar 1998 03:28:54 -0700
+Received: (qmail 3288 invoked by uid 2001); 30 Mar 1998 10:36:04 -0000
+Date: Mon, 30 Mar 1998 12:36:04 +0200
+From: Janos Farkas <Janos.Farkas-nouce/priv-#UiTVSa/OAc8mBkHH9CeLgE.uMWK@lk9qw.mail.eon.ml.org>
+To: Ian Lance Taylor <ian@cygnus.com>, gord@m-tech.ab.ca
+Cc: bug-libtool@gnu.org, tiemann@cygnus.com
+Subject: Re: Irix shared libraries
+Mail-Followup-To: Ian Lance Taylor <ian@cygnus.com>, gord@m-tech.ab.ca,
+	bug-libtool@gnu.org, tiemann@cygnus.com
+Message-ID: <19980330123604.03725@lk9qw.mail.eon.ml.org>
+References: <86hg4h59tw.fsf@trick.profitpress.com> <199803300034.TAA16378@subrogation.cygnus.com>
+Mime-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+In-Reply-To: <199803300034.TAA16378@subrogation.cygnus.com>; from Ian Lance Taylor on Sun, Mar 29, 1998 at 07:34:01PM -0500
+Errors-To: Janos Farkas <Janos.Farkas-sys/priv-#5zJlUoBBccl/-errors@lk9qw.mail.eon.ml.org>
+Lines: 44
+Xref: trick.profitpress.com mail.libtool:1249
+
+On 1998-03-29 at 19:34:01, Ian Lance Taylor wrote:
+>    From: Gordon Matzigkeit <gord@m-tech.ab.ca>
+>    Date: 29 Mar 1998 16:57:47 -0700
+> 
+>    Do you have access to the IRIX ld man pages?  I don't know why it's
+>    complaining about `non-sgi' interface versions.  I was under the
+>    impression that any colon-separated list of strings would do.
+> 
+> Here is the entire ld man page, but it does not appear particularly
+> helpful.
+
+I just realized I also have mortal access to an SGI system, and found
+this in the dso.5 page, this looks more informative :)
+
+   Versioning of Shared Objects.
+
+   QUICK OVERVIEW
+
+   For a shared object to be versioned
+   the following needs to be done:
+
+   * Version strings consist of 3 parts and a dot: The string "sgi",
+     a decimal number (the major number), a dot, and a decimal number
+     (the minor number).
+
+   * Add the command -set_version sgi1.0 to the command to build
+     the shared object (cc -shared, ld -shared, etc.).
+
+   * Whenever you make a COMPATIBLE change update the minor version
+     number (the one after the dot), and add the latest version string
+     to colon-separated list of version strings, e.g., -set_version
+     sgi1.0:sgi1.1:sgi1.3
+
+   * Whenever you make an INCOMPATIBLE change, update the
+     major version number.  Pass this as the version list, e.g.,
+     -set_version sgi2.0.  Change the filename of the OLD shared object
+     by adding a dot followed by the previous major number to the filename
+     of the shared object.  DO NOT CHANGE the soname of the object.
+     No change to the file contents are necessary or desirable.  Simply
+     rename the file.
+
+-- 
+Janos - Don't worry, my address is real.  I'm just bored of spam.
+From nobody Wed Oct 14 16:54:11 1998
+X-From-Line: gord@gnu.org Fri Jul 03 02:26:01 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 9753 invoked from network); 3 Jul 1998 02:25:59 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 3 Jul 1998 02:25:59 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id SAA13535 for <gord@m-tech.ab.ca>; Thu, 2 Jul 1998 18:34:06 -0600
+Received: from platinum.math.arizona.edu by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id UAA09573 for <bug-libtool@gnu.org>; Thu, 2 Jul 1998 20:41:52 -0400
+Date: Fri, 3 Jul 1998 00:40:12 GMT
+Message-Id: <199807030040.AAA16739@platinum.math.arizona.edu>
+Received: by platinum.math.arizona.edu; Fri, 3 Jul 1998 00:40:12 GMT
+From: "Robert S. Maier" <rsm@math.arizona.edu>
+To: bug-libtool@gnu.org
+Subject: misc. libtool bugs
+Phase-of-Moon: Waxing Gibbous (62% of Full)
+Organization: Mathematics Department, University of Arizona
+Lines: 46
+Xref: trick.fig.org mail.libtool:1516
+
+Through installing the plotutils package on several platforms, I've turned
+up a few additional bugs in libtool-1.2.  Here they are...
+
+1. The plotutils package uses libtool to link together a shared library,
+`libplot'.  It also compiles several executables, each in its own
+subdirectory, and links them with `libplot'.  It then runs tests on the
+executables.  
+
+By looking at the test output I figured out that the version of libplot
+that gets linked with the executables is by default the previously
+installed version (if any), rather than the one that that's just been
+built.  This happens under IRIX 5.3 and 6.4, when compiling with both cc
+and gcc.  Probably on other platforms as well.
+
+I assume there's something wrong with LD_LIBRARY_PATH.  But the shell
+scripts that libtool generates (i.e., the pseudo-executables) contain the
+lines
+
+    # Add our own library path to LD_LIBRARY_PATH
+    LD_LIBRARY_PATH="$thisdir/../libplot/.libs:$LD_LIBRARY_PATH"
+
+    # Some systems cannot cope with colon-terminated LD_LIBRARY_PATH
+    LD_LIBRARY_PATH=`$echo "X$LD_LIBRARY_PATH" | $Xsed -e 's/:*$//'`
+
+which certainly look right.
+
+A workaround here is to do `rm -f /usr/local/lib/libplot.*' before
+installing the package.  But that's a pretty drastic workaround.
+
+2. At least on those IRIX platforms, there's something buggy about the
+option "-set_version 1.1.2:0.0:1.0" that libtool-1.2 passes to ld.  If
+I compile a version of my `graph' utility that is meant to be linked with
+-lXm instead of -lXaw (the default), as well as -lplot, I get the following
+when I go to its subdirectory and try to run it without installing it:
+
+	cosmo$ echo 0 0 1 1 2 0 | graph -TX -C
+		 4352:graph: rld: Warning: version search suppressed because object libplot.so in liblist has non-sgi interface version (1.0)
+		 4352:graph: rld: Fatal Error: cannot map soname 'libplot.so' using any of the filenames /usr/local/lib/libplot.so:/lib/libplot.so:/usr/lib/libplot.so:/usr/local/ivtools/lib/SGI/libplot.so:/lib/cmplrs/cc/libplot.so:/usr/lib/cmplrs/cc/libplot.so: -- either the file does not exist or the file is not mappable (with reason indicated in previous msg)
+
+Not sure what's going on here.  If I do a `make install', the installed
+version of `graph' functions perfectly.  It's only the uninstalled one,
+built specially to be linked with -lXm, that gives error messages about SGI
+version numbering for -lplot.
+
+--Robert
+
+From nobody Wed Oct 14 17:10:58 1998
+X-From-Line: gord@mescaline.gnu.org Tue Sep 29 01:34:53 1998
+Return-Path: <gord@mescaline.gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 20064 invoked from network); 29 Sep 1998 01:34:52 -0000
+Received: from www.m-tech.ab.ca (HELO bambam.m-tech.ab.ca) (209.91.93.34)
+  by www.fig.org with SMTP; 29 Sep 1998 01:34:52 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1])
+	by bambam.m-tech.ab.ca (8.8.7/8.8.7) with ESMTP id TAA10331
+	for <gord@m-tech.ab.ca>; Mon, 28 Sep 1998 19:37:37 -0600
+Received: from moshpit.cygnus.com (bje@moshpit.cygnus.com [203.24.38.233])
+	by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id VAA16422
+	for <bug-libtool@gnu.org>; Mon, 28 Sep 1998 21:36:45 -0400
+Received: from localhost by moshpit.cygnus.com (8.8.8/8.8.8)
+	with SMTP id LAA24934; Tue, 29 Sep 1998 11:33:52 +1000
+X-Authentication-Warning: moshpit.cygnus.com: bje owned process doing -bs
+Date: Tue, 29 Sep 1998 11:33:52 +1000 (EST)
+From: Ben Elliston <bje@cygnus.com>
+To: bug-libtool@gnu.org
+cc: Michael Tiemann <tiemann@cygnus.com>
+Subject: libtool patch (fwd)
+Message-ID: <Pine.LNX.3.95.980929113311.24925A-100000@moshpit.cygnus.com>
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+Lines: 58
+Xref: trick.fig.org libtool:1637
+
+I didn't realise libtool was under active maintainership, so here is a
+patch from Michael Tiemann.
+
+Ben
+
+---------- Forwarded message ----------
+Date: Tue, 22 Sep 1998 08:14:25 -0700 (PDT)
+From: Michael Tiemann <tiemann@cygnus.com>
+To: bje@cygnus.com
+Subject: libtool patch
+
+Irix6 is really not an o32 system anymore...it's an n32 system (gcc
+doesn't even support o32).  So you need to change all the
+LD_LIBRARY_PATHs to LD_LIBRARYN32_PATH.
+
+tiemann@holodeck$ cvs diff -c ltconfig
+Index: ltconfig
+===================================================================
+RCS file: /cvs/cvsfiles/devo/libtool/ltconfig,v
+retrieving revision 1.16
+diff -c -r1.16 ltconfig
+*** ltconfig	1998/07/07 20:22:52	1.16
+--- ltconfig	1998/09/22 15:13:36
+***************
+*** 1328,1338 ****
+    postinstall_cmds='chmod 555 $lib'
+    ;;
+  
+! irix5* | irix6*)
+    version_type=osf
+    soname_spec='${libname}${release}.so'
+    library_names_spec='${libname}${release}.so$versuffix $libname.so'
+    shlibpath_var=LD_LIBRARY_PATH
+    ;;
+  
+  # No shared lib support for Linux oldld, aout, or coff.
+--- 1328,1345 ----
+    postinstall_cmds='chmod 555 $lib'
+    ;;
+  
+! irix5*)
+    version_type=osf
+    soname_spec='${libname}${release}.so'
+    library_names_spec='${libname}${release}.so$versuffix $libname.so'
+    shlibpath_var=LD_LIBRARY_PATH
++   ;;
++ 
++ irix6*)
++   version_type=osf
++   soname_spec='${libname}${release}.so'
++   library_names_spec='${libname}${release}.so$versuffix $libname.so'
++   shlibpath_var=LD_LIBRARYN32_PATH
+    ;;
+  
+  # No shared lib support for Linux oldld, aout, or coff.
+tiemann@holodeck$ 
+
+
diff --git a/mail/sunos b/mail/sunos
new file mode 100644
index 00000000..669c43c7
--- /dev/null
+++ b/mail/sunos
@@ -0,0 +1,320 @@
+From nobody Wed Oct 14 16:54:55 1998
+X-From-Line: gord@gnu.org Tue Jul 07 19:28:26 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 8544 invoked from network); 7 Jul 1998 19:28:24 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 7 Jul 1998 19:28:24 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id NAA06387 for <gord@m-tech.ab.ca>; Tue, 7 Jul 1998 13:28:22 -0600
+Received: from tweedledumb.cygnus.com by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id PAA17659 for <bug-libtool@gnu.org>; Tue, 7 Jul 1998 15:27:58 -0400
+Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
+	by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id PAA15308
+	for <bug-libtool@gnu.org>; Tue, 7 Jul 1998 15:27:50 -0400 (EDT)
+Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id PAA29927; Tue, 7 Jul 1998 15:27:49 -0400
+Date: Tue, 7 Jul 1998 15:27:49 -0400
+Message-Id: <199807071927.PAA29927@subrogation.cygnus.com>
+From: Ian Lance Taylor <ian@cygnus.com>
+To: bug-libtool@gnu.org
+Subject: SunOS problem in libtool 1.2b
+Lines: 13
+Xref: trick.fig.org mail.libtool:1524
+
+The SunOS support in libtool 1.2b still isn't quite right, at least
+when using GNU ld.
+
+If the library is built using -release, then the name of the library
+will be something like libbfd-2.9.4.so.  However, attempts to link
+against the library will set LD_LIBRARY_PATH and then link using
+-lbfd.  That won't work.  The only thing which would work would be
+-lbfd-2.9.4.
+
+I'm not sure how to fix this.
+
+Ian
+
+From nobody Wed Oct 14 16:54:58 1998
+X-From-Line: gord@gnu.org Tue Jul 07 19:33:34 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 9140 invoked from network); 7 Jul 1998 19:33:33 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 7 Jul 1998 19:33:33 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id NAA06452 for <gord@m-tech.ab.ca>; Tue, 7 Jul 1998 13:32:57 -0600
+Received: from cygnus.com by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id PAA17978 for <bug-libtool@gnu.org>; Tue, 7 Jul 1998 15:32:45 -0400
+Received: from happy.cygnus.com (happy.cygnus.com [205.180.230.206])
+	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA21546;
+	Tue, 7 Jul 1998 12:32:17 -0700 (PDT)
+Received: (drepper@localhost) by happy.cygnus.com (8.8.7/8.6.4) id MAA06111; Tue, 7 Jul 1998 12:31:23 -0700
+To: Ian Lance Taylor <ian@cygnus.com>
+Cc: bug-libtool@gnu.org
+Subject: Re: SunOS problem in libtool 1.2b
+References: <199807071927.PAA29927@subrogation.cygnus.com>
+Reply-To: drepper@cygnus.com (Ulrich Drepper)
+X-fingerprint: BE 3B 21 04 BC 77 AC F0  61 92 E4 CB AC DD B9 5A
+Mime-Version: 1.0 (generated by tm-edit 7.108)
+Content-Type: text/plain; charset=US-ASCII
+From: Ulrich Drepper <drepper@cygnus.com>
+Date: 07 Jul 1998 12:31:23 -0700
+In-Reply-To: Ian Lance Taylor's message of "Tue, 7 Jul 1998 15:27:49 -0400"
+Message-ID: <r27m1po3uc.fsf@happy.cygnus.com>
+X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald"
+Lines: 20
+Xref: trick.fig.org mail.libtool:1525
+
+Ian Lance Taylor <ian@cygnus.com> writes:
+
+> If the library is built using -release, then the name of the library
+> will be something like libbfd-2.9.4.so.  However, attempts to link
+> against the library will set LD_LIBRARY_PATH and then link using
+> -lbfd.  That won't work.  The only thing which would work would be
+> -lbfd-2.9.4.
+
+This is how we name shared objects in glibc.  The solution should be
+to have symlinks
+
+	libbfd-2.9.4.so <- libbfd.so
+
+created while generating the shared object.
+
+-- 
+---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
+Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
+Cygnus Solutions `--' drepper at cygnus.com   `------------------------
+
+From nobody Wed Oct 14 16:54:58 1998
+X-From-Line: gord@gnu.org Tue Jul 07 20:24:38 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 10048 invoked from network); 7 Jul 1998 20:24:37 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by localhost with SMTP; 7 Jul 1998 20:24:37 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id OAA07241 for <gord@m-tech.ab.ca>; Tue, 7 Jul 1998 14:21:34 -0600
+Received: from tweedledumb.cygnus.com by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id QAA21709 for <bug-libtool@gnu.org>; Tue, 7 Jul 1998 16:21:26 -0400
+Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
+	by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id QAA17224
+	for <bug-libtool@gnu.org>; Tue, 7 Jul 1998 16:21:20 -0400 (EDT)
+Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id QAA00051; Tue, 7 Jul 1998 16:21:20 -0400
+Date: Tue, 7 Jul 1998 16:21:20 -0400
+Message-Id: <199807072021.QAA00051@subrogation.cygnus.com>
+From: Ian Lance Taylor <ian@cygnus.com>
+To: bug-libtool@gnu.org
+In-reply-to: <r27m1po3uc.fsf@happy.cygnus.com> (message from Ulrich Drepper on
+	07 Jul 1998 12:31:23 -0700)
+Subject: Re: SunOS problem in libtool 1.2b
+Lines: 91
+Xref: trick.fig.org mail.libtool:1526
+
+   From: Ulrich Drepper <drepper@cygnus.com>
+   Date: 07 Jul 1998 12:31:23 -0700
+
+   > If the library is built using -release, then the name of the library
+   > will be something like libbfd-2.9.4.so.  However, attempts to link
+   > against the library will set LD_LIBRARY_PATH and then link using
+   > -lbfd.  That won't work.  The only thing which would work would be
+   > -lbfd-2.9.4.
+
+   This is how we name shared objects in glibc.  The solution should be
+   to have symlinks
+
+	   libbfd-2.9.4.so <- libbfd.so
+
+   created while generating the shared object.
+
+Good idea.  I worked up the appended patch.
+
+We need to set hardcode_minus_L to no.  Otherwise, libtool will set
+LD_LIBRARY_PATH to find the library.  That fails if an older version
+of the library has been installed, because the linker will search the
+-L options before it searches LD_LIBRARY_PATH.
+
+We need to set versuffix for SunOS even if there is no version name,
+because the dynamic linker expects to use a version suffix when it
+opens the library.
+
+Unfortunately, it still doesn't work, because the gcc collect2 program
+doesn't understand the -rpath option and can't find the shared
+library.
+
+Ian
+
+
+Tue Jul  7 16:19:57 1998  Ian Lance Taylor  <ian@cygnus.com>
+
+	* ltconfig.in: For sunos4 using GNU ld, set hardcode_minus_L to
+	no.  For sunos4, add ${libname}.so$versuffix to
+	library_names_spec.
+	* ltmain.in: For version_type of sunos, set versuffix even if
+	-version-info was not used.
+
+
+Index: ltconfig.in
+===================================================================
+RCS file: /cvs/cvsfiles/devo/libtool/ltconfig.in,v
+retrieving revision 1.15
+diff -u -r1.15 ltconfig.in
+--- ltconfig.in	1998/07/07 18:16:40	1.15
++++ ltconfig.in	1998/07/07 20:17:41
+@@ -792,7 +792,10 @@
+   sunos4*)
+     archive_cmds='$LD -assert pure-text -Bstatic -o $lib$libobjs'
+     hardcode_direct=yes
+-    hardcode_minus_L=yes
++    # The GNU linker will only hardcode -L options if -rpath is not
++    # used, but we will be using -rpath because we set
++    # hardcode_libdir_flag_spec below.
++    hardcode_minus_L=no
+     hardcode_shlibpath_var=no
+     ;;
+ 
+@@ -1395,7 +1398,7 @@
+ 
+ sunos4*)
+   version_type=sunos
+-  library_names_spec='${libname}${release}.so$versuffix'
++  library_names_spec='${libname}${release}.so$versuffix ${libname}.so$versuffix'
+   finish_cmds='PATH="\$PATH:/usr/etc" ldconfig $libdir'
+   shlibpath_var=LD_LIBRARY_PATH
+   ;;
+Index: ltmain.in
+===================================================================
+RCS file: /cvs/cvsfiles/devo/libtool/ltmain.in,v
+retrieving revision 1.9
+diff -u -r1.9 ltmain.in
+--- ltmain.in	1998/07/07 18:16:40	1.9
++++ ltmain.in	1998/07/07 20:17:41
+@@ -1055,6 +1055,11 @@
+ 	  major=
+ 	  versuffix=
+ 	  verstring="0.0"
++	  case "$version_type" in
++	  sunos)
++	    versuffix=".0.0"
++	    ;;
++	  esac
+ 	fi
+ 
+ 	# Check to see if the archive will have undefined symbols.
+
+From nobody Wed Oct 14 16:54:59 1998
+X-From-Line: gord@gnu.org Fri Jul 10 03:57:28 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.fig.org
+Received: (qmail 8752 invoked from network); 10 Jul 1998 03:57:27 -0000
+Received: from localhost (127.0.0.1)
+  by localhost with SMTP; 10 Jul 1998 03:57:27 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id VAA00684 for <gord@m-tech.ab.ca>; Thu, 9 Jul 1998 21:57:29 -0600
+Received: from grande.dcc.unicamp.br by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id XAA08619 for <bug-libtool@gnu.org>; Thu, 9 Jul 1998 23:57:17 -0400
+Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11])
+	by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id AAA04102;
+	Fri, 10 Jul 1998 00:55:46 -0300 (EST)
+Received: from sunsite.dcc.unicamp.br (sunsite.dcc.unicamp.br [143.106.7.10])
+	by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with SMTP id AAA15536;
+	Fri, 10 Jul 1998 00:55:47 -0300 (EST)
+Sender: oliva@sunsite.dcc.unicamp.br
+To: Ian Lance Taylor <ian@cygnus.com>
+Cc: bug-libtool@gnu.org
+Subject: Re: SunOS problem in libtool 1.2b
+References: <199807072021.QAA00051@subrogation.cygnus.com>
+From: Alexandre Oliva <oliva@dcc.unicamp.br>
+Date: 10 Jul 1998 00:55:45 -0300
+In-Reply-To: Ian Lance Taylor's message of "Tue, 7 Jul 1998 16:21:20 -0400"
+Message-ID: <orww9mnyv2.fsf@sunsite.dcc.unicamp.br>
+X-Mailer: Gnus v5.6.23/XEmacs 20.4 - "Emerald"
+X-Emacs: 20.4 "Emerald" XEmacs  Lucid without mule
+MIME-Version: 1.0 (generated by SEMI 1.8.2 - "Kosugi")
+Content-Type: text/plain; charset=US-ASCII
+Lines: 21
+Xref: trick.fig.org libtool:1527
+
+Ian Lance Taylor <ian@cygnus.com> writes:
+
+> We need to set hardcode_minus_L to no.  Otherwise, libtool will set
+> LD_LIBRARY_PATH to find the library.  That fails if an older version
+> of the library has been installed, because the linker will search the
+> -L options before it searches LD_LIBRARY_PATH.
+
+> Unfortunately, it still doesn't work, because the gcc collect2 program
+> doesn't understand the -rpath option and can't find the shared
+> library.
+
+Setting LD_LIBRARY_PATH in addition to -rpath wil work.  I won't have
+time to implement this in the next few weeks, though, so I'd
+appreciate if someone went ahead and implemented it...
+
+-- 
+Alexandre Oliva
+mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
+http://www.dcc.unicamp.br/~oliva
+Universidade Estadual de Campinas, SP, Brasil
+
+From nobody Wed Oct 14 16:54:59 1998
+X-From-Line: gord@gnu.org Sat Jun 06 19:44:18 1998
+Return-Path: <gord@gnu.org>
+Delivered-To: gord@trick.profitpress.com
+Received: (qmail 28446 invoked from network); 6 Jun 1998 19:44:16 -0000
+Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
+  by 127.0.0.1 with SMTP; 6 Jun 1998 19:44:16 -0000
+Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id LAA00406 for <gord@m-tech.ab.ca>; Sat, 6 Jun 1998 11:39:58 -0600
+Received: from grande.dcc.unicamp.br by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id NAA21678 for <bug-libtool@gnu.org>; Sat, 6 Jun 1998 13:44:12 -0400
+Received: from amazonas.dcc.unicamp.br (amazonas.dcc.unicamp.br [143.106.7.11])
+	by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id OAA02601;
+	Sat, 6 Jun 1998 14:42:57 -0300 (EST)
+Received: from zecarneiro.lsd.dcc.unicamp.br (zecarneiro.lsd.dcc.unicamp.br [143.106.24.141])
+	by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with SMTP id OAA17009;
+	Sat, 6 Jun 1998 14:42:57 -0300 (EST)
+Sender: oliva@zecarneiro.lsd.dcc.unicamp.br
+To: Steve Snodgrass <ssnodgra@fore.com>
+Cc: amanda-users@cs.umd.edu, bug-libtool@gnu.org
+Subject: Re: Build failed with 2.4.0/SunOS 4.1.4
+References: <19980605154816.A8507@fore.com>
+From: Alexandre Oliva <oliva@dcc.unicamp.br>
+Date: 06 Jun 1998 14:38:01 -0300
+In-Reply-To: Steve Snodgrass's message of "Fri, 5 Jun 1998 15:48:16 -0400"
+Message-ID: <or67ieig7a.fsf@zecarneiro.lsd.dcc.unicamp.br>
+X-Mailer: Gnus v5.6.11/XEmacs 20.4 - "Emerald"
+X-Emacs: 20.4 "Emerald" XEmacs  Lucid without mule
+MIME-Version: 1.0 (generated by SEMI 1.5.0 - "Nishi-Ny,D~(Bzen")
+Content-Type: text/plain; charset=US-ASCII
+Lines: 40
+Xref: trick.profitpress.com mail.libtool:1481
+
+[cc to bug-libtool@gnu.org]
+
+Steve Snodgrass <ssnodgra@fore.com> writes:
+
+> I'm having a strange problem building the Amanda 2.4.0 release version on a
+> SunOS 4.1.4 system with gcc 2.8.1.
+
+> Here's the error message:
+
+> gcc -shared -o .libs/libamanda.so.5.0 alloc.lo amflock.lo debug.lo dgram.lo
+>    error.lo file.lo fileheader.lo match.lo protocol.lo regcomp.lo regerror.lo
+>    regexec.lo regfree.lo security.lo statfs.lo stream.lo token.lo version.lo
+>    versuff.lo memmove.lo snprintf.lo strerror.lo
+
+> ld: /usr/tmp/cca00800.o: assert pure-text failed: reference to [offset] at
+>    16504 in /usr/tmp/cca00800.o
+
+> Does anyone have any idea what might be causing this?  Thanks.
+
+This is a problem in libtool, not amanda.  You may work around it with
+--disable-shared or --disable-libtool, at configure time.
+
+However, I'm pretty sure the libtool maintainers, would be certainly
+interested in fixing this problem.  Unfortunately, amanda 2.4.0 uses
+an old version of libtool, so this problem may be fixed in the latest
+release already.  Would you please try the latest snapshot of amanda
+2.4.1, available from my home page (URL below), and see if this fixes
+your problem?
+
+If it does not, please send some more info to bug-libtool@gnu.org, for
+example, whether you're using GNU ld or not, whether libtool notices
+which ld you're using (running configure should tell you), and any
+further information you think might be useful.
+
+-- 
+Alexandre Oliva
+mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
+http://www.dcc.unicamp.br/~oliva
+Universidade Estadual de Campinas, SP, Brasil
+