Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I cannot compile cryptsetup in my BLFS 8 system. Automake is the point of failure.
my build script, up to where the failure occurs
Code:
#!/bin/bash
#
set -e
ARCH=x86_64
BUILD="1"
NUTSO=5be69e92ce3821e88d65ffc95e81544558426b94
UNZIP_DIR=cryptsetup-master-$NUTSO
IN_NAME=cryptsetup-master-$NUTSO.tar.bz2
OUT_NAME=cryptsetup-2017.06.28-$ARCH-$BUILD\_lfs.txz
# it would be *bad* if in and out names were the same
# set up
WYAN=`pwd`
mkdir build_it pack_it
PACKHERE=$WYAN/pack_it
cd build_it
tar -xpf ../$IN_NAME
cd "$UNZIP_DIR"
echo "pwd"
pwd
# pre configure, lots of forcing things
echo "begin libtoolize"
libtoolize --force
echo "begin aclocal"
aclocal
echo "begin autoheader"
autoheader
echo "begin kludge for Makefile.am"
echo "AUTOMAKE_OPTIONS = subdir-objects" >> Makefile.am
echo "AM_INIT_AUTOMAKE = subdir-objects" >> Makefile.am
echo "begin automake"
AUTOMAKE_OPTIONS="subdir-objects" AM_INIT_AUTOMAKE="subdir-objects" automake \
--force-missing --add-missing --copy # --subdir-objects
# it always fails at automake
How I run the script
Code:
./lfs_build_cryptsetup.sh > errors.txt 2>&1
The output
Quote:
pwd
/home/bob/compile/cryptsetup/build_it/cryptsetup-master-5be69e92ce3821e88d65ffc95e81544558426b94
begin libtoolize
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: linking file 'm4/libtool.m4'
libtoolize: linking file 'm4/ltoptions.m4'
libtoolize: linking file 'm4/ltsugar.m4'
libtoolize: linking file 'm4/ltversion.m4'
libtoolize: linking file 'm4/lt~obsolete.m4'
begin aclocal
begin autoheader
begin kludge for Makefile.am
begin automake
configure.ac:27: installing './compile'
configure.ac:26: installing './config.guess'
configure.ac:67: error: required file './config.rpath' not found
configure.ac:26: installing './config.sub'
configure.ac:19: installing './install-sh'
configure.ac:19: installing './missing'
lib/Makefile.am: installing './depcomp'
src/Makefile.am:12: warning: source file '$(top_builddir)/lib/utils_crypt.c' is in a subdirectory,
src/Makefile.am:12: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
src/Makefile.am:12: warning: source file '$(top_builddir)/lib/utils_loop.c' is in a subdirectory,
src/Makefile.am:12: but option 'subdir-objects' is disabled
src/Makefile.am:105: warning: source file '$(top_builddir)/lib/utils_crypt.c' is in a subdirectory,
src/Makefile.am:105: but option 'subdir-objects' is disabled
src/Makefile.am:75: warning: source file '$(top_builddir)/lib/utils_crypt.c' is in a subdirectory,
src/Makefile.am:75: but option 'subdir-objects' is disabled
src/Makefile.am:75: warning: source file '$(top_builddir)/lib/utils_loop.c' is in a subdirectory,
src/Makefile.am:75: but option 'subdir-objects' is disabled
src/Makefile.am:45: warning: source file '$(top_builddir)/lib/utils_crypt.c' is in a subdirectory,
src/Makefile.am:45: but option 'subdir-objects' is disabled
src/Makefile.am:45: warning: source file '$(top_builddir)/lib/utils_loop.c' is in a subdirectory,
src/Makefile.am:45: but option 'subdir-objects' is disabled
tests/Makefile.am:50: warning: source file '$(top_srcdir)/lib/utils_loop.c' is in a subdirectory,
tests/Makefile.am:50: but option 'subdir-objects' is disabled
I have googled the "subdir-objects" error messages. Several ideas that worked for other people are incorporated in the my build script. Naturally, they don't work.
Has anyone else actually gotten cryptsetup to build in a BLFS8 system?
#!/bin/bash
#
set -e
ARCH=x86_64
BUILD="1"
NUTSO=5be69e92ce3821e88d65ffc95e81544558426b94
UNZIP_DIR=cryptsetup-master-$NUTSO
IN_NAME=cryptsetup-master-$NUTSO.tar.bz2
OUT_NAME=cryptsetup-2017.06.28-$ARCH-$BUILD\_lfs.txz
# it would be *bad* if in and out names were the same
# set up
WYAN=`pwd`
mkdir build_it pack_it
PACKHERE=$WYAN/pack_it
cd build_it
tar -xpf ../$IN_NAME
cd "$UNZIP_DIR"
echo "pwd"
pwd
# pre configure, lots of forcing things
echo "begin libtoolize"
libtoolize --force
echo "begin aclocal"
aclocal
echo "begin autoheader"
autoheader
echo "begin kludge for Makefile.am"
echo "AUTOMAKE_OPTIONS = subdir-objects" >> Makefile.am
echo "AM_INIT_AUTOMAKE = subdir-objects" >> Makefile.am
echo "begin automake"
AUTOMAKE_OPTIONS="subdir-objects" AM_INIT_AUTOMAKE="subdir-objects" automake \
--force-missing --add-missing --copy # --subdir-objects
# it always fails at automake
For future reference, "autoreconf --force --install", short "autoreconf -fi" would've done the same and probably succeeded. Many packages also come with autogen.sh script, which generate autotools files in proper manner.
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,150
Rep:
Just a couple of things about the syntax of the script to make it more readable, first the "OUT_NAME=cryptsetup-2017.06.28-$ARCH-$BUILD\_lfs.txz"
Instead of escaping the underscore, which is a legal character for a bash variable the usual way to use this would be the use of '{}' which are used when the var name may be ambiguous eg "${ARCH}-${BUILD}_lfs.txz"
Second as you are specifying bash in the shebang you really should use $(command) instead of `command` for command substitution its, POSIX correct and is more readable with less chance of confusion with "'".
Also as Krejzi said use the autogen.sh script if available.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
Quote:
Originally Posted by Krejzi
Many packages also come with autogen.sh script, which generate autotools files in proper manner.
I wish that were the case, but many I've seen... Mainly where the developers are using a git repo and appear to not really be familiar with building packages for release, don't setup their autogen.sh correctly. I'll often find packages that, when building "release" will leave -g or -ggdb CFLAGS in the all: makefile. (Nettle) Some, won't invoke --copy when running autoheader, autoconf, etc. and leave the symlinks to their local system for those files (recent polkit), or docize preps missing (Freedesktop). Finally, the worst is packages with unresolved references to gobject introspection. Those will bomb the autoconf if you don't have glib and gi installed, even if the package allows --disable-introspection to be used. I suspect its because autotools can't deal with it without the reference metadata in the glib/introspection packages.
YMMV with autotools. CMake, on the other hand, I have yet to see complain that some parts of itself are missing or incomplete. Dependencies yes, but not anything like "oh hey, I'd like to run, but my bootstrap is missing."
Because Cryptsetup is not in the BLFS 8 instructions. Oh, you meant the unstable version! I normally don't look at the unstable version of the book, because I try for, erm, stability.
In this case, using the version of the CryptUtils package linked from that version of the BLFS book actually worked. It didn't have a missing ./configure file. Thank you very much.
Last edited by jr_bob_dobbs; 07-02-2017 at 04:54 PM.
Just a couple of things about the syntax of the script to make it more readable, first the "OUT_NAME=cryptsetup-2017.06.28-$ARCH-$BUILD\_lfs.txz"
Instead of escaping the underscore, which is a legal character for a bash variable
You know it is a legal character, and I know it is a legal character, but try to convince bash of that. Sections of the OUT_NAME just disapear if I don't put that "\_" in. There's something wacky going on there and I haven't the smarts nor the patience to go look at bash's source code.
Quote:
would be the use of '{}' which are used when the var name may be ambiguous eg "${ARCH}-${BUILD}_lfs.txz"
If I use {} around every variable, things would look a right mess, even more like spaghetti code than I see in <redacted>.
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,150
Rep:
you're wrong using {} makes tdhe code clearer to read as it makes it clear WHAT is a variable name and what isn't i have been scrippting with bash for years and have NEVER had to escape part of the name just used {} which is the correct way of doing it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.