On 26/01/2012 14:53, Russ Allbery wrote: > 5. The exported symbols of the library contained many symbols that > obviously weren't really from that library, but instead were artifacts > of the C++ compilation process, things like instantiations of > std::vector. Do those go into the symbols file? Do they change from > architecture to architecture? If they disappear again, is that > actually an ABI break? How do I know? It's all very mysterious, and > while shlibs provides the same semantics as just ignoring this, at > least I'm not then including in the package data, generated by me, > things that I'm just blindly ignoring. Most upstream libraries don't usually have any std:: symbols that are meant to be exported. In the case of libzen and libmediainfo which I recently packaged, I just added the following to the bottom of my symbols file to ignore them: (optional|c++|regex)"^std::" 0.7.52 (optional|c++|regex)"^(bool|void|MediaInfoLib::File_Mxf::indextable\*) std::" 0.7.52 What I found most frustrating, though, was the size_t handling, which ends up being expanded into unsigned int on some architectures, and unsigned long on others, resulting in the same function (which takes a size_t parameter) being mangled differently per arch. I used the following workaround for size_t using functions: (c++|regex)"MediaInfoLib::MediaInfo::Count_Get\(MediaInfoLib::stream_t, unsigned (int|long)\)@Base" 0.7.52 And then there's also long double/__float128 (powerpc), which I worked around in the same manner. -- Kind regards, Loong Jin
Attachment:
signature.asc
Description: OpenPGP digital signature