On Sun, Mar 18, 2018 at 10:28:13PM +0000, Clyde McKenney wrote:
> /mnt/lfs/tools/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> warning: libutil.so.1, needed by
> /mnt/lfs/sources/expect5.45.4/libexpect5.45.4.so, not found (try using -rpath
> or -rpath-link)
> /mnt/lfs/tools/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> warning: libpthread.so.0, needed by /tools/lib/libtcl8.6.so, not found (try
> using -rpath or -rpath-link)
>
> These are the errors which *are* fatal. I'll comment on the first
> two, but basically after one error for a missing library all bets
> are off.
>
> The first missing file is /tools/lib/libutil.so.1 - that should have
> been installed by glibc.
>
> The second is /tools/lib/libpthread.so.0 which should also have been
> installed by glibc.
>
>
> /tools/lib/libtcl8.6.so: undefined reference to
> `pthread_setspecific@GLIBC_2.2.5'
>
> OK, I'll comment on this one too, since it is almost certainly
> defined in libpthread.so.
>
> Do you have those two files ? The version .so.X* should be symbolic
> links to .so files : if you have them, does file report they are
> broken (i.e. pointing to something which does not exist) ?
>
> Ken,
>
>
>
> I have those two files, they exist in /tools/lib, during the expect5.45.4
> make, as symlinks to existing lib*-2.27.so files, even though gcc complains
> that they're not there. (?)
>
I'm glad they are there, but now I'm puzzled about why gcc is saying
they are not there. That usually means they depend on soemthing
else which is missing (and that wouldbe very odd in chapter 5).
I was going to say that I normally discard /tools after booting, but
on the machine I'm currently using I saved it as /tools.orig.
Running ldd on them only shows (for me)
linux-vdso, libc.so.6, and ld-linux.
and if you don't have those you will get nowhere.
> Could the fact that these errors reference "GLIBC2.2.5", when the book and I
> are using glibc 2.27, be a hint?
Maybe, but I'm out of practice on determining what these versioned
symbols mean. Running strings on my preserved libtcl8.6.so from
/tools I can see pthread_setspecific@GLIBC_2.2.5 although it does
not appear to be in libpthread itself (but the @ might mean the
version is determined by other means).
> FWIW, my aging memory may be wrong, but I believe I successfully compiled all
> of Chapter 5 and 6 during an earlier run on this machine (but since gave up
> the partition during a rebuild done for other reasons), so I'll admit it's
> not a squeaky clean OOB Mint install.
>
> But then FWIW, I just successfully compiled expect5.45.4 inside a fresh
> VirtualBox using Manjaro, an Arch distro. So blame Mint...
>
If you got through chapter 6 on a previous build then I'm baffled
about what might have changed, unless you ran upgrades on mint.
> Oh well, I'll probably reboot to bare metal, or just start living inside
> VirtualBox, but nailing this issue would be educational.
>
> My version-check.sh reports:
> bash, version 4.3.48(1)-release
> /bin/sh -> /bin/bash
> Binutils: (GNU Binutils for Ubuntu) 2.26.1
> bison (GNU Bison) 3.0.4
> /usr/bin/yacc -> /usr/bin/bison.yacc
> bzip2, Version 1.0.6, 6-Sept-2010.
> Coreutils: 8.25
> diff (GNU diffutils) 3.3
> find (GNU findutils) 4.7.0-git
> GNU Awk 4.1.3, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.0)
> /usr/bin/awk -> /usr/bin/gawk
> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
> (Ubuntu GLIBC 2.23-0ubuntu10) 2.23
> grep (GNU grep) 2.25
> gzip 1.6
> Linux version 4.13.0-37-generic (buildd@lcy01-amd64-012) (gcc version 5.4.0
> 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)) #42~16.04.1-Ubuntu SMP Wed Mar 7
> 16:03:28 UTC 2018
> m4 (GNU M4) 1.4.17
> GNU Make 4.1
> GNU patch 2.7.5
> Perl version='5.22.1';
> sed (GNU sed) 4.2.2
> tar (GNU tar) 1.28
> texi2any (GNU texinfo) 6.1
> xz (XZ Utils) 5.1.0alpha
> g++ compilation OK
>
I don't recall seeing the GNU MPFR and GNU MP details for gawk
before, but that all looks ok.
>
>
> User lfs has the following environment set:
>
> BASH=/bin/bash
> BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
Wow, what a lot (I don't have that, or many of the other variables,
but I don't see anything that looks odd.
> BASH_ALIASES=()
> BASH_ARGC=()
> BASH_ARGV=()
> BASH_CMDS=()
> BASH_LINENO=()
> BASH_SOURCE=()
> BASH_VERSINFO=([0]="4" [1]="3" [2]="48" [3]="1" [4]="release"
> [5]="x86_64-pc-linux-gnu")
> BASH_VERSION='4.3.48(1)-release'
> COLUMNS=102
> DIRSTACK=()
> EUID=1001
> GROUPS=()
> HISTFILE=/home/lfs/.bash_history
> HISTFILESIZE=500
> HISTSIZE=500
> HOME=/home/lfs
> HOSTNAME=Dell-Mint
> HOSTTYPE=x86_64
> IFS=$' \t\n'
> LC_ALL=POSIX
> LFS=/mnt/lfs
> LFS_TGT=x86_64-lfs-linux-gnu
> LINES=60
> MACHTYPE=x86_64-pc-linux-gnu
> MAILCHECK=60
> MAKEFLAGS=-j1
> OLDPWD=/mnt/lfs/sources
> OPTERR=1
> OPTIND=1
> OSTYPE=linux-gnu
> PATH=/tools/bin:/bin:/usr/bin
> PIPESTATUS=([0]="0")
> PPID=4290
> PS1='${debian_chroot:+($debian_chroot)}\u@\h \w \$ '
> PS2='> '
> PS4='+ '
> PWD=/mnt/lfs/sources/expect5.45.4
> SHELL=/bin/bash
> SHELLOPTS=braceexpand:emacs:histexpand:history:interactive-comments:monitor
> SHLVL=1
> TERM=xterm-256color
> UID=1001
>
>
> Sorry for html email, Thanks for advice from all!
>
> -- Clyde
>
At this point, I'm none the wiser. Maybe somebody else will
recognize the problem. If not, maybe it will disappear on a fresh
build - but those sort of problems are exceptionally annoying and it
would be nice to understand what went wrong.
ĸen
--
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
- Unseen Academicals
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
