[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