Re: Ideas about the lib / lib64 names, subarchs, porting guidelines [Re: irc brainstorming notes]
Bart Trojanowski <bart@jukie.net> writes:
> * Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> [031209 16:55]:
> > > I am not sure if I agree with you there. It seems like you are taking
> > > the flexibility a bit too far.
> > >
> > > I can see why we need to have /lib and /lib64, but I don't see the need
> > > of having i386 and i686 libraries installed concurrently. If your
> > > application requires a 32bit version of a library it should not care if
> > > it's i386 or i686. Things will still run if you have one or the other
> > > -- unlike the case of i386 vs amd64.
> > >
> > > I could be missing something however.
> >
> > Its just the way it currently works. openssl puts a i386 lib into
> > /usr/lib and an optimised lib into /lib/i686/cmov. The ld will pick
> > the faster one if the cpu supports i686/cmov features.
>
> Oh, ok. Then I will not worry about it since it sounds like there is no
> extra support to be added.
>
> It will be likely that instead of installing libssl-i686-version_i386
> ppl will start o building libssl-version_i686... that is once there is
> support for it. Then this whole /lib/i686 could go away, no?
Could. A i686 autobuilder (or a way to get the i386 to compile for a
different target) would be needed.
Not sure how i484, i586, i686 debs are supposed to be build anyway?
There isn't realy any support to recompiled for a better arch. I guess
they would need a gcc wraper that adds -mcpu=i686 instead of our
-m32/64.
But not our problem.
MfG
Goswin
Reply to: