As we support CentOS, for example, we have a problem there
automake: warnings are treated as errors
kconfig/Makefile.am:26: warning: compiling 'lxdialog/checklist.c' in subdir requires 'AM_PROG_CC_C_O' in
'configure.ac'
autoreconf: automake failed with exit status: 1
Automake does not allow us to place the hooks before its generated actions,
and does not allow us to check MAKECMDGOALS, and does not support a mechanism
for disabling make install (such as noinst_SUBDIRS, requested a few times
on automake mailing list). The only way I could preserve the current behavior
is to have a GNUmakefile wrapper that will convert MAKECMDGOAL into a variable
unknown to automake - which seems too convoluted a solution for the problem
being solved.
Hence the approach is to not override anything for --enable-local. It is now
fully handled by selecting different values for CT_xxx_DIR in ct-ng.in; but
at the build-system level, all the variables remain the same. We just don't
support 'make install' in that case anymore; but the ct-ng in the working
copy can be used after a regular 'make' (or 'make all').
Help message for --enable-local updated accordingly.
Signed-off-by: Alexey Neyman <stilor@att.net>
Instead, just honor CFLAGS/CPPFLAGS/LDFLAGS as they're passed down from
configure. This brings the build process in compliance with the
recommended practices.
Signed-off-by: Alexey Neyman <stilor@att.net>
They don't make sense - using same ct-ng won't work with different versions,
so they cannot coexist in the same prefix.
Also localize other configure variables so that their usage is easier to track.
Signed-off-by: Alexey Neyman <stilor@att.net>
- Update to 20180129
- Throw in --disable-db-install if database is disabled; otherwise
'make install' tries to run tic which is not built.
- Select appropriate strip utility for the host; otherwise non-x86
architectures fail to install (unless --disable-stripping is also
added)
Signed-off-by: Alexey Neyman <stilor@att.net>
- Update .gitignore, do not place .gitignore into directories installed
in bulk
- Remove executable permissions and shebangs from the scripts that are
supposed to be invoked only via ct-ng frontent; prepend them with $(bash).
Despite what showSamples.sh said, it already has some bashisms.
- Remove --with autotools-dev and override dh_update_autotools_config
to avoid having config.{sub,guess} clobbered with older versions
- Install bash completion where Debian (now) expects it
- Update man page to use .\" as the comment delimiter, instead of
undefined macro (."); also, minor text edits.
- Install kconfig.mk without execute permission.
- Remove shell wrappers from 170-localedef-fix-trampoline.patch, we
do not use that for applying patches
- Revoke execute permissions on 210-expat.sh
- Get flags from dpkg-buildflags if available
Signed-off-by: Alexey Neyman <stilor@att.net>
from configure rather than substitute it from Makefile. Eventually we
might want to get rid of configure.in completely, doing on-the-fly
checks at the time of `ct-ng build`, but that is left for another day.
Signed-off-by: Alexey Neyman <stilor@att.net>
configure.ac now finds how to count the CPUs in a system. Currently
the getconf method and sysctl methods are supported. Adding more is
easy enough.
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Some software starts to adopt xz-only distribution (strace,
gcc-linaro, ...). Better that than deal with cryptic errors like
"cannot find strace-.tar.bz2".
Signed-off-by: Alexey Neyman <stilor@att.net>
After much struggling with macos (BSD) sed and even getting everything
work in crosstool-ng itself, I had to abandon that because some
components rely on GNU syntax. Specifically, GNU libc uses '/.../{H;g}'
(note absense of the separator after 'g').
So, revert the -r/-E detection and check for sed's being of GNU origin.
MacOS people, sorry, but you'd have to install GNU sed.
Signed-off-by: Alexey Neyman <stilor@att.net>
... and then use the right option. See the note in scripts/functions
on where we should use ${foo} and where just 'foo'; this boils down to
whether we can expect the build tools override to be in effect (e.g. in
the actual build scripts) or not (i.e. outside of scripts/build).
While running in scripts/functions, or in scripts/crosstool-NG.sh the
build tools override directory (.build/tools/bin) may have not been
set up (yet, or at all).
Also, modify the installed scripts (populate, xldd) accordingly.
Signed-off-by: Alexey Neyman <stilor@att.net>
Rather than requiring them of a certain version, detect if they are present
(and have sufficient version) and select an appropriate companion tool
otherwise. The reason is that, for example, most recent gettext requires
automake 1.15, but the newest available CentOS has 1.13. Hence, the option
to "upgrade your system" does not apply, and the warning comment above
the companion tools is rather scary.
With this approach, it will work out of the box - either by using the host's
tools, or by building them as needed. Note that the user can still change
the setting in the config.
While there, propagate the new version checking macro to awk/bash/host binutils,
and switch from --with-foo=xxx to officially blessed FOO=xxx: the latter
does not require checking for bogus values (i.e., --with-foo, --without-foo)
and AC_PROG_* macros recognize the corresponding settings without further
modifications. For now, I kept --with-foo=, if only to complain and steer
people to the new way. To be cleaned up after a release.
Signed-off-by: Alexey Neyman <stilor@att.net>
Allow selection of make/m4/... version. Support imports of new versions
via addToolVersion.sh. Import newest versions of the companion tools.
One non-trivial change is the handling of make versions. Existing code
was not handling make companion tool as described (see the previous
commit). However, since most modern systems have make 4.x, that previous
commit made crosstool-ng always build make as a companion tool.
This traces back to the commit dd15c93 from 2014. That commit's log message
says that actually it was 3.81 which broke the build for certain component
(it was originally breaking eglibc, but I noticed it was breaking current
glibc on powerpc64), and introduced an option to force using 3.81 by
"components that really need it". It looks like in 2.5 years we haven't
seen any such components that really need make 3.81, and (given that make
has already had a few releases since 3.81) we're unlikely to see them
in the future.
Hence, the configure check is changed from "exactly 3.81" to "3.81 or newer".
In its current form, configure will accept make 3.80+, and will not require
make as a companion tool for 3.81+. We might want to bump the latter check
to even newer version given the claim from dd15c93. Killed
COMP_TOOLS_make_3_81_NEEDED.
Anyway, I retained 3.81 just in case; ditto for m4 1.14.3, autoconf 2.65
and automake 1.11.1.
Signed-off-by: Alexey Neyman <stilor@att.net>
Because I don't pass `-o` to gcc, it makes an a.out file with gcc.
For clang it doesn't make the a.out, as that is not the default.
It doesn't hurt to output to /dev/null for both.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This is a semi-nasty-hack to see if gcc can static link.
Obviously on Mac OS X this is not possible, so we set
CT_CONFIGURE_has_static_link=y if it can.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
I previously thought that tinfo could only be a link to libncurses in
modern ncurses installations. I was wrong.
Now we check for ncurses, then check for tinfo. If tinfo is a link to
ncurses, it is then not required to link against. But if libtinfo is
providing tgetent, and not libncurses, then we must add it to LIBS as
well.
Also, kconfig shouldn't hardcode -lncurses, it should use what is in
$(LIBS).
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
We require GNU/patch, and when we install patch with `pkg`, crosstool-ng
still only finds the BSD/patch in /usr/bin/patch.
This commit fixes that and searches for gpatch first.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
While usually distributed with ncurses, some distributions distribute
this library separately. Check to make sure it is installed.
This closes#241
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
I was going to start doing some autoconf work, and noticed that
configure.in was executable. Then I noticed Makefile.in was executable.
o.O
So, I ran ```find . -type f -executable``` and found a bunch of files
that shouldn't be set executable.
This commit makes them normal files again.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
