On Sun, 2006-05-21 at 17:09 +0200, Tollef Fog Heen wrote: > Erast Benson wrote: > > On Sun, 2006-05-21 at 10:44 +0200, Tollef Fog Heen wrote: > > >> Then provide the Solaris libc and other support libraries somewhere > >> proprietary applications can use them, while building your system around > >> glibc. > > > > It is not easy possible to achieve. I'd say it would be impossible to > > make it clean. The better way which we could follow in the future is to > > port missing GLIBC functionality to SUN C library. > > Uh, why would that be hard? Solaris and Linux binaries doesn't hardcode > the same elf interpreter, so you'd just put the solaris ld.so in > /usr/lib (where it's hardcoded that it should go) and make sure its > default rpath includes something like /usr/lib/sparc-sunos-sun (or what > the architecture's triplet is). You'd obviously want to ship the > Solaris libc and any other needed libs there.
I'm not saying it will be hard. All I'm saying is that it will be impossible to make it clean.. Think about dual-architectures which are common these days. You'll pretty much need to duplicate your mulitarch libraries set by 2. Also, resulted OS will have 2 standard libraries which is not sounds clean enough too, for instance you'll need to provide 2 sets of localizations mechanisms one is sunc-way another is glibc-way. Keep in mind that Networking stack is pretty much always platform dependent, so it is not like you could provide OpenSolaris libraries as an add-ons. They needs to be present and needs to be compiled against sunc. Talking about compilations and naming conflicts, they are going to be all over and you will be forced to resolve it one way or another. And who knows what else? -- Erast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]