Re: Partial symbol export vs --export-dynamic

[Jean-Francois Panisset <panisset at discreet dot com>]

 <20010617002625.A25139@lucon.org>"H . J . Lu" writes
>On Sun, Jun 17, 2001 at 01:20:02AM -0400, Jean-Francois Panisset wrote:
>> 
>> - does the ELF format on Linux support exporting only some of the applicatio
>n
>>   symbols, or does it have to all-or-nothing?
>
>It is a linker thing.

OK, that's good.

>
>> - how painful would it be for me to add this functionality to ld/bfd,
>>   or is this a project way beyond the scope of a binutils novice?
>
>If you know something about bfd, it shouldn't be too hard to implement.
>Personally, I think it is a useful feature. I may do it myself if we all
>agree it is a good feature to have and how it should work.
>
>
>H.J.

Well, no, I don't know anything about bfd, although it looks like
I may have to learn about it :-)

For reference, under IRIX, the man page for ld says:

     -exports_file file
               Used in conjunction with the -shared or -call_shared
               options.  The specified file must contain a list of symbols
               that should be exported.  The list is comprised of symbol
               names separated by spaces or new-line characters.  Any
               symbols not specifically exported will be automatically
               hidden.  (C, C++, F77, F90)

So we just have an ASCII text file with the list of API functions
to export. The API is relatively stable, it is no big deal to
add new functions to the text file when they are added to the API.

One small issue with the IRIX implementation is that since the text file
is specified at the linker stage, it doesn't know about name mangling,
so if you want to expose C++ symbols, you will need to stick mangled
names in that file. I don't see this as a big problem, unless gcc
name mangling is different on different platforms (is it?), in which
case it could be difficult to generate a portable exports file.

JF