[lsb-discuss] Enabling FP traps in LSB code

[Dallman, John]

> > Another way to "cheat" here is to use dlopen() to load the symbol.
> > Since it's at runtime, the build system won't complain, and 
> > our tests will even be fairly happy (we warn on dlopen() use, 
> > but it's still legal).

People here are rather down on dlopen(), because its behaviour tends 
to differ across UNIX platforms, but here it would be used for a 
completely platform-specific issue, so I can probably get away with 
it. It does seem better than telling the linker to ignore errors. 

> of course, John's product is a library, not an application;
> I don't know the ins and outs of having a library do dlopen
> mucking...

This is in the test harness, not the library. Said harness is 
deliverable to customers, but they rarely use it, and it never 
ends up on end-user's systems. it's a LISP interpreter with the 
whole library API implemented as keywords. This makes for a very 
powerful testing system.

-- 
John Dallman
Parasolid Porting Engineer

Siemens PLM Software
46 Regent Street, Cambridge, CB2 1DP
United Kingdom
Tel: +44-1223-371554
john.dallman at siemens.com
www.siemens.com/plm
 

> -----Original Message-----
> From: Wichmann, Mats D [mailto:mats.d.wichmann at intel.com] 
> Sent: Wednesday, November 14, 2007 5:34 PM
> To: Jeff Licquia; Dallman, John
> Cc: lsb-discuss at lists.linux-foundation.org
> Subject: RE: [lsb-discuss] Enabling FP traps in LSB code
> 
> lsb-discuss-bounces at lists.linux-foundation.org wrote:
> > Dallman, John wrote:
> >> I'm now trying to figure out a not-too-repulsive way of calling
> >> feenableecept() in a test harness that's linked with lsbcc from
> >> LSB 2.0. ((Yes, I know it's old. the code's pure C so it's
> >> upwards compatible, and we have a lot of customer on SLES9.
> >> Upwards compatibility is safer than downwards)).
> > 
> > [...]
> > 
> >> The closest thing I have found to an acceptable technique so far
> >> is to write a tiny shared library, liblsbescape.so. This exports
> >> a function called lsb_escape_feenableecept, which just calls
> >> feenableecept(). The code for this library is compiled with plain
> >> GCC, and linked against the ordinary libm.
> > 
> > Another way to "cheat" here is to use dlopen() to load the symbol.
> > Since it's at runtime, the build system won't complain, and 
> our tests
> > will even be fairly happy (we warn on dlopen() use, but it's
> > still legal).
> 
> well, to be petty, we can't detect if your usage when you go through
> dlopen, ioctl and fcntl remain LSB conforming, since with a static
> check we don't know what you're going to pass there.
> 
> it's not exactly clear if using an interface not defined in a
> particular LSB version is conforming usage or not.  it would be
> my impression that it's conforming usage if the application
> is prepared to deal with the consequences, for example, it doesn't
> just fall over and fail horribly if a symbol isn't found; we
> know in this case it will be found but the proper way would be
> to make sure there's a fallback position (perhaps with reduced
> functionality) if it isn't.
> 
> of course, John's product is a library, not an application;
> I don't know the ins and outs of having a library do dlopen
> mucking...
>