[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 Schweikert                           MAY THE SOURCE BE WITH YOU
Software Engineer Consultant                          LINUX
rschweikert at novell.com

Making IT Work As One

More information about the lsb-discuss mailing list