Messages in this thread | | | Date | Sat, 13 Mar 1999 19:48:36 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: [OFFTOPIC]: MS Porting Office to Linux? |
| |
On Sun, 14 Mar 1999, CaT wrote:
> Richard B. Johnson wrote the following: > > > > On Sat, 13 Mar 1999, Mike A. Harris wrote: > > > > > And what is the difference between static linking, and dynamic > > > linking that requires a specially distributed shared library that > > > must be used? > > > > > > I fail to see the difference. If the shared library isn't the > > > one that everything else on the system uses, then IT ISN'T > > > SHARED. In other words, if commercial program A required library > > > B to be used, and only program A is using it, then nothing is > > > sharing the library, and the application might as well statically > > > link in the first place as it will consume the same resources, > > > and perhaps be a bit slower due to dynamic linking. > > > > Vendor X has no idea what shared libraries exist in/on your system. > > To make certain that Vendor X's executable works, he provides some. > > What pissed me off was not so much that it used it's own glibc but > because it would not let me use mine. > > What they should've done is had the setup program say > > glibc 2.0.7 could not be found on your system. It is recommended that you > use glibc 2.0.7 with Star Office. This version of glibc has been provided > with this release of Star Office. Please read X for details of how to > install and exit the setup now. If you wish to have Star Office use > the curreently installed version of glibc then simply continue. > > Would you like to exit and install glibc 2.0.7 or continue regardless? (x/c)
In this case, they would have done the installation in the old VAXen way. The final link would have been to the libraries on your system. This is great if, and only if, they have faith in the libraries that exist on your system. In the case of Digital, they would have no choice since DEC didn't distribute source and let you hack around with it. In our case, they really didn't have too much of a choice but to distribute in with known working libraries.
Properly installed, it doesn't muck with your libraries. Its libraries go into /opt/Office50/lib. You are certainly not going to link your programs against it (unless you want to), you would need:
gcc -L/opt/Office50/lib
... on the command-line.
As long as the libraries are not put in the 'standard places' you shouldn't have a problem. If you do chose to link against their libraries, you have to provide a hint as to where to find them when the program starts. This is where LD_LIBRARY_PATH is useful.
Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.2.3 on an i686 machine (400.59 BogoMips). Warning : It's hard to remain at the trailing edge of technology.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |