Make one specific target in Makefile tree - makefile

I'm building Syslinux and there is one specific directory that I would like a different CC for. Instead of patching the Makefile, I can't I just invoke make with special arguments for that file? I haven't figured out how to do this.
When I just run make normally, this last lines are:
make -r -C lzo SRC="/syslinux-6.03/lzo" OBJ="/syslinux-6.03/bios/lzo" \
-f /syslinux-6.03/lzo/Makefile all
make[3]: Entering directory '/syslinux-6.03/bios/lzo'
gcc -o prepcore prepcore.o lzo.a
But if I cd into bios/lzo and run make prepcore, it doesn't work, probably because it needs some environment from the parent directory Makefiles. The error message is:
make: Entering directory '/syslinux-6.03/lzo'
/syslinux-6.03/lzo/Makefile:14: /build.mk: No such file or directory
make: *** No rule to make target '/build.mk'. Stop.
make: Leaving directory '/syslinux-6.03/lzo'
So my question is, what is the correct way of telling make "for the current directory tree, find a target for <file> and make it"?

Here is how to do this with remake. You run "remake" and set a breakpoint on the target you want to change. Then use the remake's "write" command to write the commands it would run to a shell script. Then you can edit that shell script to adjust the commands it runs for changes you want. The shell script will have a change directory command in it that you probably want to comment out.
Here is an example:
$ rm job.o
$ remake -X job.o
GNU Make 4.1+dbg0.91
Built for x86_64-unknown-linux-gnu
...
-> (/src/external-vcs/github/remake/Makefile:621)
Makefile: Makefile.in config.status
remake<0> s
... # Step until job.o
remake<9> s
Must remake target 'job.o'.
Makefile:781: update target 'job.o' due to: job.c /usr/include/stdc-predef.h ...
##>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
depbase=`echo job.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" -DINCLUDEDIR=\"/usr/local/include\" -DHAVE_CONFIG_H -I. -DMAKE_MAINTAINER_MODE -pthread -I/usr/include/guile/2.0 -Wall -Wextra -Wdeclaration-after-statement -Wshadow -Wpointer-arith -Wbad-function-cast -g -O2 -MT job.o -MD -MP -MF $depbase.Tpo -c -o job.o job.c &&\
mv -f $depbase.Tpo $depbase.Po
##<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
++ (/src/external-vcs/github/remake/.deps/job.Po:1)
job.o
remake<10> w
File "/tmp/job.o.sh" written.
remake<11>
Now look at the file it wrote:
#!/bin/bash
#/tmp/github/remake/.deps/job.Po:1
#cd /tmp/remake
depbase=`echo job.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" -DINCLUDEDIR=\"/usr/local/include\" -DHAVE_CONFIG_H -I. -DMAKE_MAINTAINER_MODE -pthread -I/usr/include/guile/2.0 -Wall -Wextra -Wdeclaration-after-statement -Wshadow -Wpointer-arith -Wbad-function-cast -g -O2 -MT job.o -MD -MP -MF $depbase.Tpo -c -o job.o job.c &&\
mv -f $depbase.Tpo $depbase.Po

Related

Make error: The system cannot find the path specified

