[lsb-discuss] LSB conf call notes for 2008-07-16

Jeff Licquia jeff at licquia.org
Wed Jul 16 09:56:23 PDT 2008


Attendees: Jeff Licquia, Jesper Thomschultz, Mats Wichmann, Brian 
Proffitt, Kay Tate, Ted Tso, Vladimir Rubanov, Alexey Khoroshilov, 
Robert Schweikert

Jeff: New conf call service working?  Robert: works.  Mats: access code 
entry is a little less robust, but not a huge problem.  Ted: while it 
asks for a name, it doesn't replay it.  There's a special code for the 
moderator who gets those.  Jeff: moderator code might be useful.  Ted: 
will get it to you; can do other cool things, like get a MP3 of the call.

Multiversion lsbcc.  Mats: probably works, no one seems to have done 
much with it other than using the default version.  Vladimir: has been 
tested at ISPRAS.  Jeff: will compatibility hacks turn off for LSB 4? 
Mats: yes.

Mats: appchk is having issues with multiple symbols.  Patch committed. 
Used to stop with the first symbol encountered, and only check that; now 
we check all versions of a symbol.

Best-effort.  Jeff: first problem is with init priority.  Priority is a 
recent addition to gcc (4.2 or 4.3).  Do we limit building to versions 
with init priority?  Ted: worst-case scenario?  Jeff: can call 
constructors for C++ objects before a re-exec.  This could lead to bad 
things if the constructors have side-effects.  No good way to know which 
destructors we need to call first.  Ted: should use init priority if we 
can.  Jeff: need to test if older gcc can link an init function build 
with an init priority using newer gcc, and if the resulting executable 
respects init priority.  Ted: could also write a tool that rearranges 
the init section as a post-processing step.  Jeff: may work.  Ted: may 
just register this as a potential issue.  Also need to consider whether 
this will work for Intel and PGCC compilers.  Jeff: we should continue 
to support the old dynamic linker system, which may cover those 
compilers.  Also, may just need different init functions for those 
compilers.  Ted: should start using best-effort instead of building some 
of the checkers with LSB support turned off.

argv.  Jeff: in order to do the re-exec for best-effort, we need to 
access argv before it's passed to us in main.  How?  Currently, the code 
uses /proc/self/cmdline.  If we do this, we need to add that (and 
/proc/self/exe) to the LSB 4 spec.  Ted: probably only other way is to 
modify crt0.o or poke into it.  Jeff: standardize /proc/[pid]?  Ted: 
probably OK; the other /proc stuff is more dangerous.  Mats: looks kinda 
ugly.  libc has __libc_argv and __libc_argc; don't know if it's 
available early enough.  Ted: would have to add to the standard.  Which 
is uglier: /proc or __libc_argv?  getopt uses __libc_argv, as does 
dlopen.  Ulrich will probably object.  Mats: marked as hidden.  Ted: 
doesn't even seem to be exported.

Ted: potential objection: camel's nose.  Some parts of /proc/[pid] are 
not as stable.  Also, we may want to mention that /proc/self and your 
own PID are the only legal ones, due to SELinux and the like.  Jeff: to 
combat that, we should make sure we only add stuff to the /proc standard 
after approval from the kernel hackers.

Jeff: float trial balloon?  Ted: let's write the doc first, then send it 
to LKML for review.  Jeff will write up a proposed spec and send to 
lsb-discuss first.  Ted: stick to just what we need for now.

Jeff: no good way to distinguish between native binaries and binaries 
that use best-effort.  How do we test executables for it?  Ted: add a 
note in the ELF header.  Could also create a chroot to test the 
executable in.  Jeff: may be easiest to assume people aren't lying to 
us.  Ted: could also embed a special code, but would have to document in 
the spec.

Quick run-through of high-priority tasks.  Mats: Xext is easy.  Ted: 
didn't we decide that last time?  Mats: yes, but still need to decide 
how much of the structure to expose.

Jeff: also, no progress of ALSA.  Mats: not much feedback.  Jeff: also 
need a test suite.

Mats: Stew is working on a proof-of-concept on RPM build tool.  Talked 
about last week.

Ted: Dan Kohn has been talking to Moblin and LiMo, may be interest in 
getting some limited profile for those projects.



More information about the lsb-discuss mailing list