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

Re: [K12OSN] Almost ready for v2.1.2

On Tue, 5 Nov 2002, Eric Harrison wrote:

> >herrold said: 
> >you are of course right -- but rebuilding the dynamic linker
> >run-time bindings for that chroot is (and must be) harmless,
> >or there is a deeper problem.
> Is it harmless? It is obviously ok if the server & the terminals are
> the same architecture, but what if they are different? 
> Will "ldconfig -r /opt/ltsp/sparc" work if the server is an i386?
> Or better yet, will "ldconfig -r /opt/ltsp/i386" work if the server is 
> an IBM 390? Or a HP9000 runing HP-UX? Or a Sparc running Solaris?

Fair questions, and I have not tested with the HP network boot
X-terminal I have over in my garage.  It does NOT appear that
LTSP is currently carrying a separate ldconfig or ld.so,
varying by ARCH, although in light of your questions, the
answer of whether it should is unclear:

[herrold www ltsp]$ man ldconfig
[herrold www ltsp]$ find /opt/ltsp -name ldconfig -print
[herrold www ltsp]$ man ld.so
[herrold www ltsp]$ find /opt/ltsp -name ld-linux.so.2 -print
[herrold www ltsp]$

My instinct is the answer will turn out to be that we do need
to address this for cross-arch installs; that x86 is
compatible across the line [see below -- the 686 library build
variant linker is present on the current LTSP production
release]; that the answer for 32 and 64 bit Sparc or a MIPS
4000 RISC box is unknown; and that 32 and 64 PA-RISC will be
interesting [the buildout of the 64 bit PA-RISC is in the
early stages for the Linux kernel; if we are providing a
binary tftp image from the manufacturer there is no
maintenance capability and thus no issue, absent sources.]

The man pages offers no help on whether the either ldconfig
_or_ the loader is capable of using differing architectures.  
ELF headers should be just data to ldconfig; the loader will 
need to be binary compatible on the run host processor arch.

While my understanding the library loader is not such that I
can say without research, the inspection method indicates that
there is not yet an issue here.  That said, it may be prudent
to place content in /opt/ltsp/i386 relying on dynamic, or 
carrying static x386 libraries and not the later post 486 
Intel microcode extensions.

... The number of binaries actually being executed on the
generic remote thin client are relatively few, of course.  
The applications being run on the central application servers
(Thanks for the correction, Hans -- your nomenclature
amendment suggestion is quite well-taken) through the X
protocol hooks, and the libraries issue disappears.

Then again, the PCI bios microcode in SCSI controllers and
video accellerators (which will work on Alpha, Sparc, PPC, and
x86) is either arch indifferent, or has an abstracting API and
a local tiny kernel running.  I would bet the latter.
> It seems to me that the right way to deal with this is have the client
> run ldconfig itself. This avoids all of the cross-platform issues:
> 	cp /sbin/ldconfig /opt/ltsp/i386/sbin/  # the i386 version of ldconfig!

This is not the present case, interestingly ...

[herrold www ltsp]$ ldd ./i386/lib/ld-linux.so.2 ; pwd
./i386/lib/ld-linux.so.2: ./i386/lib/ld-linux.so.2: version 
`GLIBC_PRIVATE' not found (required by /lib/i686/libc.so.6)
        statically linked
[herrold www ltsp]$

> 	cd /opt/ltsp/i386/etc/
> 	rm -f /opt/ltsp/i386/etc/ld.so.cache
> 	ln -s /tmp/ld.so.cache /opt/ltsp/i386/etc/ld.so.cache
> and then edit /opt/ltsp/i386/etc/rc.local, adding the following line right
> after the "Creating ramdisk on /tmp" section (about line 69):
> 	/sbin/ldconfig -C /tmp/ld.so.cache

The scripting looks fine -- the statement that a chrooted
ldconfig is sufficient is not clear (although in simple cases
it seems to be).  Thus my initial qualification that testing
must demonstrate such a change "(and must be) harmless"  "Is
it harmless?" remains an open question.

-- Russ Herrold

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