Public SourceMage Discussion List

[sergey AT optimaltec.com]

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.