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
