* Werner Koch wrote on Wed, Jun 23, 2010 at 09:46:01AM CEST: > On Wed, 23 Jun 2010 07:29, r...@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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool