[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How do I resolve ncurses build error in source file generated by MKl
From: |
Thomas Dickey |
Subject: |
Re: How do I resolve ncurses build error in source file generated by MKlib_gen.sh |
Date: |
Thu, 12 Sep 2024 19:47:07 -0400 |
On Wed, Sep 11, 2024 at 10:48:51AM +0000, Peter Groves wrote:
> Hi Thomas
>
> I spent some time with a colleague who has a lot mor experience than I have.
> Collectively we managed to resolve the issues and get ncurses-6.5 to build
> successfully.
> I attach the latest logfile, which includes the spec file at the top.
>
>
> Here is what was done, still using ncurses-6.5.....
>
> Key to solving this was to establish which "gcc" might be invoked. Ltib adds
> a path to a spoof-wrapper perl script which was being picked up via "gcc".
>
> "/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/spoof:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/bin:/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin"
>
>
> pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto:pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$>
> ls -l /opt/freescale/ltib/usr/spoof
> total 24
> lrwxrwxrwx 1 root root 13 May 15 2013 addr2line -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 ar -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 as -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 c++ -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 cc -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 c++filt -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 cpp -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 g++ -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 gasp -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 gcc -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 ld -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 nm -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 objcopy -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 objdump -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 ranlib -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 readelf -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 size -> spoof_wrapper
> -rwxr-xr-x 1 root root 3117 May 19 2011 spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 strings -> spoof_wrapper
> lrwxrwxrwx 1 root root 13 May 15 2013 strip -> spoof_wrapper
> -rwxr-xr-x 1 root root 17394 May 19 2011 tc_wrapper
>
> It's possible that the spoof_wrapper ended up selecting one of two old
> "gcc"-prepended compilers.
>
>
> pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto:pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$>
> find /opt/freescale -type f -name gcc
>
> /opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/arm-fsl-linux-gnueabi/bin/gcc
>
> /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/bin/gcc
>
> pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto:pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$>
> ls -l /opt/freescale/usr/local/
> total 8
> drwxr-xr-x 3 root root 4096 May 19 2011 gcc-4.1.2-glibc-2.5-nptl-3
> drwxr-xr-x 3 root root 4096 Dec 11 2013
> gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12
>
> Suffice to say the first change was to re-export the path in the ncurses spec
> to effectively remove the spoof path from the PATH variable.
> "export
> PATH=/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/bin:/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin"
>
> This somehow got rid of "error: configure: error: Cross-build requires two
> compilers" but led to linker errors for ncurses proper, due to the build in
> all likelihood using the host gcc compiler.
>
> gcc -DHAVE_CONFIG_H -DBUILDING_NCURSES -I../ncurses -I. -I../include
> -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNDEBUG -O2 --param
> max-inline-insns-single=1200 -fPIC -c ../ncurses/./tty/hardscroll.c -o
> ../obj_s/hardscroll.o
> ........
> linking
> /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/ncurses//opt/freescale/rootfs/arm/usr/lib/libncursesw.so.6.5
> gcc -O2 --param max-inline-insns-single=1200 -shared
> -Wl,-soname,`basename
> /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/ncurses//opt/freescale/rootfs/arm/usr/lib/libncursesw.so.6.5
> .6.5`.6,-stats,-lc -o
> /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/ncurses//opt/freescale/rootfs/arm/usr/lib/libncursesw.so.6.5
> ../obj_s/hardscroll.o
> ......
> ../obj_s/hardscroll.o: file not recognized: File format not recognized
>
> As you pointed out in your comment made earlier that "Generally cross-tools
> are built with the architecture as part of the name, to work around
> name-conflicts", by exporting the following in the ncurses spec file, paths
> could effectively be configured for both host and target gcc compilers.
>
> export CC=arm-none-linux-gnueabi-gcc
> ./configure --prefix=%{_prefix} --host=$CFGHOST --build=%{_build} \
> --with-install-prefix=$RPM_BUILD_ROOT --mandir=%{_mandir} \
> --with-shared --without-debug --without-cxx-binding \
> --disable-termcap --with-build-cc=/usr/bin/gcc
>
> The target now ends up using the correct cross-compiler.
>
> /usr/bin/gcc -o make_keys -DHAVE_CONFIG_H -DUSE_BUILD_CC -I../ncurses
> -I. -I../include -I./../include ./tinfo/make_keys.c
> ./make_keys keys.list > init_keytry.h
> arm-none-linux-gnueabi-gcc -DHAVE_CONFIG_H -DBUILDING_NCURSES
> -I../ncurses -I. -I../include -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600
> -D_FILE_OFFSET_BITS=64 -DNDEBUG -O2 --param max-inline-insns-single=1200
> -fPIC -c ../ncurses/./tty/hardscroll.c -o ../obj_s/hardscroll.o
>
> The ncurses rpm as well as the user-space libraries and "bluetoothctl"
> executable are generated in rootfs.
>
>
> /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/RPMS/arm/ncurses-6.5-1.arm.rpm
>
> Eagle-Ltib/rootfs/usr/lib/libncursesw.so.6.5
> Eagle-Ltib/rootfs/usr/lib/libncursesw.so
> Eagle-Ltib/rootfs/usr/lib/libncursesw.so.6
> Eagle-Ltib/rpm/BUILD/bluez-5.65/client/bluetoothctl
> Eagle-Ltib/rootfs/bin/bluetoothctl
>
> By setting a path to the ncurses library in the bluez-5.65 spec, the
> "undefined references" linker error could now be resolved.
>
> LIBS="$DEV_IMAGE/usr/lib/libncursesw.so.6.5"
>
> The problem now is that the overall target image has now swelled in size by
> another 2M, so I need to check if some "configure" options can be disabled in
That sounds like more than just the library - perhaps some statically-linked
stuff got included. I'd expect 500-600kb for the ncurses library itself.
> the ncurses spec, for things that we might not need. I've been through this
> exercise with some of the other spec files, which I may also need to revisit.
For readline, you should only need half of the library, which
can be configured using "--with-termlib"
https://invisible-island.net/ncurses/INSTALL.html#option:with-termlib
--with-termlib[=XXX]
When building the ncurses library, organize this as two parts: the
curses library (libncurses) and the low-level terminfo library
(libtinfo). This is done to accommodate applications that use only
the latter. The terminfo library is about half the size of the total.
If an option value is given, that overrides the name of the terminfo
library. For instance, if the wide-character version is built, the
terminfo library would be named libtinfow. But the libtinfow interface
is upward compatible from libtinfo, so it would be possible to overlay
libtinfo.so with a "wide" version of libtinfow.so by renaming it with
this option.
The terminal database can be large - see
https://invisible-island.net/ncurses/ncurses.faq.html#big_terminfo
> I thought that resolution of the issues would be of interest to you, so
> pardon the detail.
> Thanks ever so much for your kind assistance and patience.
>
> Kind Regards.
> Peter
>
>
> -----Original Message-----
> From: Thomas Dickey <dickey@his.com>
> Sent: 10 September 2024 01:30
> To: Peter Groves <pgroves@miurasystems.com>
> Cc: dickey@his.com; bug-ncurses@gnu.org
> Subject: Re: How do I resolve ncurses build error in source file generated by
> MKlib_gen.sh
>
> On Mon, Sep 09, 2024 at 04:39:34PM +0000, Peter Groves wrote:
> > HI Thomas
> >
> > Thanks for the heads-up and explanation.
> >
> > I'm not quite sure I follow entirely. Are you saying that in later versions
> > of ncurses, it will figure out when it needs to use the host gcc compiler
> > e.g. to build "make_keys" and when it needs to compile the rest of ncurses
> > using the cross-compiler provided in the PATH variable which, without the
> > prepend, is as follows:
>
> no, it's not that smart. The configure script looks for executables with
> a prefix derived from the target name.
>
> For example, in my mingw cross-build, invoking the configure script with
> (digging the details out of a script...)
>
> BUILD_CC=${CC:-gcc}
> TARGET=i686-w64-mingw32
> ...
> --with-build-cc=$BUILD_CC \
> --host=$TARGET \
> --target=$TARGET \
>
> the log begins
>
> configure: WARNING: If you wanted to set the --build type, don't use
> --host.
> If a cross compiler is detected then cross compile mode will be
> used.
> checking for ggrep... no
> checking for grep... grep
> checking for egrep... grep -E
> Configuring NCURSES 6.5 ABI 6 (Sat Aug 31 18:10:27 EDT 2024)
> checking for package version... 6.5
> checking for package patch date... 20240831
> ABI VERSION 5:0:10
> VERSION_MAJOR 6
> VERSION_MINOR 5
> VERSION_PATCH 20240831
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... i686-w64-mingw32
> checking target system type... i686-w64-mingw32
> Configuring for mingw32
> checking for fgrep... grep -F
> checking for prefix...
> checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc
> checking for C compiler default output... a.exe
> checking whether the C compiler works... yes
> checking whether we are cross compiling... yes
> checking for executable suffix... .exe
> checking for object suffix... o
> checking whether we are using the GNU C compiler... yes
> checking whether i686-w64-mingw32-gcc accepts -g... yes
> checking version of i686-w64-mingw32-gcc... 12
> checking if this is really Clang C compiler... no
>
> So on my machine, this tells me that it found "gcc" with a prefix-name:
>
> checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc
>
> If your arm compiler isn't named with a prefix, that's a problem that
> the configure script won't handle. Renaming its files won't work,
> because the compiler runs its related programs such as "cpp", "ld" and
> perhaps "as".
>
> Now... if that's the case, you could work around this by shell scripts
> which have the expected names that set PATH specially to run the arm
> compiler.
>
> Supposing that "arm-miura" is the proper prefix (actually for this purpose
> it's arbitrary), you could have a shell script named "arm-miura-gcc"
> containing something like
>
> #!/bin/sh
>
> PATH=/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin:$PATH
> exec gcc "$@"
>
> (assuming that's all that's needed for running the compiler). The
> spec file would have to have corresponding --target and --host options
> to get the configure script to look for "arm-miura-gcc".
>
> You can see if you got it right by running
>
> arm-miura-gcc --version
>
> You'd need similar scripts for the related utilities which may be used
> directly from the makefiles. Offhand those include
>
> ar
> cpp
> ld
> nm
> ranlib
> strip
>
> (though one can also use shell substitutions to make just a single script
> with corresponding alias-links).
>
> >
> >
> > "/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/spoof:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/bin:/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin"
> >
> > The next release of ncurses after 5.3 was 5.4 (8th Feb 2004) and I can see
> > your extracted chunks from "configure" match the changes in 5.4.
> > I therefore had a go at upgrading to ncurses 6.5 as shown below, commenting
> > out the PATH variable prepend I had been experimenting with previously but
> > retaining the upfront "make clean" and "--with-build-cc=/usr/bin/gcc"
> > setting.
> > The build fails during the configure (I've included the pertinent extra
> > only), which I'm guessing alludes to what you are talking about:
> >
> > checking for an installation directory prefix...
> > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/ncurses
> > checking for native build C compiler... /usr/bin/gcc
> > checking for native build C preprocessor... ${BUILD_CC} -E
> > checking for native build C flags...
> > checking for native build C preprocessor-flags...
> > checking for native build linker-flags...
> > checking for native build linker-libraries...
> > checking if the build-compiler "/usr/bin/gcc" works... no
>
> config.log would show the actual message telling why this check failed.
> It might be a conflicting "ld" name, for example.
>
> > configure: error: Cross-build requires two compilers.
> > Use --with-build-cc to specify the native compiler.
> > error: Bad exit status from
> > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/rpm-tmp.88683
> > (%build)
> >
> > Do I need an additional setting in the spec file, for the "configure" to
> > detect "if test "$cross_compiling" = yes ; then"? I don't see anything in
> > "./configure -help" for this.
> > What other changes would you suggest, please?
> >
> > pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto:pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto:pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto:pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$>>
> > cat ./Eagle-Ltib/dist/lfs-5.1/ncurses/ncurses.spec
> > %define pfx /opt/freescale/rootfs/%{_target_cpu}
> >
> > Summary : CRT screen handling and optimization package
> > Name : ncurses
> > Version : 6.5
> > Release : 1
> > License : Distributable
> > Vendor : Freescale
> > Packager : Stuart Hughes!
> > Group : System Environment/Libraries
> > Source : %{name}-%{version}.tar.gz
> > BuildRoot : %{_tmppath}/%{name}
> > Prefix : %{pfx}
> >
> > %Description
> > %{summary}
> >
> > %Prep
> > %setup
> >
> > %Build
> > CFLAGS="%{optflags} -DPURE_TERMINFO -DSVR4_CURSES"
> > %define optflags $CFLAGS
> > #export PATH=/usr/bin:$PATH (comment out this path prepend)
> > echo "=================="
> > echo $PATH
> > echo " "
> > echo "=================="
> > if [ "$GNUTARCH" != m68knommu ]
> > then
> > ./configure --prefix=%{_prefix} --host=$CFGHOST --build=%{_build} \
> > --with-install-prefix=$RPM_BUILD_ROOT --mandir=%{_mandir} \
> > --with-shared --without-debug --without-cxx-binding \
> > --disable-termcap --with-build-cc=/usr/bin/gcc
> > else
> > ./configure --prefix=%{_prefix} --host=$CFGHOST --build=%{_build} \
> > --with-install-prefix=$RPM_BUILD_ROOT --mandir=%{_mandir} \
> > --without-shared --without-debug --without-cxx-binding \
> > --disable-termcap
> > fi
> > echo "=================="
> > echo $RPM_BUILD_ROOT
> > echo " "
> > echo $PATH
> > echo " "
> > echo "=================="
> > make clean
> > echo "=================="
> > echo $RPM_BUILD_ROOT
> > echo " "
> > echo $BUILDCC
> > echo " "
> > echo $PATH
> > echo " "
> > echo "=================="
> > make -j1 HOSTCC="$BUILDCC"
> >
> > sed -e 's%$srcdir/shlib tic$suffix%/usr/bin/tic$suffix%' \
> > misc/run_tic.sh > misc/run_tic.sh.tmp
> > mv misc/run_tic.sh misc/run_tic.sh.orig
> > mv misc/run_tic.sh.tmp misc/run_tic.sh
> >
> > %Install
> > rm -rf $RPM_BUILD_ROOT
> > make -j1 install DESTDIR=$RPM_BUILD_ROOT/%{pfx}
> > includedir=%{_prefix}/include/ncurses libdir=%{_prefix}/lib
> > mandir=%{_mandir}
> >
> > #(original sample spec chunk here removed for now, until build issues
> > resolved)
> >
> > %Clean
> > rm -rf $RPM_BUILD_ROOT
> >
> >
> > %Files
> > %defattr(-,root,root)
> > %{pfx}/*
> >
> >
> > Thanks.
> >
> > Kind Regards.
> > Peter
> >
> >
> > -----Original Message-----
> > From: Thomas Dickey <dickey@his.com<mailto:dickey@his.com>>
> > Sent: 07 September 2024 19:21
> > To: Peter Groves <pgroves@miurasystems.com<mailto:pgroves@miurasystems.com>>
> > Cc: dickey@his.com<mailto:dickey@his.com>;
> > bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org>
> > Subject: Re: How do I resolve ncurses build error in source file generated
> > by MKlib_gen.sh
> >
> > On Fri, Sep 06, 2024 at 10:11:08AM +0000, Peter Groves wrote:
> > > Hi Thomas
> > >
> > > Yes, the current build-log does show the directories in PATH begin with
> > > /usr/bin because as mentioned in my e-mail Tue 03/09/2024, I explicitly
> > > changed the ncurses spec file to prepend the PATH variable with path to
> > > host gcc i.e. "export PATH=/usr/bin:$PATH", before the "make -j1" for a
> > > specific reason.
> > >
> > > * When the PATH variable is set as follows, "make_keys.c" is
> > > compiled using the cross-compiler path:
> > >
> > > "/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/spoof:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/bin:/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin"
> > > The "with-build-cc=/usr/bin/gcc" setting has no effect and the
> > > following error occurs as a result:
> > > > > # gcc -o make_keys -DHAVE_CONFIG_H -I../ncurses -I.
> > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include -D_GNU_SOURCE -DNDEBUG
> > > -O2 ./tinfo/make_keys.c
> > > > > # AWK=mawk sh ./tinfo/MKkeys_list.sh ../include/Caps |
> > > sort >keys.list
> > > > > # ./make_keys keys.list > init_keytry.h
> > > > > # /bin/sh: ./make_keys: cannot execute binary file:
> > > Exec format error
> > > > > # make[1]: *** [Makefile:196: init_keytry.h] Error 126
> > > * Alternatively, when the PATH variable is prepended as outlined,
> > > "make_keys.c" builds correctly using the host compiler /usr/bin/gcc.
> > >
> > > "/usr/bin:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/spoof:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/bin:/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin"
> > > The problem is that the build system will obviously continue to use
> > > the host gcc compiler to build the rest of ncurses e.g. gcc -O2 -o
> > > ncurses ../obj_s/ncurses.o -L../lib -lform -lmenu -lpanel -lncurses
> > > -Wl,-rpath,/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/lib
> > > -I../test -I. -DHAVE_CONFIG_H -I. -I../include -D_GNU_SOURCE -DNDEBUG
> > > -O2 -fPIC
> > > The following error occurs as a result:
> > >
> > > /opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/
> > > bin/arm-miura-linux-gnueabi-objdump:
> > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/ncurses/opt/fr
> > > eescale/rootfs/arm/usr/lib/libncurses.so.5.4: File format not
> > > recognized
> > >
> > > > But you can change the PATH (putting the arm directory first),
> > > > and find out quickly without much pain. If that doesn't work, you need
> > > > another plan...
> > > That is effectively what I am doing when I don't prepend the PATH
> > > variable with "usr/bin".
> > >
> > > > Now... if that arm compiler is named "gcc", then there's going to
> > > > be a conflict on the $PATH.
> > > At the end of the day, some components for ncurses need to be built using
> > > the host compiler and others cross-compiled and the build system seems to
> > > be picking whatever "gcc" path appears first in the PATH variable. It's a
> > > bit of a chicken and egg situation. If I understand you correctly, I
> > > "think" that's what you are inferring by your comment.
> > >
> > > I hope I am making myself clear.
> >
> > sure. I'm working on a 20+ year-old-bug report :-)
> >
> > ncurses 5.3 was October 12, 2002.
> >
> > Later that year, I modified the configure script:
> >
> > 20021214
> > + allow BUILD_CC and related configure script variables to be
> > overridden from the environment.
> > ...
> > + use $cross_compiling variable in configure script rather than
> > comparing $host_alias and $target alias, since "host" is
> > traditionally misused in autoconf to refer to the target platform.
> >
> > The latter part is this chunk:
> >
> > --- ncurses-5.3/configure 2002-09-22 00:49:14.000000000 +0000
> > +++ ncurses-5.3-build/configure 2024-09-07 17:55:57.687860944 +0000
> > @@ -1976,7 +1976,7 @@
> > BUILD_CPPFLAGS='$(CPPFLAGS)'
> > BUILD_LDFLAGS='$(LDFLAGS)'
> > BUILD_LIBS='$(LIBS)'
> > -if test "$host_alias" != "$target_alias" ; then
> > +if test "$cross_compiling" = yes ; then
> >
> > # Check whether --with-build-cc or --without-build-cc was given.
> > if test "${with_build_cc+set}" = set; then
> >
> > There's a long story for that change - originally (mid-1990s) cross
> > compiling was only set up by invoking an autoconf macro (not something that
> > one could choose as an option on the command-line). Later, at the time
> > when I added the build-cc option, that was via command-line options but
> > using a different combination than you would now. It went through a few
> > (successively
> > incompatible) changes, and post-5.3 I found that autoconf developers had
> > changed it again - hence this fix.
> >
> > I didn't keep the generated configure script or config.sub, config.guess in
> > source-control at that time -- it was too much diskspace -- times have
> > changed -- so I can't readily show the timeline of those changes to the
> > cross-compiling support in autoconf.
> >
> > ...at that time, I wasn't doing cross-compiles, but relied upon comments by
> > others, e.g., comments on mailing lists, and occasional fixes from users.
> > Since this turned out to be a problem, I found how to set up a
> > cross-compiler a few months later.
> >
> > https://invisible-island.net/personal/cross-mingw.html#cross_dev
> >
> > ...I don't have an arm cross-compiler, but with that change the mingw
> > cross-compiler does use the proper compiler -- and runs into a different
> > problem (basically lacks the workaround for missing termios support which
> > we added several years later).
> >
> > You might not run into that sort of problem, but if you do, upgrading might
> > improve the odds of successfully building.
> >
> > > Thanks.
> > >
> > > Regards.
> > > Peter
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Thomas Dickey
> > > <dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com>>>
> > > Sent: 05 September 2024 21:26
> > > To: Peter Groves
> > > <pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:pgroves@miurasystems.com>>>
> > > Cc:
> > > dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com>>;
> > >
> > > bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org>>
> > > Subject: Re: How do I resolve ncurses build error in source file
> > > generated by MKlib_gen.sh
> > >
> > > On Wed, Sep 04, 2024 at 11:45:35AM +0000, Peter Groves wrote:
> > > > Hi Thomas
> > > >
> > > > I'd already made the "--with-build-cc=/usr/bin/gcc " change, if you
> > > > look at the spec file which I dumped in tarred logfile
> > > > build_030924_1445.tar.gz (attached in my previous e-mail). I don't
> > > > think it's having an effect however because it's using the PATH
> > > > variable to determine which gcc to build with, so it's either going to
> > > > use /usr/bin (host compiler path) or
> > > > /opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin
> > > > (cross-compiler path) to build with, depending on what appears first
> > > > in the PATH variable.
> > > >
> > > > The problem now is that it's building the entire ncurses package
> > > > using the host compiler gcc. Am I correct in saying that it only
> > > > needs gcc in /usr/bin/ to build "make_keys" and "make_hash" and then
> > > > revert to using the cross-compiler to build the rest of the ncurses
> > > > package? I suspect that's
> > >
> > > that sounds right. However, the build-log shows the directories in PATH
> > > begin with /usr/bin:
> > >
> > > /usr/bin
> > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin
> > > /opt/freescale/ltib/usr/spoof
> > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin
> > > /opt/freescale/ltib/usr/bin
> > >
> > > /opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin
> > > /usr/local/bin
> > > /usr/bin
> > > /bin
> > > /usr/bin/X11
> > > /usr/X11R6/bin
> > >
> > > I assume you meant to put this first:
> > >
> > > /opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/
> > > bin
> > >
> > > I see the file-format-not-recognized messages, which mean that the tool
> > > isn't seeing the proper object file type.
> > >
> > > Now... if that arm compiler is named "gcc", then there's going to be a
> > > conflict on the $PATH. Some tools are smart enough to find their related
> > > tools (such as ld, as, cpp), and some aren't. If /usr/bin isn't up
> > > front, the related tools can also have naming conflicts.
> > >
> > > Offhand I don't know if gcc's going to do that.
> > > If this arm gcc isn't that smart, it complicates things.
> > >
> > > But you can change the PATH (putting the arm directory first), and find
> > > out quickly without much pain. If that doesn't work, you need another
> > > plan...
> > >
> > > Generally cross-tools are built with the architecture as part of the
> > > name, to work around name-conflicts. I have these in (Debian/oldstable)
> > > in the /usr/bin directory:
> > >
> > > /usr/bin/c89-gcc
> > > /usr/bin/c99-gcc
> > > /usr/bin/gcc
> > > /usr/bin/gnatgcc
> > > /usr/bin/i686-w64-mingw32-gcc
> > > /usr/bin/musl-gcc
> > > /usr/bin/x86_64-linux-gnu-gcc
> > > /usr/bin/x86_64-linux-gnu-gnatgcc
> > > /usr/bin/x86_64-linux-musl-gcc
> > > /usr/bin/x86_64-w64-mingw32-gcc
> > >
> > > Since ncurses 5.3, I've changed the configure scripts to use
> > > AC_CHECK_TOOL (which provides for this renaming) rather than
> > > AC_PROG_RANLIB (which doesn't allow for renaming).
> > >
> > > fwiw, I started doing that a year or two after ncurses 5.3 :-)
> > >
> > > Upgrading of course entails new risks. You might be able to work around
> > > name-conflicts for "gcc" by generating the source files with the native
> > > /usr/bin/gcc, and then adding them to the cross-build (with timestamps
> > > updated so that the system doesn't attempt to build them).
> > >
> > > The "make sources" rule just makes the source-files.
> > >
> > > > why I'm now seeing the following error in the Install phase for the
> > > > ncurses package, as per the logfile attachment build_040924_1200.tar.gz.
> > > >
> > >
> > > > /opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin/arm-miura-linux-gnueabi-objdump:
> > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/ncurses/opt/freescale/rootfs/arm/usr/lib/libncurses.so.5.4:
> > > > File format not recognized
> > > >
> > > >
> > > > It's a complete nightmare having to switch between compilers.
> > > >
> > > > Regards.
> > > > Peter
> > > >
> > > > -----Original Message-----
> > > > From: Thomas Dickey
> > > > <dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com>>>>
> > > > Sent: 04 September 2024 01:21
> > > > To: Peter Groves
> > > > <pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:pgroves@miurasystems.com>>>>
> > > > Cc:
> > > > dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com>>>;
> > > > bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org>>>
> > > > Subject: Re: How do I resolve ncurses build error in source file
> > > > generated by MKlib_gen.sh
> > > >
> > > > On Tue, Sep 03, 2024 at 04:08:53PM +0000, Peter Groves wrote:
> > > > > Hi Thomas
> > > > >
> > > > >
> > > > > I've had some measure of success in understanding the issues and in
> > > > > deriving and testing workarounds to at least overcome the issues,
> > > > > though they may not necessarily be the final solution.
> > > > > Thanks again for your observations and suggestions, as they helped
> > > > > tremendously in pointing me in the right direction.
> > > > > I attached the tarred logfile build_030924_1445.tar.gz, to which I've
> > > > > added my own notes for clarification. The build log illustrates
> > > > > completion of the ncurses package build phase, with failures
> > > > > occurring in the install phase, which I'll now focus my attention on.
> > > > >
> > > > > The overriding problem is that cross-compiler gcc path is being used
> > > > > to build 'make_keys' in
> > > > > Eagle-Ltib/rpm/BUILD/ncurses-5.3/ncurses/Makefile, rather than the
> > > > > host gcc compiler in /usr/bin. By applying the cross-compiler gcc
> > > > > path, the 'make_keys' executable cannot run on the host system. A
> > > > > further distinction is that the build of 'make_keys.c' is invoked by
> > > > > directly calling 'gcc', rather than invoking a 'make' in the instance
> > > > > when the header files are generated.
> > > > >
> > > > > # echo "********BUILD_CC= PATH=*******"
> > > > > # ********BUILD_CC= PATH=*******
> > > > > # echo gcc
> > > > > # gcc
> > > > > # echo
> > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/spoof:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/bin:/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin
> > > > > #
> > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/spoof:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/bin:/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin
> > > > > # gcc -o make_keys -DHAVE_CONFIG_H -I../ncurses -I.
> > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include -D_GNU_SOURCE
> > > > > -DNDEBUG -O2 ./tinfo/make_keys.c
> > > > > # AWK=mawk sh ./tinfo/MKkeys_list.sh ../include/Caps | sort
> > > > > >keys.list
> > > > > # ./make_keys keys.list > init_keytry.h
> > > > > # /bin/sh: ./make_keys: cannot execute binary file: Exec
> > > > > format error
> > > > > # make[1]: *** [Makefile:196: init_keytry.h] Error 126
> > > > >
> > > > > The effective changes are restricted to
> > > > > Eagle-Ltib/dist/lfs-5.1/ncurses/ncurses.spec, albeit with some
> > > > > additional debug. Temporary debug in the form of "echo" statements
> > > > > were also added to "ncurses/Makefile" and "include/Makefile". Echoing
> > > > > the PATH variable at various stages of ncurses build indicated that
> > > > > the cross-compiler gcc path set by Ltib i.e.
> > > > > "/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin",
> > > > > is being applied. The PATH variable remains constant before and
> > > > > after the ./configure, make clean and make stages (unless altered by
> > > > > the spec).
> > > > >
> > > > > The effective changes included:
> > > > > - Prepending the PATH variable with path to host gcc i.e. "export
> > > > > PATH=/usr/bin:$PATH", to ensure that the path to host gcc is "seen"
> > > > > before cross-compiler gcc path. The "with-build-cc=/usr/bin/gcc"
> > > > > setting is being overriden at this point when building 'make_keys'
> > > > > and is ineffective.
> > > >
> > > > that won't work (as you've seen). Earlier, you showed the ".spec"
> > > > file:
> > > >
> > > > pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto<mailto:pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto<mailto:pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto<mailto:pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto>>
> > > > :p<mailto:pgroves@pgroves-virtual-machine:~/workspace/RELEASE5301.or
> > > > ig$<mailto:p>
> > > > groves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto<mailto:groves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto<mailto:groves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto<mailto:groves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto>>:
> > > > groves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto:groves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto:groves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$<mailto:groves@pgroves-virtual-machine:~/workspace/RELEASE5301.orig$>>>>
> > > > cat
> > > > ./Eagle-Ltib/dist/lfs-5.1/bluez/bluez-5.65.spec
> > > >
> > > > which contains this chunk:
> > > >
> > > > ./configure --prefix=%{_prefix} --host=$CFGHOST --build=%{_build} \
> > > > --with-install-prefix=$RPM_BUILD_ROOT --mandir=%{_mandir} \
> > > > --with-shared --without-debug --without-cxx-binding \
> > > > --with-build-cc=gcc
> > > >
> > > > I'd change that last line to
> > > >
> > > > --with-build-cc=/usr/bin/gcc
> > > >
> > > > > - Adding a 'make clean' before 'make -j1 HOSTCC="$BUILDCC"' - this is
> > > > > to ensure that the header files in
> > > > > Eagle-Ltib/rpm/BUILD/ncurses-5.3/include/Makefile are always built
> > > > > and that no steps are missed, as has been observed in the previous
> > > > > build logs.
> > > > >
> > > > > The first change above resolves the 'make_keys' issue. Regardless as
> > > > > to whether a build of 'make_keys.c' was attempted using
> > > > > '/usr/bin/gcc' or just 'gcc' (a change to the Makefile.in itself),
> > > > > the cross-compiler gcc path was ultimetaly being used, until the PATH
> > > > > variable is prepended, a shown below.
> > > > >
> > > > > echo "********BUILD_CC= PATH=*******"
> > > > > ********BUILD_CC= PATH=*******
> > > > > echo /usr/bin/gcc
> > > > > /usr/bin/gcc
> > > > > echo
> > > > > /usr/bin:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/spoof:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/bin:/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin
> > > > >
> > > > > /usr/bin:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/spoof:/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/bin:/opt/freescale/ltib/usr/bin:/opt/miura/gcc-6.3.0-glibc-2.31-miura-2020.04/arm-miura-linux-gnueabi/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin
> > > > > /usr/bin/gcc -o make_keys -DHAVE_CONFIG_H -I../ncurses -I.
> > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include -D_GNU_SOURCE
> > > > > -DNDEBUG -O2 ./tinfo/make_keys.c
> > > > > AWK=mawk sh ./tinfo/MKkeys_list.sh ../include/Caps | sort
> > > > > >keys.list
> > > > > ./make_keys keys.list > init_keytry.h
> > > > > sh ./base/MKlib_gen.sh "gcc -E -DHAVE_CONFIG_H -I../ncurses -I.
> > > > > -I. -I../include -D_GNU_SOURCE -DNDEBUG" "mawk" generated
> > > > > <../include/curses.h >lib_gen.c
> > > > > mawk -f ./base/MKkeyname.awk keys.list > lib_keyname.c
> > > > > sh ./base/MKlib_gen.sh "gcc -E -DHAVE_CONFIG_H -I../ncurses -I.
> > > > > -I. -I../include -D_GNU_SOURCE -DNDEBUG" "mawk" implemented
> > > > > <../include/curses.h >link_test.c
> > > > > echo | mawk -f ./base/MKunctrl.awk >unctrl.c
> > > > >
> > > > > Kind Regards.
> > > > > Peter
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Thomas Dickey
> > > > > <dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto
> > > > > :dickey@his.com>>>
> > > > > Sent: 02 September 2024 22:00
> > > > > To: Peter Groves
> > > > > <pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:p
> > > > > groves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:groves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:groves@miurasystems.com<mailto:pgroves@miurasystems.com<mailto:groves@miurasystems.com<mailto:pgroves@miurasystems.com>>>>>;
> > > > > bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@>>
> > > > > gnu.org<mailto:bug-ncurses@gnu.org>>
> > > > > Cc: Thomas Dickey
> > > > > <dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mailto
> > > > > :dickey@his.com>>>
> > > > > Subject: Re: How do I resolve ncurses build error in source file
> > > > > generated by MKlib_gen.sh
> > > > >
> > > > > On Mon, Sep 02, 2024 at 04:54:59PM -0400, Thomas Dickey wrote:
> > > > > > On Mon, Sep 02, 2024 at 02:58:48PM +0000, Peter Groves wrote:
> > > > > > > Hi Thomas
> > > > > > >
> > > > > > > I seem to be cycling between the two error conditions i.e.
> > > > > > >
> > > > > > > * Perform a 'make clean'
> > > > > > > * ./make_keys: cannot execute binary file: Exec format error
> > > > > >
> > > > > > you would get "Exec format error" if make_keys were compiled
> > > > > > with the cross-compiler.
> > > > > >
> > > > > > (I'll take a look at the build-logs to see if I can spot a problem).
> > > > >
> > > > > The build-log shows that the cross- and build-compilers are "gcc".
> > > > >
> > > > > Perhaps the "gcc" that you would like to use for the build compiler
> > > > > is in a different directory, later in $PATH than the cross-compiler.
> > > > > To work around that, you will have to give the full pathname of the
> > > > > build-compiler, e.g., /usr/bin/gcc rather than just "gcc".
> > > > >
> > > > > > > * Build again: ../ncurses/comp_captab.c:74:19: error:
> > > > > > > '_nc_cap_table' undeclared
> > > > > > > Etc.
> > > > > > >
> > > > > > > Regards.
> > > > > > > Peter
> > > > > > >
> > > > > > > _____________________________________________
> > > > > > > From: Peter Groves
> > > > > > > Sent: 02 September 2024 14:39
> > > > > > > To:
> > > > > > > dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mai<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mai<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mai<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mai>>
> > > > > > > lt<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@h
> > > > > > > is.com<mailt>
> > > > > > > o:dickey@his.com>>
> > > > > > > Cc:
> > > > > > > bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncur<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncur<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncur<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncur>>
> > > > > > > se<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailt
> > > > > > > o:bug-ncurse>
> > > > > > > s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto:b<mailto:s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto:b<mailto:s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto:b<mailto:s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto:b>>
> > > > > > > ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org>>>>>;
> > > > > > > Peter Groves
> > > > > > > <pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mail
> > > > > > > to
> > > > > > > :pgroves@miurasystems.com<mailto:pgroves@miurasystems.com>>>
> > > > > > > Subject: RE: How do I resolve ncurses build error in source
> > > > > > > file generated by MKlib_gen.sh
> > > > > > >
> > > > > > >
> > > > > > > << File: build_020924_1150.tar.gz >>
> > > > > > >
> > > > > > > Hi Thomas
> > > > > > >
> > > > > > > Thank you for your reply.
> > > > > > >
> > > > > > > Yes, I compared the respective logfiles against the contents in
> > > > > > > "Eagle-Ltib/rpm/BUILD/ncurses-5.3/Makefile" and
> > > > > > > "Eagle-Ltib/rpm/BUILD/ncurses-5.3/include/Makefile", to identify
> > > > > > > whether my make files included the necessary steps.
> > > > > > > Following your suggestion, I ran a make clean and after
> > > > > > > rebuilding, these are now being executed (as indicated in green
> > > > > > > below).
> > > > > > > Unfortunately, I'm now encountering the same error encountered
> > > > > > > previously trying to run "make_keys" in
> > > > > > > "Eagle-Ltib/rpm/BUILD/ncurses-5.3/ncurses/Makefile":
> > > > > > >
> > > > > > > 195 init_keytry.h: make_keys$(BUILD_EXEEXT) keys.list
> > > > > > > 196 ./make_keys keys.list > $@
> > > > > > >
> > > > > > > I thought I had resolved this by setting "--with-build-cc=gcc"
> > > > > > > option in ./Eagle-Ltib/dist/lfs-5.1/ncurses/ncurses.spec, to
> > > > > > > force the host compiler rather than cross-compiling for the
> > > > > > > target, so I don't know why I'm seeing this issue again. I'm
> > > > > > > assuming the manual "make clean" took out the previous
> > > > > > > "init_keytry.h".
> > > > > > >
> > > > > > > Attached please find my latest tarred logfile
> > > > > > > "build_020924_1150.log".
> > > > > > >
> > > > > > > + make -j1 'HOSTCC=ccache /usr/bin/gcc -B/usr/bin/'
> > > > > > > cd man && make
> > > > > > > DESTDIR="/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/ncurses"
> > > > > > > all
> > > > > > > make[1]: Entering directory
> > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/man'
> > > > > > > sh ./MKterminfo.sh ./terminfo.head ./../include/Caps
> > > > > > > ./terminfo.tail >terminfo.5
> > > > > > > make[1]: Leaving directory
> > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/man'
> > > > > > > cd include && make
> > > > > > > DESTDIR="/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/ncurses"
> > > > > > > all
> > > > > > > make[1]: Entering directory
> > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/include'
> > > > > > > cat curses.head >curses.h
> > > > > > > AWK=mawk sh ./MKkey_defs.sh ./Caps >>curses.h
> > > > > > > sh -c 'if test "chtype" = "cchar_t" ; then cat
> > > > > > > ./curses.wide >>curses.h ; fi'
> > > > > > > cat ./curses.tail >>curses.h
> > > > > > > sh ./MKhashsize.sh ./Caps >hashsize.h
> > > > > > > AWK=mawk sh ./MKncurses_def.sh ./ncurses_defs >ncurses_def.h
> > > > > > > AWK=mawk sh ./MKparametrized.sh ./Caps >parametrized.h
> > > > > > > mawk -f MKterm.h.awk ./Caps > term.h
> > > > > > > sh ./edit_cfg.sh ../include/ncurses_cfg.h term.h
> > > > > > > ** edit: HAVE_TCGETATTR 1
> > > > > > > ** edit: HAVE_TERMIOS_H 1
> > > > > > > ** edit: HAVE_TERMIO_H 1
> > > > > > > ** edit: BROKEN_LINKER 0
> > > > > > > make[1]: Leaving directory
> > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/include'
> > > > > > > cd ncurses && make
> > > > > > > DESTDIR="/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/ncurses"
> > > > > > > all
> > > > > > > make[1]: Entering directory
> > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/ncurses'
> > > > > > > sh ./base/MKlib_gen.sh "gcc -E -DHAVE_CONFIG_H -I../ncurses
> > > > > > > -I. -I. -I../include -D_GNU_SOURCE -DNDEBUG" "mawk" generated
> > > > > > > <../include/curses.h | \
> > > > > > > fgrep undef >../include/nomacros.h
> > > > > > > mawk -f ./tinfo/MKnames.awk ./../include/Caps
> > > > > > > cat namehdr boolnames boolfnames numnames numfnames
> > > > > > > strnames strfnames nameftr >names.c
> > > > > > > cat namehdr boolcodes numcodes strcodes codeftr >codes.c
> > > > > > > rm -f namehdr nameftr codeftr boolnames boolfnames
> > > > > > > boolcodes numnames numfnames numcodes strnames strfnames strcodes
> > > > > > > gcc -o make_hash -DHAVE_CONFIG_H -I../ncurses -I.
> > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include -D_GNU_SOURCE
> > > > > > > -DNDEBUG -O2 -DMAIN_PROGRAM ./tinfo/comp_hash.c
> > > > > > > sh ./tinfo/MKcaptab.awk mawk ./../include/Caps >
> > > > > > > comp_captab.c
> > > > > > > ./tinfo/MKcaptab.awk: line 20: ./make_hash: cannot execute
> > > > > > > binary file: Exec format error
> > > > > > > ./tinfo/MKcaptab.awk: line 21: ./make_hash: cannot execute
> > > > > > > binary file: Exec format error
> > > > > > > sh ./tty/MKexpanded.sh "gcc -E" -DHAVE_CONFIG_H
> > > > > > > -I../ncurses -I. -I. -I../include -D_GNU_SOURCE -DNDEBUG >
> > > > > > > expanded.c
> > > > > > > sh ./tinfo/MKfallback.sh /usr/share/terminfo
> > > > > > > ../misc/terminfo.src >fallback.c
> > > > > > > gcc -o make_keys -DHAVE_CONFIG_H -I../ncurses -I.
> > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include -D_GNU_SOURCE
> > > > > > > -DNDEBUG -O2 ./tinfo/make_keys.c
> > > > > > > AWK=mawk sh ./tinfo/MKkeys_list.sh ../include/Caps | sort
> > > > > > > >keys.list
> > > > > > > ./make_keys keys.list > init_keytry.h
> > > > > > > /bin/sh: ./make_keys: cannot execute binary file: Exec
> > > > > > > format error
> > > > > > > make[1]: *** [Makefile:196: init_keytry.h] Error 126
> > > > > > > make[1]: Leaving directory
> > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/ncurses'
> > > > > > > make: *** [Makefile:96: all] Error 2
> > > > > > > error: Bad exit status from
> > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/rpm-tmp.
> > > > > > > 57
> > > > > > > 23
> > > > > > > 7 (%build)
> > > > > > >
> > > > > > > Regards.
> > > > > > > Peter
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Thomas Dickey
> > > > > > > <dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<ma
> > > > > > > il
> > > > > > > to:dickey@his.com>>>
> > > > > > > Sent: 31 August 2024 23:55
> > > > > > > To: Peter Groves
> > > > > > > <pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<mail
> > > > > > > to
> > > > > > > :pgroves@miurasystems.com<mailto:pgroves@miurasystems.com>>>
> > > > > > > Cc:
> > > > > > > dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mai<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mai<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mai<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<mai>>
> > > > > > > lt<mailto:dickey@his.com<mailto:dickey@his.com<mailto:dickey@h
> > > > > > > is.com<mailt>
> > > > > > > o:dickey@his.com>>;
> > > > > > > bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncur<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncur<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncur<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-ncur>>
> > > > > > > se<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailt
> > > > > > > o:bug-ncurse>
> > > > > > > s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto:b<mailto:s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto:b<mailto:s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto:b<mailto:s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto:b>>
> > > > > > > ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org>>>>>
> > > > > > > Subject: Re: How do I resolve ncurses build error in source
> > > > > > > file generated by MKlib_gen.sh
> > > > > > >
> > > > > > > On Fri, Aug 30, 2024 at 10:51:45AM +0000, Peter Groves wrote:
> > > > > > > > HI Thomas
> > > > > > > >
> > > > > > > > Thank you so much for your prompt response. Much appreciated.
> > > > > > > >
> > > > > > > > I should just mention that my build is on a VMWare Workstation
> > > > > > > > 16 Player. The host version of awk is GNU Awk 5.0.1, API: 2.0
> > > > > > > > (GNU MPFR 4.0.2, GNU MP 6.2.0).
> > > > > > > > I've included three logfiles,
> > > > > > > > - the first showing just the ncurses 5.3 package build error
> > > > > > > > i.e.
> > > > > > > > with "--disable-client" set in bluez-5.65.spec
> > > > > > > > - the second with "--disable-client" removed, such that the
> > > > > > > > logfile will also show the linker error for the bluez package
> > > > > > > > build.
> > > > > > > > - the third with ncurses package 6.5 (using 5.3 spec file to
> > > > > > > > begin with) - for some reason the "--with-build-cc=gcc" setting
> > > > > > > > that worked for 5.3 doesn't seem to work in this instance.
> > > > > > > > Looking at
> > > > > > > > https://invisible-island.net/ncurses/ncurses.faq.html#where_patches,
> > > > > > > > it doesn't seem as 6.5 requires any patches.
> > > > > > > >
> > > > > > > > checking for native build C compiler... gcc
> > > > > > > > checking for native build C preprocessor... ${BUILD_CC} -E
> > > > > > > > checking for native build C flags...
> > > > > > > > checking for native build C preprocessor-flags...
> > > > > > > > checking for native build linker-flags...
> > > > > > > > checking for native build linker-libraries...
> > > > > > > > checking if the build-compiler "gcc" works... no
> > > > > > > > configure: error: Cross-build requires two compilers.
> > > > > > > > Use --with-build-cc to specify the native compiler.
> > > > > > > > error: Bad exit status from
> > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/rpm-tmp.
> > > > > > > > 95
> > > > > > > > 026
> > > > > > > > (%build)
> > > > > > >
> > > > > > > something is missing in your build log - this chunk in my build:
> > > > > > >
> > > > > > > make[1]: Leaving directory '/tmp/ncurses-5.3/include'
> > > > > > > cd ncurses && make
> > > > > > > DESTDIR="/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/t
> > > > > > > mp /n cu rses" all /tmp/ncurses-5.3/ncurses
> > > > > > > make[1]: Entering directory '/tmp/ncurses-5.3/ncurses'
> > > > > > > sh ./base/MKlib_gen.sh "gcc -E -DHAVE_CONFIG_H -I../ncurses -I.
> > > > > > > -DNDEBUG -D_GNU_SOURCE -I. -I../include" "mawk" generated
> > > > > > > <../include/curses.h | \
> > > > > > > fgrep undef >../include/nomacros.h mawk -f
> > > > > > > ./tinfo/MKnames.awk ./../include/Caps cat namehdr boolnames
> > > > > > > boolfnames numnames numfnames strnames strfnames nameftr
> > > > > > > >names.c cat namehdr boolcodes numcodes strcodes codeftr
> > > > > > > >codes.c rm -f namehdr nameftr codeftr boolnames boolfnames
> > > > > > > boolcodes numnames numfnames numcodes strnames strfnames
> > > > > > > strcodes gcc -o make_hash -DHAVE_CONFIG_H -I../ncurses -I. -O2
> > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -DNDEBUG -D_GNU_SOURCE -I.
> > > > > > > -I../include -DMAIN_PROGRAM ./tinfo/comp_hash.c sh
> > > > > > > ./tinfo/MKcaptab.awk mawk ./../include/Caps
> > > > > > > > comp_captab.c sh ./tty/MKexpanded.sh "gcc -E"
> > > > > > > > -DHAVE_CONFIG_H
> > > > > > > -I../ncurses -I. -DNDEBUG -D_GNU_SOURCE -I. -I../include >
> > > > > > > expanded.c sh ./tinfo/MKfallback.sh /usr/share/terminfo
> > > > > > > ../misc/terminfo.src >fallback.c gcc -o make_keys
> > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -O2 -DHAVE_CONFIG_H
> > > > > > > -I../ncurses -I. -DNDEBUG -D_GNU_SOURCE -I. -I../include
> > > > > > > ./tinfo/make_keys.c AWK=mawk sh ./tinfo/MKkeys_list.sh
> > > > > > > ../include/Caps | sort >keys.list ./make_keys keys.list >
> > > > > > > init_keytry.h sh ./base/MKlib_gen.sh "gcc -E -DHAVE_CONFIG_H
> > > > > > > -I../ncurses -I. -DNDEBUG -D_GNU_SOURCE -I.
> > > > > > > -I../include" "mawk" generated <../include/curses.h >lib_gen.c
> > > > > > > mawk -f ./base/MKkeyname.awk keys.list > lib_keyname.c sh
> > > > > > > ./base/MKlib_gen.sh "gcc -E -DHAVE_CONFIG_H -I../ncurses -I.
> > > > > > > -DNDEBUG -D_GNU_SOURCE -I. -I../include" "mawk" implemented
> > > > > > > <../include/curses.h >link_test.c echo | mawk -f
> > > > > > > ./base/MKunctrl.awk
> > > > > > > >unctrl.c
> > > > > > >
> > > > > > > Presumably your build-tree is clean (if not, that's a problem),
> > > > > > > or the build is using parallel make (but I don't see a "make
> > > > > > > -j4", etc).
> > > > > > >
> > > > > > > >
> > > > > > > > Package extraction is not shown, as this would have occurred in
> > > > > > > > earlier logs. I hope this will assist with regard to the
> > > > > > > > ncurses build error.
> > > > > > > > Yes, the ncurses package is very old and would prefer to use
> > > > > > > > a later version of ncurses if I had more confidence in
> > > > > > > > generating an appropriate spec file.
> > > > > > > >
> > > > > > > > Kind Regards.
> > > > > > > > Peter
> > > > > > > >
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Thomas Dickey
> > > > > > > > <dickey@his.com<mailto:dickey@his.com<mailto:dickey@his.com<
> > > > > > > > ma
> > > > > > > > il
> > > > > > > > to:dickey@his.com>>>
> > > > > > > > Sent: 30 August 2024 01:31
> > > > > > > > To: Peter Groves
> > > > > > > > <pgroves@miurasystems.com<mailto:pgroves@miurasystems.com<ma
> > > > > > > > il
> > > > > > > > to
> > > > > > > > :pgroves@miurasystems.com<mailto:pgroves@miurasystems.com>>>
> > > > > > > > Cc:
> > > > > > > > bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-nc<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-nc<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-nc<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mailto:bug-nc>>
> > > > > > > > ur<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mai
> > > > > > > > lto:bug-ncur>
> > > > > > > > se<mailto:bug-ncurses@gnu.org<mailto:bug-ncurses@gnu.org<mai
> > > > > > > > lt
> > > > > > > > o:bug-ncurse>
> > > > > > > > s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto<mailto:s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto<mailto:s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto<mailto:s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.org<mailto>>
> > > > > > > > :b<mailto:s@gnu.org<mailto:bug-ncurses@gnu.org<mailto:s@gnu.
> > > > > > > > org<mailto:b>
> > > > > > > > ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org<mailto:ug-ncurses@gnu.org>>>>>>
> > > > > > > > Subject: Re: How do I resolve ncurses build error in source
> > > > > > > > file generated by MKlib_gen.sh
> > > > > > > >
> > > > > > > > On Thu, Aug 29, 2024 at 12:36:44PM +0000, Peter Groves wrote:
> > > > > > > > > Hi
> > > > > > > > >
> > > > > > > > > Stack Overflow issue "How do I resolve ncurses build error in
> > > > > > > > > source file generated by
> > > > > > > > > MKlib_gen.sh<https://stackoverflow.com/staging-ground/78924563>"
> > > > > > > > > refers.
> > > > > > > > >
> > > > > > > > > Thank you for your comment in directing me to your bug
> > > > > > > > > reporting portal - please pardon my hesitation in terms of
> > > > > > > > > not having used this option. I thought it might have seemed
> > > > > > > > > inappropriate as I believe the problem I am facing is
> > > > > > > > > probably of my own making rather than a bug associated with
> > > > > > > > > the ncurses software itself.
> > > > > > > > > Following your recommendation, I have therefore outlined
> > > > > > > > > the issue below, by including additional info which may be
> > > > > > > > > useful.
> > > > > > > > >
> > > > > > > > > Problem description
> > > > > > > > >
> > > > > > > > > I have been tasked with upgrading to bluez-5.65.tar.gz as
> > > > > > > > > part of a linux development build cross-compiled for a
> > > > > > > > > target arm-none-linux-gnueabi processor. The build system
> > > > > > > > > uses the opensource Freescale GNU/Linux Target Image Builder
> > > > > > > > > (LTIB) tool.
> > > > > > > > > The build was simplified initially by dropping 'readline'
> > > > > > > > > with the --disable-client option in the bluez spec file
> > > > > > > > > however this comes at a cost because 'bluetoothctl' is
> > > > > > > > > consequently also excluded.
> > > > > > > > > Reconfiguring to include 'readline' leads to dependencies
> > > > > > > > > on other packages and in particular a number of undefined
> > > > > > > > > references in the package bluez build (see attached), despite
> > > > > > > > > the readline package building successfully.
> > > > > > > > >
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib//libreadline.so:
> > > > > > > > > undefined reference to `tputs'
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib//libreadline.so:
> > > > > > > > > undefined reference to `tgoto'
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib//libreadline.so:
> > > > > > > > > undefined reference to `tgetflag'
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib//libreadline.so:
> > > > > > > > > undefined reference to `UP'
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib//libreadline.so:
> > > > > > > > > undefined reference to `tgetent'
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib//libreadline.so:
> > > > > > > > > undefined reference to `tgetnum'
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib//libreadline.so:
> > > > > > > > > undefined reference to `PC'
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib//libreadline.so:
> > > > > > > > > undefined reference to `tgetstr'
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib//libreadline.so:
> > > > > > > > > undefined reference to `BC'
> > > > > > > > > collect2: error: ld returned 1 exit status
> > > > > > > > > make[1]: *** [Makefile:5401: client/bluetoothctl] Error 1
> > > > > > > > > make[1]: *** Waiting for unfinished jobs....
> > > > > > > > >
> > > > > > > > > Some investigation revealed that libtinfo installed as
> > > > > > > > > part of ncurses could resolve this. A LTIB sample ncurses
> > > > > > > > > spec file is provided with reference to a very early
> > > > > > > > > version (see attached), namely, ncurses-5.3.tar.gz. This
> > > > > > > > > was downloaded from the ncurses website
> > > > > > > > > https://invisible-island.net/ncurses/ncurses.faq.html#othe
> > > > > > > > > r_ ve rs ions , along with the associated path file
> > > > > > > > > patch-5.3-5.4.sh.gz located here
> > > > > > > > > https://invisible-island.net/ncurses/ncurses.faq.html#where_patches.
> > > > > > > > > I was able to apply the patches successfully using the
> > > > > > > > > example provided on the website as a reference. It would
> > > > > > > > > doubtless be prudent to consider using a later version of
> > > > > > > > > ncurses except for the fact that I'm not very confident of
> > > > > > > > > deriving a corresponding spec file.
> > > > > > > >
> > > > > > > > ncurses 5.3 is more than 20 years old.
> > > > > > > >
> > > > > > > > Actually in a quick check, I can compile it on this
> > > > > > > > (Debian/oldstable) machine. Some versions of gcc won't do that
> > > > > > > > -- but that would be reflected in other parts of the build.
> > > > > > > >
> > > > > > > > > For the moment I have disabled PKG_LIBTERMCAP, though may
> > > > > > > > > need to revert this setting at some stage.
> > > > > > > >
> > > > > > > > The spec file (better, a pointer to where it can be inspected)
> > > > > > > > would help to see if that's needed.
> > > > > > > >
> > > > > > > > > config PKG_NCURSES
> > > > > > > > > #select PKG_LIBTERMCAP
> > > > > > > > > bool "ncurses"
> > > > > > > > > help
> > > > > > > > > The curses library routines are a terminal-independent
> > > > > > > > > method of
> > > > > > > > > updating character screens with reasonable
> > > > > > > > > optimization. The ncurses
> > > > > > > > > (new curses) library is a freely distributable
> > > > > > > > > replacement for the
> > > > > > > > > discontinued 4.4BSD classic curses library.
> > > > > > > > >
> > > > > > > > > The build for ncurses initially generated the following
> > > > > > > > > error, which I resolved by setting "--with-build-cc=gcc"
> > > > > > > > > in the ncurses spec file, to ensure that the 'make_keys'
> > > > > > > > > is compiled using the host compiler rather than being
> > > > > > > > > cross-compiled for the target. A similar issue was raised
> > > > > > > > > here:
> > > > > > > > > https://lists.gnu.org/archive/html/bug-ncurses/2002-10/msg00091.
> > > > > > > > > html
> > > > > > > > >
> > > > > > > > > gcc -o make_hash -DHAVE_CONFIG_H -I../ncurses -I.
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -DMAIN_PROGRAM
> > > > > > > > > ./tinfo/comp_hash.c sh ./tinfo/MKcaptab.awk mawk
> > > > > > > > > ./../include/Caps > comp_captab.c
> > > > > > > > > ./tinfo/MKcaptab.awk: line 20: ./make_hash: cannot execute
> > > > > > > > > binary
> > > > > > > > > file: Exec format error
> > > > > > > > > ./tinfo/MKcaptab.awk: line 21: ./make_hash: cannot execute
> > > > > > > > > binary
> > > > > > > > > file: Exec format error sh ./tty/MKexpanded.sh "gcc -E"
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG > expanded.c sh
> > > > > > > > > ./tinfo/MKfallback.sh /usr/share/terminfo
> > > > > > > > > ../misc/terminfo.src >fallback.c gcc -o make_keys
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -DHAVE_CONFIG_H
> > > > > > > > > -I../ncurses -I. -I. -I../include -D_GNU_SOURCE -DNDEBUG
> > > > > > > > > -O2 ./tinfo/make_keys.c AWK=mawk sh ./tinfo/MKkeys_list.sh
> > > > > > > > > ../include/Caps | sort >keys.list ./make_keys keys.list >
> > > > > > > > > init_keytry.h
> > > > > > > > > /bin/sh: ./make_keys: cannot execute binary file: Exec
> > > > > > > > > format error
> > > > > > > > > make[1]: *** [Makefile:196: init_keytry.h] Error 126
> > > > > > > > > make[1]: Leaving directory
> > > > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/ncurses'
> > > > > > > > > make: *** [Makefile:96: all] Error 2
> > > > > > > > > error: Bad exit status from
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/rpm-tmp.
> > > > > > > > > 6585
> > > > > > > > > 2
> > > > > > > > > (%build)
> > > > > > > > >
> > > > > > > > > The build for ncurses generates the following error (see
> > > > > > > > > attached) in the source file ../ncurses/comp_captab.c,
> > > > > > > > > which is in fact generated by the ncurses script MKlib_gen.sh.
> > > > > > > >
> > > > > > > > no - ncurses/tinfo/MKcaptab.sh - which uses awk.
> > > > > > > >
> > > > > > > > > + make -j1 'HOSTCC=ccache /usr/bin/gcc -B/usr/bin/'
> > > > > > > > > cd man && make
> > > > > > > > > DESTDIR="/home/pgroves/workspace/RELEASE5301.orig/Eagle-Lt
> > > > > > > > > ib
> > > > > > > > > /t
> > > > > > > > > mp
> > > > > > > > > /ncu
> > > > > > > > > rs
> > > > > > > > > es" all
> > > > > > > > > make[1]: Entering directory
> > > > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/man'
> > > > > > > > > sh ./MKterminfo.sh ./terminfo.head ./../include/Caps
> > > > > > > > > ./terminfo.tail
> > > > > > > > > >terminfo.5
> > > > > > > > > make[1]: Leaving directory
> > > > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/man'
> > > > > > > > > cd include && make
> > > > > > > > > DESTDIR="/home/pgroves/workspace/RELEASE5301.orig/Eagle-Lt
> > > > > > > > > ib
> > > > > > > > > /t
> > > > > > > > > mp
> > > > > > > > > /ncu
> > > > > > > > > rs
> > > > > > > > > es" all
> > > > > > > > > make[1]: Entering directory
> > > > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/include'
> > > > > > > > > cat curses.head >curses.h
> > > > > > > > > AWK=mawk sh ./MKkey_defs.sh ./Caps >>curses.h sh -c 'if test
> > > > > > > > > "chtype"
> > > > > > > > > = "cchar_t" ; then cat ./curses.wide >>curses.h ; fi'
> > > > > > > > > cat ./curses.tail >>curses.h mawk -f MKterm.h.awk ./Caps >
> > > > > > > > > term.h sh ./edit_cfg.sh ../include/ncurses_cfg.h term.h
> > > > > > > > > ** edit: HAVE_TCGETATTR 1
> > > > > > > > > ** edit: HAVE_TERMIOS_H 1
> > > > > > > > > ** edit: HAVE_TERMIO_H 1
> > > > > > > > > ** edit: BROKEN_LINKER 0
> > > > > > > > > make[1]: Leaving directory
> > > > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/include'
> > > > > > > > > cd ncurses && make
> > > > > > > > > DESTDIR="/home/pgroves/workspace/RELEASE5301.orig/Eagle-Lt
> > > > > > > > > ib
> > > > > > > > > /t
> > > > > > > > > mp
> > > > > > > > > /ncu
> > > > > > > > > rs
> > > > > > > > > es" all
> > > > > > > > > make[1]: Entering directory
> > > > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/ncurses'
> > > > > > > > > sh ./base/MKlib_gen.sh "gcc -E -DHAVE_CONFIG_H -I../ncurses
> > > > > > > > > -I. -I. -I../include -D_GNU_SOURCE -DNDEBUG" "mawk"
> > > > > > > > > generated <../include/curses.h | \
> > > > > > > > > fgrep undef >../include/nomacros.h sh
> > > > > > > > > ./base/MKlib_gen.sh "gcc -E -DHAVE_CONFIG_H -I../ncurses -I.
> > > > > > > > > -I. -I../include -D_GNU_SOURCE -DNDEBUG" "mawk" generated
> > > > > > > > > <../include/curses.h
> > > > > > > > > >lib_gen.c sh ./base/MKlib_gen.sh "gcc -E -DHAVE_CONFIG_H
> > > > > > > > > >-I../ncurses -I. -I.
> > > > > > > > > -I../include -D_GNU_SOURCE -DNDEBUG" "mawk" implemented
> > > > > > > > > <../include/curses.h >link_test.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./tty/hashmap.c cd ../obj_s; gcc -DHAVE_CONFIG_H
> > > > > > > > > -I../ncurses -I. -I.
> > > > > > > > > -I../include -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_beep.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I.
> > > > > > > > > -I../include -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_color.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_endwin.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_flash.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c ../ncurses/lib_gen.c
> > > > > > > > > cd ../obj_s; gcc -DHAVE_CONFIG_H -I../ncurses -I. -I.
> > > > > > > > > -I../include -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_getstr.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_mouse.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./tty/lib_mvcur.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_newterm.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_restart.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_screen.c
> > > > > > > > > ../ncurses/./base/lib_screen.c: In function 'getwin':
> > > > > > > > > ../ncurses/./base/lib_screen.c:48:5: warning: ignoring return
> > > > > > > > > value of 'fread', declared with attribute warn_unused_result
> > > > > > > > > [-Wunused-result]
> > > > > > > > > (void) fread(&tmp, sizeof(WINDOW), 1, filep);
> > > > > > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > > > > ../ncurses/./base/lib_screen.c:95:6: warning: ignoring return
> > > > > > > > > value of 'fread', declared with attribute warn_unused_result
> > > > > > > > > [-Wunused-result]
> > > > > > > > > (void) fread(nwin->_line[n].text,
> > > > > > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > > > > sizeof(NCURSES_CH_T),
> > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~
> > > > > > > > > (size_t) (nwin->_maxx + 1),
> > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > > > > filep);
> > > > > > > > > ~~~~~~
> > > > > > > > > cd ../obj_s; gcc -DHAVE_CONFIG_H -I../ncurses -I. -I.
> > > > > > > > > -I../include -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_set_term.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_slk.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_slkrefr.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./tty/lib_vidattr.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./tty/tty_update.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/lib_dft_fgbg.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./tinfo/lib_print.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/resizeterm.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./base/wresize.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./tinfo/alloc_entry.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/./tinfo/alloc_ttype.c cd ../obj_s; gcc
> > > > > > > > > -DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include
> > > > > > > > > -D_GNU_SOURCE -DNDEBUG -O2 -fPIC -c
> > > > > > > > > ../ncurses/comp_captab.c
> > > > > > > > > ../ncurses/comp_captab.c: In function '_nc_get_table':
> > > > > > > > > ../ncurses/comp_captab.c:74:19: error: '_nc_cap_table'
> > > > > > > > > undeclared (first use in this function)
> > > > > > > > > return termcap ? _nc_cap_table: _nc_info_table ;
> > > > > > > > > ^~~~~~~~~~~~~
> > > > > > > > > ../ncurses/comp_captab.c:74:19: note: each undeclared
> > > > > > > > > identifier is reported only once for each function it
> > > > > > > > > appears in
> > > > > > > > > ../ncurses/comp_captab.c:74:34: error: '_nc_info_table'
> > > > > > > > > undeclared (first use in this function)
> > > > > > > > > return termcap ? _nc_cap_table: _nc_info_table ;
> > > > > > > > > ^~~~~~~~~~~~~~
> > > > > > > >
> > > > > > > > The generated source should have those names. Perhaps your
> > > > > > > > build machine doesn't have awk (though that seems unlikely).
> > > > > > > > Attaching what I built just now for that, and lib_gen.c
> > > > > > > >
> > > > > > > > If I had the complete build logs, I might see the problem.
> > > > > > > > I prefer having a compressed tar file of the logs, as an
> > > > > > > > attachment.
> > > > > > > >
> > > > > > > > https://invisible-island.net/personal/bug-reports.html
> > > > > > > >
> > > > > > > > > make[1]: *** [Makefile:974: ../obj_s/comp_captab.o] Error
> > > > > > > > > 1
> > > > > > > > > make[1]: Leaving directory
> > > > > > > > > '/home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rpm/BUILD/ncurses-5.3/ncurses'
> > > > > > > > > make: *** [Makefile:96: all] Error 2
> > > > > > > > > error: Bad exit status from
> > > > > > > > > /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/tmp/rpm-tmp.
> > > > > > > > > 4877
> > > > > > > > > 0
> > > > > > > > > (%build) ` To summarize, I was expecting ncurses to build
> > > > > > > > > successfully, hopefully to resolve my linker error
> > > > > > > > > associated with the
> > > > > > > > > bluez-5.65 package. I wasn't expecting the build to fail for
> > > > > > > > > a file generated by the ncurses script.
> > > > > > > > > How may I resolve this issue please? I do anticipate
> > > > > > > > > further ncurses package dependencies that may still be
> > > > > > > > > required in order to ultimately generate a 'bluetoolctl'
> > > > > > > > > executable file.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Thomas E. Dickey
> > > > > > > > <dickey@invisible-island.net<mailto:dickey@invisible-island.
> > > > > > > > ne
> > > > > > > > t<
> > > > > > > > mailto:dickey@invisible-island.net<mailto:dickey@invisible-i
> > > > > > > > sl
> > > > > > > > an
> > > > > > > > d.net>>>
> > > > > > > > https://invisible-island.net
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Thomas E. Dickey
> > > > > > > <dickey@invisible-island.net<mailto:dickey@invisible-island.ne
> > > > > > > t<
> > > > > > > ma
> > > > > > > ilto:dickey@invisible-island.net<mailto:dickey@invisible-island.
> > > > > > > ne
> > > > > > > t>>>
> > > > > > > https://invisible-island.net
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Thomas E. Dickey
> > > > > > <dickey@invisible-island.net<mailto:dickey@invisible-island.net<
> > > > > > ma
> > > > > > ilto:dickey@invisible-island.net<mailto:dickey@invisible-island.
> > > > > > ne
> > > > > > t>>>
> > > > > > https://invisible-island.net
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thomas E. Dickey
> > > > > <dickey@invisible-island.net<mailto:dickey@invisible-island.net<ma
> > > > > il
> > > > > to:dickey@invisible-island.net<mailto:dickey@invisible-island.net>
> > > > > >>
> > > > > https://invisible-island.net
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Thomas E. Dickey
> > > > <dickey@invisible-island.net<mailto:dickey@invisible-island.net<mail
> > > > to:dickey@invisible-island.net<mailto:dickey@invisible-island.net>>>
> > > > https://invisible-island.net
> > > >
> > >
> > >
> > >
> > > --
> > > Thomas E. Dickey
> > > <dickey@invisible-island.net<mailto:dickey@invisible-island.net<mailto:dickey@invisible-island.net<mailto:dickey@invisible-island.net>>>
> > > https://invisible-island.net
> > >
> >
> > --
> > Thomas E. Dickey <dickey@invisible-island.net> https://invisible-island.net
> >
>
> --
> Thomas E. Dickey <dickey@invisible-island.net>
> https://invisible-island.net
>
--
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
signature.asc
Description: PGP signature
- Re: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, (continued)
- Re: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Thomas Dickey, 2024/09/02
- RE: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Peter Groves, 2024/09/03
- Re: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Thomas Dickey, 2024/09/03
- RE: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Peter Groves, 2024/09/04
- Re: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Thomas Dickey, 2024/09/05
- RE: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Peter Groves, 2024/09/06
- Re: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Thomas Dickey, 2024/09/07
- RE: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Peter Groves, 2024/09/09
- Re: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Thomas Dickey, 2024/09/09
- RE: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Peter Groves, 2024/09/11
- Re: How do I resolve ncurses build error in source file generated by MKlib_gen.sh,
Thomas Dickey <=
- RE: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Peter Groves, 2024/09/13
- Re: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Thomas Dickey, 2024/09/13
- RE: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Peter Groves, 2024/09/18
- RE: How do I resolve ncurses build error in source file generated by MKlib_gen.sh, Peter Groves, 2024/09/18