support for linux-dietlibc

[Ralf Wildenhues]

OK to apply the following two patches to HEAD and branch-2-0?
With these and the other patches I sent, I get for branch-2-0:

i686-pc-linux-dietlibc                 7 of 102 tests failed
CC="diet gcc" CXX=false F77=false      (13 tests were not run)

All failures are due to Fortran or C++ involvement (which dietlibc
does not support).

CC="diet-dyn gcc"                      5 of 115 tests failed

mdemo-exec and mdemo2-exec fail here when trying to execute the
mdemo{,2}_static binaries (i.e. trying to mix shared and static
stuff), plus the Fortran failures.  I wonder why tagdemo succeeds,
must be a lucky coincidence.

BTW: yes, I will be applying all my pending patches.  Later today.

Cheers,
Ralf


patch #1:
Detect static dietlibc.  One could think about trying to map `-static'
and `-shared' to `diet' and `diet-dyn' respectively, but I figured that
isn't worth the effort (I don't think you're supposed to mix these
anyway).

        * m4/libtool.m4 (_LT_LINKER_SHLIBS): Treat linux-dietlibc with
        the `diet' compiler wrapper (as opposed to the `diet-dyn'
        wrapper) as a static-only platform.

Index: m4/libtool.m4
===================================================================
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.125.2.14
diff -u -r1.125.2.14 libtool.m4
--- m4/libtool.m4       24 Nov 2004 17:24:30 -0000      1.125.2.14
+++ m4/libtool.m4       28 Nov 2004 09:48:27 -0000
@@ -3611,7 +3611,14 @@
       ;;
 
     linux*|tpf*)
-      if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null; 
then
+      tmp_diet=no
+      if test "$host_os" = linux-dietlibc; then
+       case "$cc_basename" in
+         diet\ *) tmp_diet=yes;;       # linux-dietlibc with static linking 
(!diet-dyn)
+       esac
+      fi
+      if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null && \
+         test "$tmp_diet" = no; then
         tmp_archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags 
${wl}-soname $wl$soname -o $lib'
        # Portland Group f77 and f90 compilers require an additonal -fpic
        if test "$CC" = "pgf77" -o "$CC" = "pgf90"; then




patch #2:
This one deserves a couple of comments.  dietlibc has some "features" to
be enabled at libc compile time, which are "interesting", to say the
least.  In its default configuration, it will use non-standards
compliant versions of strncpy and strncat (WANT_NON_COMPLIANT_STRNCAT)
which always null-terminate the destination string.  This is documented,
the reasoning goes along the lines of: mostly you'll want to add null at
the end of the string anyway, but if you forget, this will leave you
with one less buffer overflow.

Now I don't mean to discuss the merits or demerits of this "feature",
at least not on this list.  Issue for libltdl is merely that
ltdl.c's trim() uses strncpy in a way which conflicts with this
(cuts off the last character, `foo.a' becomes `foo.').  We don't
need strncpy here, however, memcpy is the right thing anyway.
The following patch fixes the issue for good.


        * libltdl/ltdl.c (trim): Use memcpy instead of strncpy here, to
        avoid problems with non-conforming strncpy.  This is safe here.

Index: libltdl/ltdl.c
===================================================================
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.217.2.3
diff -u -r1.217.2.3 ltdl.c
--- libltdl/ltdl.c      1 Nov 2004 14:05:02 -0000       1.217.2.3
+++ libltdl/ltdl.c      28 Nov 2004 09:48:20 -0000
@@ -903,7 +903,7 @@
       if (!tmp)
        return 1;
 
-      strncpy(tmp, &str[1], (end - str) - 1);
+      memcpy(tmp, &str[1], (end - str) - 1);
       tmp[len-3] = LT_EOS_CHAR;
       *dest = tmp;
     }