Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] amd64 /lib64 to /lib conversion fixes and adventures.

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: sergey AT optimaltec.com
  • Cc: Karsten Behrmann <BearPerson AT gmx.net>, sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] amd64 /lib64 to /lib conversion fixes and adventures.
  • Date: Mon, 18 Apr 2005 09:59:21 -0700

Sergey,

I don't disagree with you. I want the symlink to be default (widest
compatibility). I just want the later option of removing it (I don't
run anything proprietary). Also my fixes make the benoit iso relatively
usable without symlink hacking. Not that it matters, though, future
isos will have the symlink by default while this one doesn't.

Seth

On Mon, Apr 18, 2005 at 10:20:42AM -0500, sergey AT optimaltec.com wrote:
> Karsten,
>
> Please read the link I supplied, it has my position spelled out: no mixed
> 32-
> and 64-bit executables. So, my point is not that I'd like both lib and lib64
> populated. It's the "no lib64 symlinks" idea that I'm opposed to. I'd like
> lib64 symlinks to exist for compatibility with LSF (if there's such
> requirement) and with binary 64-bit spells (I don't like supporting 32-bit
> binaries in 64-bit environment, because it's a lot of work for nothing).
> I believe installwatch follows symbolic links and records stuff installed
> into
> /lib64 symlink as going into /lib. This seems to work just fine with current
> devel sorcery.
>
> Quoting Karsten Behrmann <BearPerson AT gmx.net>:
>
> > On Mon, 18 Apr 2005 07:54:51 -0400
> > "Sergey A. Lipnevich" <sergey AT sourcemage.org> wrote:
> >
> > > Seth,
> > >
> > > Isn't lib64 required by LFS? Also, there's always software we can't
> > > recompile, such as Oracle database or VMWare, that people will need to
> > > run. To make this work, these links will be needed.
> > > I don't feel good about this approach in general. I don't suffer from
> > > lib64 links. After the procedure described here [1], Benoit's ISO works
> > > just fine for me. We have an option to disable multilib build of GCC
> > > which works great. I and others contributed fixes to make 64-bit spells
> > > work, and having this link was never an issue. I think *not* having it
> > > would have been.
> > > Why is having these links such a big deal?
> >
> > Well, currently we don't have quite all the developers we'd like to have.
> > This freezes development on the proj2 branch of sorcery,
> > the only branch that can actually work with these paths("bi-arch").
> > Normal procedure would be to just decide if you want to run in 64 bits or
> > 32.
> > Then you'd have /lib and /usr/lib like any regular system.
> > If you really need both, probably the best solution is to have a chroot
> > for
> > the other.
> >
> > As for symlinks, installwatch (the tool we use for tracking files as they
> > are
> > installed) does not like them currently, therefore we're careful with
> > them.
>
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737 F2FF 7A3F 6D3C 00BA 3AF3
Security Team Member Source Mage GNU/Linux http://www.sourcemage.org
Elected Coordinating Committee Member, Pacific Green Party of Oregon

Attachment: pgpqhPLRHkMkg.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page