RE: Initial patch for toolset modification proposal

>> Here's my understanding of argument requirements:
>> LSB_PRODUCT=3Dcore:     LSB_Core + Graphics + Cpp
>> LSB_PRODUCT=3Ddesktop:  LSB_Core + Graphics + Cpp + Graphics-Ext + =
XML
+
>> GTKVTS
>
>At the moment, desktop is actually defined as LSB_All_Modules;
reasoning
>being, that all defined modules fall under core/desktop.
>
>> LSB_PRODUCT not set:  LSB_Core (only, no Graphics & Cpp) //this was
the
>> behavior before desktop was introduced ...do we want to change this?
>
>Rephrasing it a bit, unset/invalid results in LSB_Core | LSB_Graphics |
>LSB_Cpp , old was LSB_Core only.
>
>Open to suggestions on that one; offhand, to me it seems a bit odd to
have
>unset differ from what the core 'product' comprises though.
>
The initial thought behind this was to allow implementations to certify
only for the "Core-core" libraries and not the Xt part i.e. Graphics.
IMHO, it is OK to say that "default =3D Core + graphics + Cpp". For any
subset, the -M approach may be used. Unless there are any objections...

>> -M option: should allow the binary (or library if -L specified) to be
>> checked against each individual module, irrespective of -T and
LSB_TARGET
>> settings. To enable this, each of the desktop modules will need a
hash
>> define in elfchk.h.
>
>No changes to -M handling via this patch. Digging into util.c a bit,
the
>only defined modules are
>
>LSB-Core
>LSB_Graphics
>LSB_Cpp
>
>So util.c needs a bit of an overhaul- long term, I'd rather those
modules
>were pulled from the db- so next release, manual work isn't required.
>
Good idea. Shouldn't be too complicated.

>Guessing short term, probably continue the hard coding in util.c and
>elfchk.h?
>
>One thing I could use if someone has available, is an updated specdb-
>what's in cvs right now seems to lack the 3.1 additions (thus my local
db
>lacks all 3.1 additions).  Meanwhile, the modules I know about from
>grepping a copy of dynsyms.c from rajesh are-
>
>LSB_Core
>LSB_Cpp
>LSB_Graphics
>LSB_Graphics_ext
>LSB_Toolkit_Gtk
>LSB_Xml
>
>Are there any others I'm missing?
>
Maybe there will be another one for Qt going forward.

>> Some additional comments:
>> * LSB_All_Modules should set flags for each of the desktop modules
>> individually i.e. Graphics-Ext, XML, GTKVTS or else while looking for
>> symbols in the DynSyms array, the desktop symbols will be excluded.
>
>Currently, activated modules are controlled via bit masking;
>LSB_All_Modules just sets the field to 0xff, thus no symbols are
filtered
>(this obviously will break when the number of modules exceeds 8
however).
>
LSB_All_Modules=3D0xff is the right thing to do. But assuming
LSB_Desktop=3DLSB_All_Modules may not be the right approach if we want =
to
allow implementations to certify only for specific modules. It may hold
true for this release, but may not be a long term approach. Also, as
discussed above, we should allow flag setting for each individual
desktop module.=20

-Rita