[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

But not our problem.


Reply to: