[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