Re: X and LSB
On Thu, 16 Mar 2000, Aaron Gaudio wrote:
>
> Similarly, one can write a package which requires glibc2.1 and won't
> settle for less. The problem is, as such a vendor (rhetorically), I want to
> make sure that my product will reach the "common" Linux market. It is not
> sufficient for me to say, "My product depends on glibc2.1, so go and get it".
> I want to move where the majority of my market is, so the question for me
> becomes "I want to have a product that will 'just work' on as many Linux
> boxes as possible (of course, within the constraints demanded by the nature
> of the product), so what target would be the best one for my product to
> depend on? glibc2.0 or glibc2.1? etc". When I don't know the answer I either
> am forced to guess, or forced to produce two or more versions of the product,
> each tailored to the appropriate system. I shouldn't have to worry about that.
>
> LSB can define a standard that would say, for instance, that glibc2.0 will
> be available on any LSB-compliant system, so depend on glibc2.1 at your
> own peril.
>
> These issues do not stop at the C Standard Library. For graphical software,
> vendors want to know what toolkit they can count on people having, what
> version of the libraries they will have, what capabilities they can count
> on their GUI having. These are important issues. Are they important to all
> users? Of course not. Then again, what version of libc++ is installed
> in users' systems is not important to everyone either.
>
> Not really. We already have FHS and one can debate how well it is adhered
> to, but it is out there. We already have dependancy checking in all the
> major package formats. The question is, how can application developers avoid
> having to support multiple OS configurations (libc5/glibc2.0/glibc2.1, for
> example), and instead concentrate on producing better software? Compatibility.
> If there is a large market of X-based applications, it is not enough to
> define how to see what version of X is installed, it is necessary to say
> what version of X *will* be installed (or a backwards-compatible version
> thereof) in a standards-compliant system. Bleeding-edge folks will have
> to wait for the standard to catch up with them and in the meantime, roll
> the dice.
>
That is why, if i were a commercial software house, i would consider
the possibility to produce a statically linked version of my product.
Of course, dependending on what kind of product i am
developing this could be an advantage, also for perfomance issues.
This is way that mathematica comes, and i would bet
it is linked against libc5.
they do not have portability and compatibility issues.
Big applications that need a big ammount of memory to do their work,
will not have problems if they are statically linked.
if i am developing something that will be used by more than one user at
the same time,
then i will make a dinamically linked version against glibc 2.1, but i
will not use libraries siblos take are not present also in
glibc 2.0. anyway the compatibility issue should not be present.
The real problem comes with c++, but then libstdc++ for commercial
software
should really be "ever" statically linked.
Luigi Genoni
Reply to: