[lsb-discuss] notes on LSB architecture addition

Steve McIntyre steve.mcintyre at linaro.org
Tue Jun 7 05:32:41 PDT 2011

Hi Mats,

Thanks for the notes - very useful!

On Sat, Jun 04, 2011 at 10:34:01AM -0600, Wichmann, Mats D wrote:
>I promised to write some notes on the addition and what to look at, 
>and then got swamped, then stuck in an email transition that caused
>me to lose track of the message I was going to reply to - sorry!
>I'm just sending this to lsb-discuss, I know some of the calls for
>participation have been rather widely disseminated, pass this on if
>needed (or it should end up in the mailing list archive)
>So...  the heart of all of the stuff is the LSB database.  This has its own
>web page, so you can read as little or as much as you like about it:
> There's a description of the schema, and the tables that are mostly
>involved are join tables that have "Arch" in them, as this is where
>a generic description is mapped into specifics for a particular
>architecture.  There are a few others (TypeMember and TypeMemberExtras)
>as well.

OK. Digging through it now.

>There's a patch file (sql instructions) which attempts to add ARM
>This isn't a branch so loggerhead is hiding it, I should move it
>somewhere else I guess.  The patch is done with no knowledge
>applied, just brute-force duplication of sets of existing records.

It would be nice to see it, yes. :-) If nothing else, I'm sure it'll
be useful for ideas.

>You don't need to set up the database to get started:
>there are two sets of files that have been generated from this -
>the bzr branches build_env and misc-test.
>build_env knows how to build in LSB mode, so it includes a compiler
>wrapper, "stub" (link-time-only) libraries, and headers.  In the header
>directory there are ordinary headers, and files suffixed .defs, those
>are used when the actual specification document is generated
>(defs for "data definitions") but are not interesting at this stage, they're
>basically single-architecture instances of the headers, with some
>other changes that are not worth describing, so if the headers are
>right, the defs will almost certainly also be right.
>so the main job is to understand whether the headers (structure
>layouts, constants, data types and sizes) are correct, and whether
>the symbol versioning (embedded in the stub libraries) is correct.
>two tools can help with this... both live in the other branch,
>misc-test.  The first is libchk, this is a checker for the presence of
>required symbols and libraries, and for those cases where symbol
>versioning is used, for the correct symbol versions.  So running
>a "make" in misc-test inside an ARM build enviroment (native,
>or I suppose cross would also work) will hopefully build an
>appropriate binary, then in libchk run "./lsblibchk" to generate a
>report.   With such a report we would have information to update
>the database, then continue to iterate until it's correct.
>the second tool is devchk... in misc-test/devchk/ts/devchk.
>this is a bunch of generated checks for each LSB library, and
>it's built in two modes:  using the native compiler, so that we can
>see if the descriptions in the database are aligned with the native
>headers for that architecture, then a second time with the LSB
>SDK (the stuff from build_env) so that it can check if things are
>self-consistent between the LSB headers and other information.
>Getting the native-build version clean is a pretty big job, it does
>generate sql instructions but the tool is not of high enough quality
>that these can just be applied verbatim.  We have a long list of
>wish-list items for devchk to improve it, but unfortunately nobody
>to work on making those improvements.   The main thing it gets
>wrong is rather relevant here:  it operates in isolation, and does not
>have knowledge of other architectures while it's working (irritating
>since the information is there, but #ifdef'd out), so it will often propose
>wrong -
>update FOO with details for Arch=1 (All) rather than with details
>for Arch=4 (ARM). 
>For browsing the database for details, we suggest the LSB Navigator,
>which also has a web page:
>the hosted instance of this does not have the experimental elements
>in it, but it's not too hard to set up a local instance (it's a bunch
>of php code, which connects to a mysql database instance, and
>there's really only two places you need to configure - password/name/
>other details of the db instance for navigator, and then whatever
>webserver setup is needed to actually allow access to the navigator).
>I imagine Linux Foundation could also host such an instance, but
>that's not mine to promise :)

Right. I'm setting up a local instance for now to get a feel for
things. I'll probably be back to add questions as and when... :-)

>There are conceptually two parts to the database, "LSB Elements"
>(which are things describing the ABI), and "Community Data"
>(which are captured details about distributions and applications
>that let developers understand more about where things are common
>and where they aren't).   As things evolve, it will be useful to scan
>some ARM-based distributions and add them to the Community
>Data, just so information will be available.  There's a tool for that,
>and it has a page on the wiki as well.

Steve McIntyre
steve.mcintyre at linaro.org

More information about the lsb-discuss mailing list