bug#104: Redhad 8.0 build looks feasable, not easy

Attempt to compile on Redhat 8.0 with gcc 3.2
Attempt made to address LNX-BBC bugs 270, 61, 63, 64, 104

   http://bugs.lnx-bbc.org/bugs/db/61/61.html
   http://bugs.lnx-bbc.org/bugs/db/63/63.html
   http://bugs.lnx-bbc.org/bugs/db/64/64.html
   http://bugs.lnx-bbc.org/bugs/db/104/104.html
   http://bugs.lnx-bbc.org/bugs/db/270/270.html

Needs review!

This is about a weeks worth of work.
First 3 steps journal working with glibc 2.2.5 which I punted on
Steps 4 and on chronlog working with lnx-bbc and glibc 2.3.1

1) gcc 3.2 now has a reserved word "__thread"
   glibc 2.2.5 uses this as a variable name in function prototypes.
   Fix is to delete or rename to something like "thread" in a few header files
   Refer to
       http://mail.gnu.org/archive/html/commit-hurd/2002-11/msg00013.html

   Use this approach to edit files
       ... /glibc-2.2.5/linuxthreads/sysdeps/pthread/pthread.h
       ... /glibc-2.2.5/linuxthreads/sysdeps/unix/sysv/linux/bits/sigthread.h
       ... /glibc-2.2.5/linuxthreads/internals.h

2) Compiler breaks on 
   gar/devel/glibc/work/main.d/glibc-2.2.5/sysdeps/unix/sysv/linux/errlist.c

   Fix from
       http://gcc.gnu.org/ml/gcc-bugs/2002-08/msg00001.html
       http://gcc.gnu.org/ml/gcc/2002-07/msg01401.html`
   Basically, delete the weak aliases and make __old_sys_errlist a strong alias.

3) While linking rpcinfo you get
       ../elf/ld-linux.so.2: version `GLIBC_PRIVATE' not found
       (required by /lib/libc.so.6)

   Its tripping up on the ABI, Application Binary Interface.  There is some
   good reading material on this stuff.  In a nutshell, ABI is how you can
   get rid of shipping multiple versions of a lib like libcurl.so,
   libcurl.so.2, libcurl.so.2.0.2

      http://abicheck.sourceforge.net/abi-drafts/glibc-abi.html
      http://abicheck.sourceforge.net/intro.html
      https://qa.mandrakesoft.com/show_bug.cgi?id=744
      http://bugs.lnx-bbc.org/bugs/db/10/104.html
      http://sources.redhat.com/glibc/glibc-faq.html  <-- sect 3.18

   My interpretation (which may be wrong) as to why this trips is because 
   my host OS's libc has a dependency on symbols in the ld-linux.so.2 dynamic
   loader.

      $ ldd /lib/libc-2.2.93.so
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

   When you run the glibc v2.2.5 version elf/ld-linux.so.2 (which is kind 
   of odd thing by the glibc build), it loads the host OS's libc which as 
   you see above wants to load symbols in ld-linux.so.2.  Since ld-linux.so.2
   is already loaded, it doesn't grab the newer symbols in /lib/ld-linux.so.2.
   Then glibc says, what the hell is this, I can't find the GLIBC_PRIVATE
   versions of symbols that I need and bails...

   Not sure if this is a problem or not, but it looks like ldd squawks about
   minor version numbers.

      $# v2.5.5 lnx-bbc version...
      $ nm --dynamic libc.so.6 | grep GLIB
         00000000 A GLIBC_2.0
         00000000 A GLIBC_2.1
         00000000 A GLIBC_2.1.1
         00000000 A GLIBC_2.1.2
         00000000 A GLIBC_2.1.3
         00000000 A GLIBC_2.2
         00000000 A GLIBC_2.2.1
         00000000 A GLIBC_2.2.2
         00000000 A GLIBC_2.2.3
         00000000 A GLIBC_2.2.4
         00000000 A GLIBC_2.2.5
      $ldd libc.so.6
         ./libc.so.6: //lib/ld-linux.so.2: version `GLIBC_2.1.1' not found
            (required by ./libc.so.6)
         ./libc.so.6: //lib/ld-linux.so.2: version `GLIBC_2.2.3' not found
            (required by ./libc.so.6)
         ./libc.so.6: //lib/ld-linux.so.2: version `GLIBC_2.2' not found
            (required by ./libc.so.6)
         //lib/ld-linux.so.2 => //lib/ld-linux.so.2 (0x40000000)
      $ nm --dynamic /lib/ld-linux.so.2 | grep GLIB
         00000000 A GLIBC_2.0
         00000000 A GLIBC_2.1
         00000000 A GLIBC_2.3
         00000000 A GLIBC_PRIVATE

   See how v2.5.5 libc.so.6 wants ld-linux symbols with version GLIBC_2.1.1,
   GLIBC_2.2.3, and GLIBC_2.2 and the Redhat 8.0 host OS ld-linux only has
   versions labled GLIBC_2.0, GLIBC_2.1, GLIBC_2.3, and GLIBC_PRIVATE.
   Probably only an issue if ld-linux squawks, but since the error message
   was exactly the same...

   There is probably a good history posted on gnu.org or redhat but I
   couldn't find it.  I hacked at breaking the dynamic link between libc
   and ld.linux but got pretty frustrated.  The chroot is a much cleaner
   way to deal with this obviously.  http://www.lnx-bbc.org/chroot.html.
   A chroot of lnx-bbc might be an interesting idea...  If glibc is 
   identical on both the source code and chroot doing the compile, things 
   should never cause version ABI problems...