I'm getting a Make error when I run the mingw32-make command:
PS D:\> mingw32-make
cd src; mingw32-make
The system cannot find the path specified.
mingw32-make: *** [Makefile:4: all] Error 1
But when I list the actual command listed in the Makefile i.e. cd src; mingw32-make, the build is finished successfully.
PS D:\> cd src; mingw32-make
g++ -std=c++17 -Wall -Wextra -Wpedantic -Wformat -Wchkp -I../include -c account.cpp
g++ -std=c++17 -Wall -Wextra -Wpedantic -Wformat -Wchkp -I../include -c customer.cpp
g++ -std=c++17 -Wall -Wextra -Wpedantic -Wformat -Wchkp -I../include -c display.cpp
g++ -std=c++17 -Wall -Wextra -Wpedantic -Wformat -Wchkp -I../include -c main.cpp
g++ -std=c++17 -Wall -Wextra -Wpedantic -Wformat -Wchkp -I../include -c passbook.cpp
g++ -std=c++17 -Wall -Wextra -Wpedantic -Wformat -Wchkp -I../include -c security.cpp
g++ -std=c++17 -Wall -Wextra -Wpedantic -Wformat -Wchkp -I../include -c staff.cpp
g++ -o Bank account.o customer.o display.o main.o passbook.o security.o staff.o
However this issue is not present when I build using Make on Ubuntu.
This is the Makefile in my root directory:
DIR = src
all:
cd $(DIR); mingw32-make
clean:
cd $(DIR); mingw32-make clean
This is the Makefile in my src subdirectory:
# Compiler options
# -std=c++17 enables ISO C++ 17 standard
CC = g++
CCFLAGS = -std=c++17 -Wall -Wextra -Wpedantic -
Wformat -Wchkp
i = ../include
# LOCFLAGS used to set tell the compiler where to find a
# header that is not in the same directory as the source
file itself
# LOCFLAGS will be set in directory level makefiles as
needed
LOCFLAGS = -I../include
# The list of object files that can be made in this
subdirectory
# is assigned to the make macro named $OBJECTS
OBJECTS = account.o customer.o display.o main.o
passbook.o \
security.o staff.o
# This rule says that the target named "all" depends on
those
# files. Executing "make all" in this subdirectory will cause
# make to build the object files (.o) listed in the macro
$OBJECTS
# and create an executable named "Bank" by linking them
all: $(OBJECTS)
$(CC) -o Bank $(OBJECTS)
# rule that says how to make a .o object file from a .cpp
source file
# for a given source file in a given directory you could
compile it
# into an object file by executing "make filename.o"
# $< and $# are macros defined by make
# $< refers to the file being processed (i.e., compiled or
linked )
# $# refers to the generated file
%.o: %.cpp
$(CC) $(CCFLAGS) $(LOCFLAGS) -c $<
# target to clean up the object files, core files and
executables
# executing "make clean" in this subdirectory will remove
all
# files named core, "Bank" or any file ending in .o or
.stackdump
clean:
del $(OBJECTS) core *.stackdump Bank
On Windows you're running in a command.com shell, not a POSIX shell. In command.com, the syntax cd src; mingw32-make is not legal. For example if I open a command.com terminal on a Windows system I see:
C:\Users\build> cd src; echo hi
The system cannot find the path specified.
In Windows command.com the command separator is a single & not a semicolon.
If you want to change directories portably you can use the -C option to GNU make. Also you should always use the $(MAKE) variable, not write out the make command by hand:
all:
$(MAKE) -C $(DIR)

Has anyone built gcc 8.2.0 on OpenBSD 6.3?

I am getting the following error when I try to build gcc 8.2.0 on OpenBSD 6.3:
/bin/sh ./libtool --tag=CC --mode=compile /home/shane/gcc-8.2.0/host-i386-unknown-openbsd6.3/gcc/xgcc -B/home/shane/gcc-8.2.0/host-i386-unknown-openbsd6.3/gcc/ -B/opt/gcc-8.2.0/i386-unknown-openbsd6.3/bin/ -B/opt/gcc-8.2.0/i386-unknown-openbsd6.3/lib/ -isystem /opt/gcc-8.2.0/i386-unknown-openbsd6.3/include -isystem /opt/gcc-8.2.0/i386-unknown-openbsd6.3/sys-include -DHAVE_CONFIG_H -I../.././libatomic/config/x86 -I../.././libatomic/config/posix -I../.././libatomic -I. -march=i486 -mtune=i386 -fomit-frame-pointer -Wall -Werror -pthread -g -O2 -MT fence.lo -MD -MP -MF .deps/fence.Tpo -c -o fence.lo ../.././libatomic/fence.c
libtool: compile: /home/shane/gcc-8.2.0/host-i386-unknown-openbsd6.3/gcc/xgcc -B/home/shane/gcc-8.2.0/host-i386-unknown-openbsd6.3/gcc/ -B/opt/gcc-8.2.0/i386-unknown-openbsd6.3/bin/ -B/opt/gcc-8.2.0/i386-unknown-openbsd6.3/lib/ -isystem /opt/gcc-8.2.0/i386-unknown-openbsd6.3/include -isystem /opt/gcc-8.2.0/i386-unknown-openbsd6.3/sys-include -DHAVE_CONFIG_H -I../.././libatomic/config/x86 -I../.././libatomic/config/posix -I../.././libatomic -I. -march=i486 -mtune=i386 -fomit-frame-pointer -Wall -Werror -pthread -g -O2 -MT fence.lo -MD -MP -MF .deps/fence.Tpo -c ../.././libatomic/fence.c -fPIC -DPIC -o .libs/fence.o
../.././libatomic/fence.c:26:10: fatal error: stdatomic.h: No such file or directory
#include <stdatomic.h>
^~~~~~~~~~~~~
compilation terminated.
gmake[4]: *** [Makefile:491: fence.lo] Error 1
gmake[4]: Leaving directory '/home/shane/gcc-8.2.0/i386-unknown-openbsd6.3/libatomic'
gmake[3]: *** [Makefile:524: all-recursive] Error 1
gmake[3]: Leaving directory '/home/shane/gcc-8.2.0/i386-unknown openbsd6.3/libatomic'
gmake[2]: *** [Makefile:360: all] Error 2
gmake[2]: Leaving directory '/home/shane/gcc-8.2.0/i386-unknown-openbsd6.3/libatomic'
gmake[1]: *** [Makefile:21680: all-target-libatomic] Error 2
gmake[1]: Leaving directory '/home/shane/gcc-8.2.0'
gmake: *** [Makefile:943: all] Error 2
My process:
Install OpenBSD (using defaults)
Run syspatch
Add some packages:
# pkg_add wget
# pkg_add gmp mpfr libmpc
# pkg_add gmake
Get the source:
$ wget ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-8.2.0/gcc-8.2.0.tar.gz
$ tar xzf gcc-8.2.0.tar.gz
$ cd gcc-8.2.0
Build:
$ ./configure --prefix=/opt/gcc-8.2.0 --with-gmp=/usr/local --enable-languages=c,c++
$ gmake
This also fails with gcc 8.1.0 in a similar way.
I also tried using clang rather than gcc to build, like this:
$ CC=cc CXX=c++ ./configure --prefix=/opt/gcc-8.2.0 --with-gmp=/usr/local --enable-languages=c,c++
That made no difference, which makes some sense as apparently it is failing in stage 3 (gcc compiling itself again for a final check).
Annoyingly, there is a stdatomic.h file in the tarball:
$ find gcc-8.2.0 -name stdatomic.h
gcc-8.2.0/gcc/ginclude/stdatomic.h
So I have no idea what I am missing.
Has anyone successfully built this? How?

automake cannot deduce `_OBJECTS` from `_SOURCES` when using Pattern-Rules

Automake usually can deduce object names needed for linking from the list of _SOURCES.
The following example using old-fashioned suffix rules works:
ACLOCAL_AMFLAGS = -I m4
bin_PROGRAMS = testam
testam_SOURCES = testam.c c.asn1
.asn1.c:
> $#
_
$ rm -f testam && make
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o testam.exe testam.o c.o
libtool: link: gcc -g -O2 -o testam.exe testam.o c.o
As you can see, automake added the file c.o to the list of objects required to build testam.
But c.o isn't added, if I try to convert the rule into a pattern-rule:
%.c: %.asn1
> $#
_
$ rm -f testam && make
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o testam.exe testam.o
libtool: link: gcc -g -O2 -o testam.exe testam.o
I have to use pattern rules, because my tool actually has two outputs: %.c %.h: %.asn1.
Why is this happening and how to explicitly add object files? Should I use _DEPENDENCIES and _LDADD or maybe BUILT_SOURCES?
Update
Automake's dependency tracking does not work for object files added with:
foo_LIBADD: extra1.o extra2.o
.Po files are generated, but Makefile does not include them

Library fails to build if "autoreconf -i" is run before ./configure

I'm working with a tool that is supposed to simplify the build process of Unix-based apps. One of the things it does automatically is run "autoreconf -i" before doing "./configure". However, when it tries to build the expat library on OSX (Lion), the build fails:
$ tar xfz expat-2.0.1.tar.gz; cd expat-2.0.1
$ autoreconf -i
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `conftools'.
glibtoolize: copying file `conftools/ltmain.sh'
glibtoolize: You should add the contents of the following files to `aclocal.m4':
glibtoolize: `/usr/bin/../share/aclocal/libtool.m4'
glibtoolize: `/usr/bin/../share/aclocal/ltoptions.m4'
glibtoolize: `/usr/bin/../share/aclocal/ltversion.m4'
glibtoolize: `/usr/bin/../share/aclocal/ltsugar.m4'
glibtoolize: `/usr/bin/../share/aclocal/lt~obsolete.m4'
glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
glibtoolize: rerunning glibtoolize, to keep the correct libtool macros in-tree.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
$ ./configure
(Lots of output here)
configure: creating ./config.status
config.status: creating Makefile
config.status: WARNING: Makefile.in seems to ignore the --datarootdir setting
config.status: creating expat_config.h
$ make
bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c
./libtool: line 473: CDPATH: command not found
./libtool: line 1297: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
libtool: and run autoconf again.
On the other hand, if I don't do autoreconf first, it build just fiine:
$ cd ..; rm -r expat-2.0.1; tar xfz expat-2.0.1.tar.gz; cd expat-2.0.1
$ ./configure
(Lots of output here)
configure: creating ./config.status
config.status: creating Makefile
config.status: creating expat_config.h
$ make
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c
/bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:2:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/codepage.o -c xmlwf/codepage.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/unixfilemap.o -c xmlwf/unixfilemap.c
/bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la
What is "autoreconf -i" doing, and why is it causing the build to fail?
I think the problem is here:
libtool: Version mismatch error. This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
libtool: and run autoconf again.
In my experience with OS X Leopard and Snow Leopard (I have not tried Lion yet), the autotools actually installed with OS X are not recent enough to actually reconfigure anything for the system. So I usually grab the latest autotools from a GNU mirror and make a local version of them if I need to reconfigure.
"autoreconf -i" copies files from the installed GNU autotools to AC_CONFIG_AUX_DIR, an in this case is probably ltmain.sh.
A user should never run autoreconf. As ldav1s points out (+1), the autotools installed on your box do not match the tools used to generate the tarball. There are many packages in the wild that recommend (or even require) the user to run autoconf in some form to build the package; those packages are broken. A properly built package should build on a machine that does not have any of the autotools installed, and unless you are a package maintainer you should probably just uninstall them. IMO, they should not be included in default installations.
If you use a package that requires the autotools to build, please report that as a bug to the package maintainer. If a version control system (eg git, hg, svn ) is being used as the distribution mechanism, then you will either need to run the autotools to build the package or the package will have to include autotools generated files in the repository. This is why version control systems should not be used as a distribution tool for packages that use the autotools.

