On Wed, 2009-11-11 at 22:27 +0000, Dmitry Eremin-Solenikov wrote: > I'm currently trying to restore/update blackfin toolchain. One of the major > problems I've stumbled upon > are versioned scripts/export symbols. Basically there are lot's of software > starting from g++ itself > that have symbol versioning scripts. The problem is that blackfin arch > prepends all symbols with underscore, > thus breaking all that scripts. > > My first intention was to follow the alsa-libs approach: handle all prefixing > on package-per-package basis. > However that would be a nigtmare. > > My current intention (that at least partially works) is to make libtool (when > it's used) generate correct > versioning scripts and resort to package-per-package updating after that. > > The problem comes from C++ world, where versioning script can contain > unmangled name, but it's demangled > name that should be prefixed with underscore. > > So I have a bit hackish idea: maybe it's better to hack ld to accept scripts > w/o underscores and prefix all > symbols with it? This will eliminate most of changes. The question is if this > patch is acceptable for OE? > Does this approach sound too hackish?
How do other Blackfin folks deal with this issue? It doesn't sound like there is anything OE-specific about the problem you are facing, and I would have thought that it is something that should be solved upstream rather than with a local hack in OE. Linker version scripts operate on symbol names, not on function names, so I don't think that having the underscores automatically added here would be appropriate. It is a little bit unfortunate that the Blackfin folks have decided to put these underscores in their symbols. The ELF gABI calls for symbol names to be the same as C function names (i.e. no prefix) and, although I guess the psABI is permitted to countermand that, the vast majority of architectures do follow the gABI convention. Underscore-prefixed symbol names are fairly common in the a.out and COFF worlds but of course there are no version scripts there so this issue does not arise. p. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
