glibc 2.1.3 failure

Richard A.Gollub rgollub at uninet.com.br
Sun Jun 18 15:02:25 PDT 2000


Jens Luedicke wrote:

> hi there ...
>
> when I tried to build the glibc 2.1.3, I'm
> getting the error message:
>
> connectionc.c: In function `handle_request':
> connections.c:353: `SO_PEERCRED' undeclared (first use in this function)
> connections.c:353: (Each ....)
> connections.c:442: `SO_PEERCRED' undeclared (...)
>
> with friendly regards....
>
>         Jens Luedicke <jens at irs-net.com>

            I guess the following could be of your interest :)


> Subject:
>          LFS-2.3.2 - some experiences
>      Date:
>          Sat, 27 May 2000 20:40:28 +0100 (BST)
>     From:
>          John Phillips
>  Reply-To:
>          lfs-discuss at linuxfromscratch.org
>       To:
>          lfs-discuss at linuxfromscratch.org
>
> Hi everyone
>
> I managed to work through 2.3.2 to the point of booting the LFS system.
> For what it's worth here are some notes from the experience.  I haven't
> been on the list for more than a couple of days so apologies if I raise
> points that have long been solved.
>
> Starting point
> ==============
> * LFS 2.3.2 built from a Debian 2.1r2 (updated to r5) host.
>
> Problems arising from Debian 2.1 (and solutions)
> ================================================
> * The static linked bash "make install" gave an error because Debian's
> install-info is rather old.  I patched the bash doc/Makefile.in to
> comment out the call to install-info.  (I might better have upgraded
> but the patch was easier and made no difference).
>
> * If you are using X under Debian 2.1 and do the chroot from an xterm,
> you
> may need to do "export TERM=xterm" to avoid confusion over xterm-debian.
> This happens with "make menuconfig" while compiling the kernel.
>
> Other problems (and solutions)
> ==============================
> * I had to compile glibc with the latest kernel headers.  It would not
> compile with Debian's 2.0.38 headers since it needs "#define SO_PEERCRED
> 17" which is in 2.2.14 but not 2.0.38.
>
> To do this, I had to install the new kernel and make the links in
> $LFS/usr/include during the static build phase.  I then had to do:
>
>     make include/linux/version.h
>
> since glibc needs version.h, which this command makes.
>
> Then to make glibc I added "--with-headers=$LFS/usr/include".
>
> Finally, in the chrooted environment I had to configure the kernel at the
>
> beginning (using defaults for now) because some later compiles need the
> "autoconf.h" this generates.  To configure the kernel I did this:
>
>     yes "" | make config
>     make dep
>
> * For some reason I could not properly compile m4 in the chrooted
> environment following LFS-2.3.2 as it currently stands.  It would compile
>
> and link, but would not run (because the new glibc claimed it did not
> implement "sigstack").  All subsequent compiles needing m4 therefore
> failed (including the immediately following autoconf and automake).
>
> The solution (unexplained) was to make a static linked m4 at the end of
> the static build phase and then move the m4 re-compile in the chrooted
> section to somewhere after autoconf and automake (which need m4, and
> which m4 needs under some circumstances).  I actually put m4 after lilo
> and before make.
>
> * Permissions issues - (I assume umask 022 has been used for the
> install):
> I had to chmod 1777 for $LFS/tmp and $LFS/var/tmp.  Also for security
> there may need to be other changes such as 700 for $LFS/root, and 555
> for $LFS/proc (probably others I haven't found yet).
>
> * In the chrooted environment when a utility program is compiled and
> then moved, there is a risk that bash will "lose" it by remembering
> where it was.  The cure is "hash -r".
>
> * In the binutils install in the chrooted environment there are
> complaints
> about "file" which do not occur in the static build of binutils:
>
>    *** Warning: the command libtool uses to detect shared libraries,
>    *** /usr/bin/file, produces output that libtool cannot recognize.
>    *** The result is that libtool may fail to recognize shared libraries
>    *** as such.  This will affect the creation of libtool libraries that
>    *** depend on shared libraries, but programs linked with such libtool
>    *** libraries will work regardless of this problem.  Nevertheless, you
>
>    *** may want to report the problem to your system manager and/or to
>    *** bug-libtool at gnu.org
>
> I have not checked if these are significant.
>
> * There are quite a few other warnings in the log files but I think these
>
> are not significant.  Notable (because I don't understand them) are:
>
> binutils static:
>    libtool: install: warning: remember to run `libtool --finish /usr/lib'
>
> binutils under chroot:
>    ./libtool: ldconfig: command not found
>
> Neither seems to be a problem.
>
> * For setting up lilo to boot from LFS: The text was not clear to me.
> I had to to copy the new kernel to the active (bootable) partition
> (which was on the host system in my case), install the edited lilo.conf
> there and run lilo there (not in the chroot environment).
>
> * There were "char 45" errors in the net-tools install - I haven't
> checked then out.
>
> Minor typos in 2.3.2
> ====================
> * gcc install on host system - "--enable shared" -> "--enable-shared"
>
> * gzip static linked patch - the directory is wrong, the patch name
> is wrong and the patch should not be gzipped.
>
> * sed static linked patch - the patch should not be gzipped.
>
> * findutils chrooted patch - the directory is wrong and the patch should
> not be gzipped.
>
> * diffutils chrooted install (title) - "diffuitls"-> "diffutils"
>
> * file chrooted install - directory is file-3.26.orig/ (should there
> be a patch for the original?)
>
> * linux86 chrooted install - directories should be .../as or .../ld
>
> * psmisc chrooted install - directory is just psmisc/ (no version
> number).
>
> * /etc/init.d/syslogd script - "load daemon" -> "log daemon"
>
> * I decided to use the "production" netkit-base-0.16 rather than the
> development version (0.17).
>
> * add netkit-base-0.16 and net-tools-1.54 to the mandatory list in ch3.
>
> * /etc/init.d/ethnet file - use ${NAME}, not $(NAME) and there are two
> cases where "echo" should be "echo -n".  Change "NETMAKSK" to "NETMASK"
> Note also there are potential problems over setting the default route
> if you later set up PPP.
>
> Regards
>
> John
> --
> John Phillips           john at linux.demon.co.uk
> --
>

--
Mail archive: http://www.pcrdallas.com/mail-archives/lfs-discuss
IRC access: server: irc.linuxfromscratch.org port: 6667 channel: #LFS
Unsubscribe: email lfs-discuss-request at linuxfromscratch.org and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)



More information about the lfs-dev mailing list