[lsb-discuss] LSB -- next 4.1

Robert Schweikert rschweikert at novell.com
Thu May 28 12:32:50 PDT 2009



Dallman, John wrote:
> Well, for any given release of a Linux distribution, there is a 
> compiler that is in some senses part of the OS - the one that 
> was used to build that release. 

Yes, but what if that compiler is not gcc, for whatever reason. A good 
recent example is Debian switching to eglibc. Since the LSB doesn't tie 
anyone to glibc, but the interfaces Debian can still be LSB compliant.

There are certainly a lot of details to consider, that's why I think a 
compliant OpenMP library may be faster to achieve.

> 
> I absolutely agree that installing another compiler because an 
> application needs its support libraries is unacceptable. 
> 
> My problem comes if I ship a libgomp.so accompanying my product
> (which is a library, not an application) and it needs some non-
> LSB interface. Suddenly, I'm no longer LSB-compliant. And at 
> present, libgomp can't be LSB-compliant owing to syscall(). 

Yes, that would have to be fixed.
> 
> Even with an LSB-compliant libgomp, I need to be rather careful 
> about where I tell my customers who write applications to install
> it. Some creative genius will doubtless try to replace the 
> copy in /usr/lib64, rather than keeping it as part of their app. 
> 
You could link you library with rpath and put the shipping OpenMP 
library right next to it to avoid this problem.

Anyway, I think the next step would be to look at the interfaces for the 
various libraries that implement OpenMP and see if there is any commonality.

Robert
-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
Software Engineer Consultant                          LINUX
rschweikert at novell.com
781-464-8147

Novell
Making IT Work As One


More information about the lsb-discuss mailing list