This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Partial symbol export vs --export-dynamic
- To: Jean-Francois Panisset <panisset at discreet dot com>
- Subject: Re: Partial symbol export vs --export-dynamic
- From: Ben Elliston <bje at redhat dot com>
- Date: Mon, 18 Jun 2001 12:38:00 +1000 (EST)
- Cc: "H . J . Lu" <hjl at lucon dot org>, binutils at sources dot redhat dot com
- References: <hjl@lucon.org><20010617002625.A25139@lucon.org><200106170748.DAA877699@cuba.discreet.qc.ca>
>>>>> "Jean-Francois" == Jean-Francois Panisset <panisset@discreet.com> writes:
Jean-Francois> So we just have an ASCII text file with the list of
Jean-Francois> API functions to export. The API is relatively
Jean-Francois> stable, it is no big deal to add new functions to the
Jean-Francois> text file when they are added to the API.
Reading through your message, I was about to fire off a reply asking
"What about C++?", but then I see you've noted how IRIX deals with
that:
Jean-Francois> One small issue with the IRIX implementation is that
Jean-Francois> since the text file is specified at the linker stage,
Jean-Francois> it doesn't know about name mangling, so if you want
Jean-Francois> to expose C++ symbols, you will need to stick mangled
Jean-Francois> names in that file. I don't see this as a big
Jean-Francois> problem, unless gcc name mangling is different on
Jean-Francois> different platforms (is it?), in which case it could
Jean-Francois> be difficult to generate a portable exports file.
I see no reason why it shouldn't be possible for you to list C++
symbols in an unmangled form and let the linker mangle them as the
export file is processed. Am I missing something, anyone?
Ben