Re: [Netatalk-admins] Problem in Cross Compiling Netatalk for a Linux Set Top Box (Dreambox)

[didier <dga...@ma...>]

Hi,
Le jeudi 30 novembre 2006 à 19:42 +0100, Fabio Fogliuzzi a écrit :
> Hi,
> I'm struggling to port netatalk on a linux set top box (a 'dreambox'
> sat receiver) and to get the afpd daemon working with the provided uam
> authentication plug-ins.
> I'm cross compiling the last distribution (2.0.3) on Mac OS X, where I
> ported (with minor modification to the automake/autoconf files) the
> CDK for the dreambox itself available at
> http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/.
> I compiled the sources with the following options to configure:
> 
> 
> --build=$(build) \
> --host=$(target) \
> --prefix= \
> --includedir=$(targetprefix)/include \
> --with-bdb=$(targetprefix) \
> --with-ssl-dir=$(targetprefix) \
> --without-shadow \
> --disable-static \
> --disable-cups && \
> 
> 
> Where 'host' is Mac OS X Tiger and  'target' is the set top box (based
> on linux kernel 2.6.9). The targetprefix variable points to the root
> directory where the software for the set top box get installed. In a
> second stage of the compilation the software rooted in
> 'targetprefix' (which will form the final software image installed in
> the flash memory of the set top box) is copied into another directory
> and stripped out of unused code and symbols by means of the pyton
> script 'mklibs.py'.
> Every thing seems to compile fine and also afpd starts without errors.
> The problem lies in the fact  that the only way I can connect to the
> server is as guest.
> 
> 
> The afpd.conf file is formed by the following single line of options:
> 
> 
> - -transall -nouservol -noslp -ipaddr 192.168.2.103
> -uampath /etc/netatalk/uams -uamlist
> uams_guest.so,uams_clrtxt.so,uams_dhx_passwd.so -nosavepassword
> -defaultvol /etc/netatalk/AppleVolumes.default
> -systemvol /etc/netatalk/AppleVolumes.system -unixcodepage UTF8
> -maccodepage MAC_ROMAN -signature user:dreambox.sig
> 
> 
No errors in /var/log/syslog? If it can't load uams_dx_passwd.so you
should have one.
> while in 'AppleVolumes.default' I defined a single volume to share.
> 
> 
> /hdd/movie "Movies" allow:root volcharset:UTF8 maccharset:MAC_ROMAN
> adouble:v2
> 
> 
> The server offers only the 'guest' and 'clear text' methods for
> authentication (no dhx method even if this method is selected in
> afpd.conf). Furthermore I can't connect  to the server as the root
> user (the only user on the set top box) providing the correct password
> in clear text. I think that may there be a problem at build time in
> linking the uam plugins with the correct libraries. In no way I'm an
> expert of the Autoconf-Automake-Libtool machinery, nevertheless I have
> noted that the configure script seems to check the presence of the
> needed libraries against the build system (Mac OS X) and this fact may
> lead to problems difficult to trace. To make be sure that the programs
> get linked against the correct libraries located in '$targetprfix/lib'
> I modified the configure script by applying the following patch:
Configure is a generated file, you may want to work with the CVS version
and configure.in.
> 
> 
> _ACEOF
> -  LIBS="-ldl $LIBS"
> +  LIBS="-L$(pwd)/../../root/cdkroot/lib -ldl $LIBS"
> fi
IMO it's a toolchain bug, the buildroot or whatever should redefine -l
path.
 
> @@ -8317,7 +8318,7 @@
> #define HAVE_LIBNSL 1
> _ACEOF
> -  LIBS="-lnsl $LIBS"
> +  LIBS="-L$(pwd)/../../root/cdkroot/lib -lnsl $LIBS"

> fi
Unrelated but this one is a bug in configure.in (fixed in CVS) for most
system libnsl is not needed. 


> 
> The lines of the patch related to the defines of
> 'DLSYM_PREPEND_UNDERSCORE'  and 'NEED_USCORE' actually doesn't change
> anything and I have left them here as a memo of my previous attempts
> to solve the problem. In these attempts I have forced the the
> definition of these macros.

> The lines of the patch related to the test of the variable
> 'netatalk_cv_SIZEOF_OFF_T' come from the observation that (when cross
> compiling) the support for large files doesn't get caught by the
> configure script (the previous check for this feature in configure is
> based on running a test on the build machine which fails) and, as a
> consequence of this fact the AFP3.X support gets disabled even if the
> target machine could support it. I constructed the patch of this line
> by looking at the file 'largefile-check.m4' in which are defined the
> related autoconf macros.
Yes it's a problem with cross compilers.

> Finally, the patch to the file 'Makefile.in' for libatalk is to force
> the build of a shared library and to globally consumes (library +
> binaries) less space than the one resulting from linking the binaries
> statically. I don't know if there is any negative consequence in
> building libatalk as a shared library and any suggestion on this fact
> will be appreciated.
There's none, in my understanding libatalk is not a shared library
because:
1) History :) 
2) the API isn't stable and we have enough pbs with libdb.
3) It's irrelevant for most servers, worse case in RAM you have 3
instances running: atalkd, papd and afpd ie maybe 150KB. Of course it's
not the same game when you have only 32MB and the root fs is a flash. 
> 
> 
> A final question:
> Is the libltdl library necessary on the target system to load the uam
> plugins at runtime?
Do you mean libdl.so? Likely for a glibc or uclib system.

As Uam dx needs other libraries libcrypt, libcrypto it could be the
culprit, it's not the case for guest and cleartext uam.

> Any Hint or Suggestion on the entire subject will be very appreciated.
> Thank you and best regards,
I don't understand the need for -L patch but often cross compilation is
a pain.

Didier