4) Following the lines of thought that getting the host OS's glibc and
   lnx-bbc's code close, I updated gar/devel/glibc/checksums to look like
   this


   e4c3eb8343b5df346ceaaec23459f1dc  download/glibc-2.2.5.tar.gz
   c766a79a51668d7fa33f175a249655b4  download/glibc-linuxthreads-2.2.5.tar.gz
   3b9ba238eaa92a61e91c234cd28ed5bb  download/gar-base.diff
   e8e7ffcb86f921c5b597008bf6f891bd  download/glibc-2.3.1.tar.gz
   73a5b953b89c8ebeb534bf59822dde07  download/glibc-linuxthreads-2.3.1.tar.gz


   Then I edited gar/devel/glibc/Makefile to "GARVERSION = 2.3.1" and
   commented out the PATCHFILES line.  Nick Moffitt deleted the LD_PRELOAD
   out of gar/gar.conf.mk and lnx-bbc starts compiling through glibc...

5) Compile fails on flex.  Between the version of glibc that is running on 
   RH 8.0 and glibc 2.3.1, this ABI change was made in glibc...

      http://sigunix.cwru.edu/pub/gentoo/rsync/sys-libs/glibc/files/2.3.1/glibc-2.3.1-stack_end-compat.patch

   You back this out of gar/devel/glibc/work/main.d/glibc-2.3.1/elf/Versions
   and lnx-bbc compiles through flex.

6) Compile fails on pkg-config.  This little package includes a small glibc
   in it.  Thought a nice way to fix this would be to just use the glibc
   that comes with the operating system so I re-wrote "configure.in".
   Delete gar/devel/pkg-config/work/main.d/pkgconfig-0.14.0/configure.in
   and create a "configure.ac in it's place.  Here it is...

### begin file
# Modified by Lee Thompson Feb 27, 2003 to allow builder to select
# the host OS's implementation of glibc instead of the one provided with pkgconfig.
# Also "freshened" some syntax
AC_INIT(pkgconfig, 0.14.0, [email protected])
AM_INIT_AUTOMAKE
AM_MAINTAINER_MODE

AM_CONFIG_HEADER([config.h])
AC_CONFIG_FILES([Makefile])

AC_ARG_ENABLE([local-glib],
  AC_HELP_STRING([--enable-local-glib],
    [Use OS's  glibc instead of v1.2.8 which comes with pkgconfig]),
  [case "${enableval}" in
    yes) local_glib=yes ;;
    no)  local_glib=no ;;
    *) AC_MSG_ERROR(bad value ${enableval} for --enable-local-glibc) ;;
  esac], [local_glib=no])

AC_MSG_CHECKING([for Win32])
case "$host" in
  *-*-mingw*)
    native_win32=yes
    local_glib=yes
  ;;
  *)
    native_win32=no
  ;;
esac
AC_MSG_RESULT([$native_win32])
AC_MSG_CHECKING([for local glibc use])
AC_MSG_RESULT([$local_glib])

AM_CONDITIONAL(USE_INSTALLED_GLIB, test x$local_glib = xyes)

if test x$local_glib = xyes; then
  # On Win32, use the normal installed GLib.  Yes, this is a circular
  # dependency. But then, only experienced hackers that presumably can
  # work around that will be building pkg-config and GLib on Win32
  # anyway (especially using the auto*/configure/libtool
  # mechanism). Others use prebuilt versions.
  #
  # These are correct for GLib 2.x
  GLIB_CFLAGS="-I$includedir/glib-2.0 -I$libdir/glib-2.0/include"
  if test x$native_win32 = xyes; then
    GLIB_LIBS="-L$libdir -lglib-2.0 -liconv -lintl"
  else
    GLIB_LIBS="-L$libdir -lglib-2.0"
  fi

  AC_SUBST(GLIB_LIBS)
  AC_SUBST(GLIB_CFLAGS)

  AC_CONFIG_AUX_DIR(.)

  AC_DEFINE(USE_INSTALLED_GLIB, 1, [We are using the installed GLib])
else
  AC_CONFIG_SUBDIRS(glib-1.2.8)
fi

AM_PROG_LIBTOOL

AC_PROG_CC

AC_FUNC_ALLOCA

AC_CHECK_FUNCS(setresuid setreuid,break)
AC_CHECK_HEADERS([dirent.h unistd.h sys/wait.h])

AC_OUTPUT
### endfile

   Once configure.ac is created, delete the files configure.in, config.h,
   config.h.in, stamp*, and aclocal.m4.  Run the utilities aclocal,
   autoheader, autoconf, and automake.

   Then, edit gar/devel/pkg-config/Makefile and add "--enable-local-glib"
   to the CONFIGURE_ARGS.  No you will compile through pkgconfig and 
   the linux kernel which is encouraging.

7) Compile fails on curses complaining of an antiquated header.  This
   is not surprising considering its as old as, well, its as old as curses...
   Upgrading to v5.3 ncurses will probably get this but I wanted to get
   some feadback on this.



Lee Thompson
[email protected]