Re: RFC: Better portability for package maintainers
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
Reply to: