added message with -export-symbols syntax for various platforms

This commit is contained in:
Alexandre Oliva 1998-11-21 06:40:20 +00:00 committed by Alexandre Oliva
parent d4326213cb
commit 073f9e6582

View File

@ -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.