Blackfin and version scripts

[Ralf Wildenhues]

* Werner Koch wrote on Wed, Jun 23, 2010 at 09:46:01AM CEST:
> On Wed, 23 Jun 2010 07:29, rra at stanford.edu said:
> 
> > I can take a pass at starting.  All that I need for my packages is to
> > support the basic version syntax:
> >
> >     <version> {
> >       global:
> >         <symbol>;
> 
> That would be sufficient for me too as long as a <version_2> with only
> global symbols is supported as well.
> 
> Having a second file with a simple list of symbols instead of a version
> script parser is another option.  Actually this is required because to
> support W32 we need a .def file
> 
>   EXPORTS
>       gcry_check_version  @1
>       gcry_control  @2
> 
> which allows to assign id numbers to symbols.  In theory we could add
> this via comment lines to a versions script but that would make a parser
> even more complicated.  In some projects I create the .def file from a
> .def.in file to handle differences between W32 and W32CE.  In any case
> the .def file is easy to parse and could be used as input to
> --export-symbols.

OK, so the problem space as I see it:

- complex GNU/Solaris ld version scripts, but most users need only a
  fairly simple part of that,
- w32 .def files,
- symbols lists or regexes as used by libtool,
- the wild card specification to use: ld uses globbing,
  -export-symbols-regex uses ERE.
- mangling relevant also for C: prepending underscore or not, appending
  calling convention suffixes @... on w32,
- mangling for non-C languages: C++, Java,
- libtool should be able to add or remove a few symbols to the list,
- for w32, we may need to tag DATA exports,

"Parsing" is hard in the shell.  It's probably easiest to define a
libtool-specific language ("file format") that is easily amenable to sed
or old awk, from which we can generate a ld version script, a def file,
or a list of mangled symbols.  That language could still allow the user
to specify arbitrarily complex version script constructions, as long as
they are given in a way our parser can easily ignore.  That's the hard
part.

A complicating factor in the current libtool handling for exports is
line length limitations: we might need to cope with partial links or
reloadable objects, or, preferably, employ one of the workarounds like
response files or linker scripts.  This part in ltmain I know how to
deal with, so if you need help there speak up.

Cheers,
Ralf