[syslinux] 5.00 c32 dependencies paths

[Ady]

> On Sat, Dec 8, 2012 at 6:44 AM, Ady <ady-sf at hotmail.com> wrote:
> > The following is a list gathered from Syslinux 5.00 using the "ldd"
> > command under Linux.
> >
> > (Note: use a monospaced font for clarity.)
> >
> > advdump.c32:      statically linked
> > cat.c32:          statically linked
> > chain.c32:        libutil_com.c32
> >                   libcom32.c32
> > cmd.c32:          libcom32.c32
> > config.c32:       libcom32.c32
> > cpuid.c32:        statically linked
> > cpuidtest.c32:    libcom32gpl.c32
> > disk.c32:         libcom32gpl.c32
> > dmitest.c32:      libcom32gpl.c32
> > elf.c32:          libcom32.c32
> > entrydump.c32:    statically linked
> > ethersel.c32:     libcom32.c32
> > fancyhello.c32:   libutil_com.c32
> > gfxboot.c32:      libcom32.c32
> > gpxecmd.c32:      libcom32.c32
> > hdt.c32:          libutil_com.c32
> >                   libcom32gpl.c32
> >                   libcom32.c32
> >                   libmenu.c32
> > hello.c32:        statically linked
> > hexdump.c32:      libcom32.c32
> > host.c32:         libcom32.c32
> > ifcpu.c32:        libutil_com.c32
> >                   libcom32gpl.c32
> >                   libcom32.c32
> > ifcpu64.c32:      libcom32.c32
> > ifmemdsk.c32:     libcom32.c32
> > ifplop.c32:       libcom32.c32
> > kbdmap.c32:       libcom32.c32
> > keytest.c32:      libutil_com.c32
> > kontron_wdt.c32:  libcom32.c32
> > ldlinux.c32:      statically linked
> > libcom32.c32:     statically linked
> > libcom32gpl.c32:  statically linked
> > liblua.c32:       statically linked
> > libmenu.c32:      libutil_com.c32
> >                   libcom32.c32
> > libutil_com.c32:  statically linked
> > linux.c32:        libcom32.c32
> > localboot.c32:    libcom32.c32
> > ls.c32:           statically linked
> > lua.c32:          liblua.c32
> >                   libcom32gpl.c32
> >                   libcom32.c32
> > mboot.c32:        libcom32.c32
> > meminfo.c32:      statically linked
> > menu.c32:         libutil_com.c32
> > pcitest.c32:      libcom32.c32
> > pmload.c32:       libcom32.c32
> > prdhcp.c32:       libutil_com.c32
> >                   libcom32.c32
> > pwd.c32:          statically linked
> > pxechn.c32:       libutil_com.c32
> >                   libcom32.c32
> > reboot.c32:       libcom32.c32
> > resolv.c32:       statically linked
> > rosh.c32:         libutil_com.c32
> >                   libcom32.c32
> > sanboot.c32:      libcom32.c32
> > sdi.c32:          libcom32.c32
> > serialinfo.c32:   statically linked
> > sysdump.c32:      libcom32.c32
> > vesainfo.c32:     statically linked
> > vesamenu.c32:     libutil_com.c32
> >                   libcom32.c32
> > vpdtest.c32:      libcom32gpl.c32
> > whichsys.c32:     libcom32.c32
> > zzjson.c32:       libcom32gpl.c32
> >
> >
> For me ldd shows (Syslinux 5.00):
> 
> /usr/lib/syslinux/bios/chain.c32:
> linux-gate.so.1 (0xf76f3000)
>  ../../com32/libutil/libutil_com.c32 => not found
> ../../com32/lib/libcom32.c32 => not found
> 
> Instead of just showing
> 
> /usr/lib/syslinux/bios/chain.c32:
> libutil_com.c32
> libcom32.c32
> 

The list I posted is not the exact result from ldd. I made the list 
based on it. (BTW, the posted list might be displayed with a 
different alignment format in different email clients. It may be 
clearer to see in the ML archive 
http://www.syslinux.org/archives/2012-December/018747.html .)

> ldd is showing similar info for other *.c32 files. Why is it linked to the
> build dir libcom32.c32 instead of $PWD/libcom32.c32 . Is something wrong in
> Makefiles? I am getting similar ldd info for Syslinux firmware branch efi64
> (v6.00-pre??) ? How do I fix this?
> 

The lib*.c32 files are dependencies in the sense that they are needed 
for other *.c32 files to work. We are not talking here about 
dependencies needed to build Syslinux in your system, nor to use the 
SYSLINUX/EXTLINUX (for example) installer(s).

The paths shown by the ldd command are the paths from the Syslinux 
build in your system (or to boot your system with Syslinux?). The 
list posted here just shows you which lib*.c32 files you need to copy 
to the destination device where you are going to install, for 
example, ldlinux.sys (for SYSLINUX/EXTLINUX) on it.

So, for example, if you installed ldlinux.sys in a UFD, the installer 
already copies ldlinux.sys and ldlinux.c32. If you want to use 
menu.c32 too, then the UFD should contain (for this example):

 ./boot/syslinux/ldlinux.sys
 ./boot/syslinux/ldlinux.c32
 ./boot/syslinux/menu.c32
 ./boot/syslinux/libutil_com.c32
 ./boot/syslinux/syslinux.cfg

because menu.c32 needs libutil_com.c32 (as listed by ldd). Without 
libutil_com.c32, menu.c32 fails. The "/boot/syslinux/" path is the 
"installation directory" just for this example. Since syslinux.cfg is 
also there, in the installation directory, that directory is going to 
be the "Current Working Directory" when you first boot that UFD.

When you boot with that UFD, if the syslinux.cfg file contains "UI 
menu.c32", then menu.c32 will be able to use libutil_com.c32 located 
in that same directory and should show you the boot menu.

This is a very simple example, just to give a general basic idea. In 
this simple case, the PATH directive is not needed, as the lib*.c32 
file(s) is (are) located in the same directory as the installation 
directory (where ldlinux.sys was installed), which is also where 
syslinux.cfg is located, which is the initial CWD when booting with 
this UFD.


> The new PATH directive is used in the cfg files to point to the
> > location of the lib*.c32 files, just in case that location is not the
> > "Current Working Directory".
> 
> 
> Any example of how to use PATH in syslinux.cfg ?
> 
> Regards.
> 
> Keshav

The general explanation about the new PATH directive can be found in 
the Syslinux 5.00 package in syslinux.txt. Look for the PATH 
directive and PATH rules.

I have found some problems in 5.00, which I reported to the ML 
already. If there are more difficulties, and the above basic example 
(and the syslinux.txt file) are not enough (and they might not be), 
just start a new email thread in the ML with the specific case. I'm 
not sure _I_ am going to know the answer, but maybe someone will.

HTH,
Ady.