added message with -export-symbols syntax for various platforms

1 files changed, 101 insertions, 0 deletions

diff --git a/mail/deplibs b/mail/deplibs
index dcfcb22d..a298728f 100644
--- a/mail/deplibs
+++ b/mail/deplibs
@@ -507,3 +507,104 @@ portability, we want to keep the number of cases of 1.4 to a minimum.
 Cheers,
 	Gary.
 
+From wmperry@aventail.com Sun Nov  1 01:03 EDT 1998
+Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8])
+	by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id BAA29973
+	for <oliva@amazonas.dcc.unicamp.br>; Sun, 1 Nov 1998 01:03:04 -0200 (EDT)
+Received: from slow.bp.aventail.com (vina05.cntwk.net [207.205.120.131])
+	by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id BAA10397
+	for <oliva@dcc.unicamp.br>; Sun, 1 Nov 1998 01:02:59 -0200 (EDT)
+Received: from kramer-fast.bp.aventail.com (kramer-fast.bp.aventail.com [192.168.200.2])
+	by slow.bp.aventail.com (8.8.5/8.8.5) with ESMTP id SAA31093;
+	Sat, 31 Oct 1998 18:03:52 -0800
+Received: (from wmperry@localhost)
+	by kramer-fast.bp.aventail.com (8.8.5/8.8.5) id WAA21542;
+	Sat, 31 Oct 1998 22:04:49 -0500
+Sender: wmperry@aventail.com
+To: Gordon Matzigkeit <gord@trick.fig.org>
+Cc: Alexandre Oliva <oliva@dcc.unicamp.br>
+Subject: Re: libtool 1.2 problems...
+References: <199810251708.MAA02237@kramer-fast.bp.aventail.com> <oryapxaste.fsf@araguaia.dcc.unicamp.br> <86zpac2z99.fsf@trick.fig.org>
+Errors-to: wmperry@aventail.com
+Reply-to: wmperry@aventail.com
+X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
+ x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
+ [WJopW_J.WY;
+Mime-Version: 1.0 (generated by tm-edit 7.108)
+From: wmperry@aventail.com (William M. Perry)
+Date: 31 Oct 1998 22:04:49 -0500
+In-Reply-To: Gordon Matzigkeit's message of "31 Oct 1998 15:32:50 -0600"
+Message-ID: <867lxgazam.fsf@kramer-fast.bp.aventail.com>
+X-Mailer: Gnus v5.6.8/XEmacs 21.0 - "Pyrenean-pre6"
+Content-Type: text/plain; charset=US-ASCII
+X-Content-Length: 2306
+Xref: araguaia.dcc.unicamp.br libtool-deplibs:9
+Lines: 66
+X-Gnus-Article-Number: 9   Fri Nov 20 23:23:12 1998
+
+Gordon Matzigkeit <gord@trick.fig.org> writes:
+
+> >>>>> Alexandre Oliva writes:
+> 
+>  AO> I can understand why we'd want all that stuff on systems with
+>  AO> brain-damaged dynamic linkers or such, but on Linux?  Gord?
+> 
+> No specific reason.  I was trying to implement something that would
+> work on all platforms, including Linux.
+> 
+>  >> I think optionally having a PUBLIC_API preprocessor macro or
+>  >> something might be handy.
+> 
+>  AO> Thomas Tanner has recently submitted a patch that implements
+>  AO> that, I think.  I still couldn't find the time to look carefully
+>  AO> at the patch, but, from the text description, it looks like
+>  AO> that's exactly what it does.
+> 
+> I think it's a good idea to be able to specify global symbols
+> explicitly.  That's part of the glibc versioning system that I was
+> alluding to earlier.
+> 
+> If you look at the `--version-script' option to GNU ld
+> ((ld.info)Version Script.), then you'll see more details.
+
+  To restrict globally visible symbols, here's the info I've got. :)  i've
+been using this for quite a while in our server product.  All hail the
+NSA.
+
+Linux: '--retain-symbols-file <FILENAME>' , with all the symbols you want
+       exported in <FILENAME>
+
+OSF1: '-hidden -exported_symbol "symname-or-wildcardspec"'
+
+AIX: you just restrict what you but in the export list you pass to
+     -bE:<FILENAME>.
+
+HP/UX: '+e symname' on the link line for each exported symbol you want
+
+Solaris: create a map file for the linker that looks like:
+	{
+	 global:
+	  symname1;
+	  symname2;
+	  symname3;
+	 local:
+	  *;
+	}
+
+	And use -M <MAPFILE> on the link line.
+
+BSD/OS 3.x is the only system I couldn't find a way to support this symbol
+hiding on.  But you might be able to do it better with BSD/OS 4.x now that
+they have finally moved to elf.
+
+BTW: What are the subscription directions for libtool-bugs or a general
+discussion list for stuff like this?  I've had lots of experience over the
+last 3 years with dynamic loading on various platforms, and would love to
+get libtool to the point where I could use it for all of our products here
+at aventail.  Less stuff for me to officially maintain. :)
+
+I'd also like to see DLD 4.x eventually so that I can just support it and
+ditch all the crufty junk we are using right now. :)  Abstraction good.
+
+-Bill P.
+