Apologies for the double send Greg, I did reply instead of reply all. Thanks so much for the help Greg. Yeah, I didn't include the prefix when running configure, because the docs said it would default to the location I wanted it in anyways. I found that Ubuntu didn't have /usr/local added for the ldconfig. I recall it being that way several years ago, but it seems like maybe something changed. There was one issue though, a .scm file was installed/copied into /usr/local/lib, which ldconfig didn't like. The file was libguile-3.0.so.1.7.1-gdb.scm. This is the only installation for guile on this machine, as it's close to a new install, and when I delete it and run `sudo make install`, it puts it back. So there were two parts to the fix
1. Add "/usr/local/lib" to a new file in /etc/ld.so.conf.d/usr-local.conf. After doing this, running `ldconfig` resulted in this error /sbin/ldconfig.real: /usr/local/lib/libguile-3.0.so.1.7.1-gdb.scm is not an ELF file - it has the wrong magic bytes at the start. 2. Remove libguile-3.0.so.1.7.1-gdb.scm from /usr/local/lib I'm not sure if this is Ubuntu special sauce, or if this file is ending up there incorrectly, but it really wants everything in all ld folders to be only ELF files. After doing these two steps after `sudo make install`, guile seems to be working now. Below is the output of ldd and objdump for context ldd: zymus@abyss:~/src/guile-3.0.11$ ldd /usr/local/bin/guile linux-vdso.so.1 (0x00007ffc61064000) libguile-3.0.so.1 => /usr/local/lib/libguile-3.0.so.1 (0x00007aecfc4e7000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007aecfc200000) libgc.so.1 => /lib/x86_64-linux-gnu/libgc.so.1 (0x00007aecfc472000) libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007aecfc465000) libunistring.so.5 => /usr/local/lib/libunistring.so.5 (0x00007aecfc017000) libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007aecfbf95000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007aecfc429000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007aecfbeae000) /lib64/ld-linux-x86-64.so.2 (0x00007aecfc64a000) objdump: zymus@abyss:~/src/guile-3.0.11$ objdump -x /usr/local/bin/guile | egrep NEEDED\|RPATH NEEDED libguile-3.0.so.1 NEEDED libc.so.6 On Wed, May 13, 2026 at 4:45 AM Greg Troxel <[email protected]> wrote: > Zyle Moore <[email protected]> writes: > > > I'm trying to build and install Guile from source on an Ubuntu machine. I > > followed the instructions from > > > https://www.gnu.org/software/guile/manual/html_node/Obtaining-and-Installing-Guile.html > > with the only difference being running `sudo make install` instead of > `make > > install`. Each stage finishes, and at the end, I see the libraries in > > /usr/local/lib, and the executable in /usr/local/bin. But when I run > `make > > installcheck`, it looks like it can't find the header. When running > `guile` > > it also errors out with the same message. The full output from `make > > installcheck` is below, followed by the `guile` output, followed by the > > /usr/local file listing. > > The standard approach in ELF is to annotate a binary with RPATH that > lists the directories where shared libraries (that are "NEEDED") can be > located. My understanding is that some GNU/Linux systems object to > that and do something different. I mention this because it sounds like > it may be related. > > Another point is that software is generally built with a prefix and > installed to that same prefix. Sometimes people think they should be > able to build to one prefix and put it someplace else. That in general > does not work. > > I'm assuming that you ran ./configure without prefix, and did not set > any kind of prefix or DESTDIR when installing. > > I would suggest: > > run "ldd /usr/local/bin/guile" > > run "objdump -x /usr/local/bin/guile" (to a file and then look at it; > it's huge). Look specifically for NEEDED and RPATH > > Determine somehow, if Ubuntu objects to RPATH and does something > else, and if so, understand it. Perhaps /etc/ld.so.conf has to list > directories, which are treated as being in RPATH for every binary > (and if so, I don't know how that works with multiple installs of > different versions). > > Check if some other guile is installed. Consider removing it, > removing all guile bits in /usr/local, removing your entire build > directory, and building again. It is a fairly frequent problem for > builds to refer to different versions in various places, as the > search mechanisms tend to be lists of directories. > > > On my NetBSD 10 amd64 system, which uses pkgsrc and can install multiple > versions of guile at once (I have 2.0, 2.2. and 3.0), it works. NetBSD > and pkgsrc follow the traditional ELF plan of RPATH. > > $ /usr/pkg/guile/3.0/bin/guile --version > guile (GNU Guile) 3.0.11 > [license info snipped] > > $ ldd /usr/pkg/guile/3.0/bin/guile > /usr/pkg/guile/3.0/bin/guile: > -lguile-3.0.1 => /usr/pkg/guile/3.0/lib/libguile-3.0.so.1 > -lgc.1 => /usr/pkg/lib/libgc.so.1 > -lpthread.1 => /usr/lib/libpthread.so.1 > -lc.12 => /usr/lib/libc.so.12 > -lrt.1 => /usr/lib/librt.so.1 > -lffi.8 => /usr/pkg/lib/libffi.so.8 > -lunistring.5 => /usr/pkg/lib/libunistring.so.5 > -lgmp.10 => /usr/pkg/lib/libgmp.so.10 > -lcrypt.1 => /usr/lib/libcrypt.so.1 > -lm.0 => /usr/lib/libm.so.0 > > $ objdump -x /usr/pkg/guile/3.0/bin/guile |egrep NEEDED\|RPATH > NEEDED libguile-3.0.so.1 > NEEDED libgc.so.1 > NEEDED libpthread.so.1 > NEEDED librt.so.1 > NEEDED libffi.so.8 > NEEDED libunistring.so.5 > NEEDED libgmp.so.10 > NEEDED libcrypt.so.1 > NEEDED libm.so.0 > NEEDED libc.so.12 > RPATH /usr/pkg/guile/3.0/lib:/usr/pkg/lib >