How to make automake less ugly?

I recently learned how to use automake, and I'm somewhat annoyed that my compile commands went from a bunch of:
g++ -O2 -Wall -c fileName.cpp
To a bunch of:
depbase=`echo src/Unit.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I./src -g -O2 -MT src/Unit.o -MD -MP -MF $depbase.Tpo -c -o src/Unit.o src/Unit.cpp &&\
mv -f $depbase.Tpo $depbase.Po
Is there any way to clean this up? I can usually easily pick out warning messages, but now the wall of text to read though is 3x bigger and much weirder.
I know what my flags are, so making it just says "Compiling xxx.cpp" for each file would be perfect.
As of automake 1.11, you can greatly clean up the output using the silent-rules option. For example:
$ # First, make without silent rules
$ make
make all-am
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT foo.o -MD -MP -MF .deps/foo.Tpo -c -o foo.o foo.c
mv -f .deps/foo.Tpo .deps/foo.Po
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o foo foo.o
libtool: link: gcc -g -O2 -o foo foo.o
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT bar.o -MD -MP -MF .deps/bar.Tpo -c -o bar.o bar.c
mv -f .deps/bar.Tpo .deps/bar.Po
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o bar bar.o
libtool: link: gcc -g -O2 -o bar bar.o
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT baz.o -MD -MP -MF .deps/baz.Tpo -c -o baz.o baz.c
mv -f .deps/baz.Tpo .deps/baz.Po
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o baz baz.o
libtool: link: gcc -g -O2 -o baz baz.o
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT qux.o -MD -MP -MF .deps/qux.Tpo -c -o qux.o qux.c
mv -f .deps/qux.Tpo .deps/qux.Po
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o qux qux.o
libtool: link: gcc -g -O2 -o qux qux.o
$ # Now, use the silent rules
$ ./configure --enable-silent-rules > /dev/null
$ make clean all
rm -f foo bar baz qux
rm -rf .libs _libs
rm -f *.o
rm -f *.lo
make all-am
CC foo.o
CCLD foo
CC bar.o
CCLD bar
CC baz.o
CCLD baz
CC qux.o
CCLD qux
All that is needed is to add "silent-rules" to the invocation
of AM_INIT_AUTOMAKE in configure.ac, and add the option
--enable-silent-rules when you invoke configure. (There
was much debate about requiring the option to be added
at configure time when this feature was added, and there
is an easy workaround to make it unnecessary.) Note that
with silent-rules enabled, you can still get verbose
output by running 'make V=1'
I did a bit of googling around as I am in the same boat, the autoconf tools do a nice job but it kind of wrecks your eyes when the text whizzes by and no way of knowing what was that about... here is a link to a blog that mentions a tool to do this and make it look like neater just like how you see a kernel build does the magic i.e.
Compiling foo.so
Linking foo.so
Here is another link to a tool that is called prettify automake.

Resources