[lsb-discuss] State of LSB

[Rob Conde]

Thanks for the response Mats...I was starting to wonder if there was anyone out there :)

So some background. I'm looking at distributing a commercial application on linux in binary form only. Practically speaking I would probably only officially support a fixed set of distros/versions, but it would nice if the application worked on as many distros as possible. For these requirements LSB notionally seemed like a good fit.

I've gotten a bit further with my progress since I first wrote the list. I got most of my shared library dependencies building under LSB (including boost 1.55 though I had to exclude a few libraries that I don't use and hack the linux.hpp header a bit:

http://boost.2283326.n4.nabble.com/thread-linux-hpp-BOOST-HAS-PTHREAD-YIELD-BOOST-HAS-SCHED-YIELD-td4668324.html

)

However then I hit a roadblock with the template-only library eigen (http://eigen.tuxfamily.org/index.php?title=Main_Page). The simple test:

#include <Eigen/Dense>

int main(int argc, char ** argv)
{
   Eigen::MatrixXd m1;
   Eigen::MatrixXd m2;
   
   Eigen::MatrixXd m3 = m1*m2;
   
   return 0;
}

compiles fine on g++ 4.6. On lsbc++ w/gcc 4.6 however I get,

---------------------------------------------------------------------------------------------------------------
In file included from Eigen/Core:330:0,
                 from Eigen/Dense:1,
                 from simple.cpp:1:
Eigen/src/Core/products/GeneralMatrixMatrix.h: In static member function ‘static void Eigen::internal::general_matrix_matrix_product<Index, LhsScalar, LhsStorageOrder, ConjugateLhs, RhsScalar, RhsStorageOrder, ConjugateRhs, 0>::run(Index, Index, Index, const LhsScalar*, Index, const RhsScalar*, Index, Eigen::internal::general_matrix_matrix_product<Index, LhsScalar, LhsStorageOrder, ConjugateLhs, RhsScalar, RhsStorageOrder, ConjugateRhs, 0>::ResScalar*, Index, Eigen::internal::general_matrix_matrix_product<Index, LhsScalar, LhsStorageOrder, ConjugateLhs, RhsScalar, RhsStorageOrder, ConjugateRhs, 0>::ResScalar, Eigen::internal::level3_blocking<LhsScalar, RhsScalar>&, Eigen::internal::GemmParallelInfo<Index>*)’:
Eigen/src/Core/products/GeneralMatrixMatrix.h:157:5: error: there are no arguments to ‘alloca’ that depend on a template parameter, so a declaration of ‘alloca’ must be available [-fpermissive]
Eigen/src/Core/products/GeneralMatrixMatrix.h:157:5: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
Eigen/src/Core/products/GeneralMatrixMatrix.h:158:5: error: there are no arguments to ‘alloca’ that depend on a template parameter, so a declaration of ‘alloca’ must be available [-fpermissive]
Eigen/src/Core/products/GeneralMatrixMatrix.h:159:5: error: there are no arguments to ‘alloca’ that depend on a template parameter, so a declaration of ‘alloca’ must be available [-fpermissive]
In file included from Eigen/Core:332:0,
                 from Eigen/Dense:1,
                 from simple.cpp:1:
--------------------------------------------------------------------------------------------------------------
...and a bunch more similar errors. The documentation for eigen says the library supports gcc 4.1 and newer. 

My assumption here is that this fails because of the out-of-date headers shipped with the LSB sdk (that could be wrong).

Some questions:
 - for the purposes of library compatibility, is there an equivalent version of gcc to map to? (e.g. LSB 4.1 is like compiling with gcc 3.2)
 - Am I stuck with the delivered headers (in order to compile to LSB) or is there some other approach?
 - Similar questions to using C++11 etc features...if the compiler can handle it, seems unfortunate to be locked out because of old templates

I don't know if there was a plan to update the headers for LSB 5. I'm afraid of getting stuck on a very old lowest-common-denominator if I take the LSB approach. My current alternative is to pick the oldest distro I want to support and just build on that normally (assuming that works).

It's unclear to me whether the other approaches you mentioned (docker, etc.) would be appropriate for me.

Thanks for your time. I very much appreciate your guidance.

Looking forward to your thoughts,
Rob Conde
________________________________________
From: lsb-discuss-bounces at lists.linux-foundation.org <lsb-discuss-bounces at lists.linux-foundation.org> on behalf of Mats Wichmann <mats at wichmann.us>
Sent: Saturday, October 18, 2014 6:34 AM
To: lsb-discuss at lists.linux-foundation.org
Subject: Re: [lsb-discuss] State of LSB

On 10/15/14 13:31, Rob Conde wrote:
> I am looking into targeting LSB for an application, but based on various documents and resources I've found I'm a bit confused about the state. For example, the Sample Implementation and lsb-buildenv appear to be gone but the documentation isn't clear about that change (most documents still reference these things)...is the idea to only use lsbcc and lsbc++ going forward? Is LSB still a recommended approach, or has it been supplanted by something else?
>
>
> Thanks for your input,

I sent an answer a couple of days ago but apparently it didn't go out.

The si faded away due to disuse - there just weren't resources to
maintain it in light of that.

The SDK (lsbcc) should work pretty well for producing an app, and we can
give you tips here as needed.  LSB itself isn't so much of a priority in
the linux space any longer, seems people are trying other approaches for
apps (docker, software collections, you name it).

Perhaps if you let us know what you're trying to accomplish we can
provide further suggestions?
_______________________________________________
lsb-discuss mailing list
lsb-discuss at lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss