[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: |
Fri, 13 Sep 2024 19:15:14 -0400 |
On Fri, Sep 13, 2024 at 06:06:57PM +0000, Peter Groves wrote:
> HI Thomas
>
> I experimented with this however even if it splits into separate libraries,
> they are all packaged as part of the image so the overall size remains the
> same.
> * By not setting the --with-termlib option (default has it excluded,
> which is the same as setting --without-termlib), it provides: libformw.so.6,
> libmenuw.so.6, libncursesw.so.6 & libpanelw.so.6, where:
> 395288 Sep 13 12:17
> ./Eagle-Ltib/rpm/BUILD/ncurses-6.5/lib/libncursesw.so.6.5
> * Setting --with-termlib option, it provides libformw.so.6,
> libmenuw.so.6, libncursesw.so.6, libpanelw.so.6 & libtinfow.so.6, where:
> 238436 Sep 13 10:29 ./usr/lib/libncursesw.so.6.5
> 229800 Sep 13 10:29 ./usr/lib/libtinfow.so.6.5
> But the overall size of the image increases to 22751396 Sep 13 09:09
> M000-OS-VX-X.mlf.
>
> I when through the list of "disable" and "without" options listed by ncurses
> "./configure help" and the only settings that made a real difference in
> reducing the overall image size were the following:
> --disable-db-install
> --without-progs
> --disable-widec
> This reduced the size to 21047460 Sep 11 17:01 M000-OS-VX-X.mlf, which is
> just small enough to install on the target.
>
> The last setting i.e. "--disable-widec" caused a problem for the bluez
> package build.
> configure:4280: checking whether the C compiler works
> configure:4302: gcc conftest.c
> /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib/libncursesw.so.6.5
> >&5
> arm-miura-linux-gnueabi-gcc: error:
> /home/pgroves/workspace/RELEASE5301.orig/Eagle-Ltib/rootfs/usr/lib/libncursesw.so.6.5:
> No such file or directory
> configure:4306: $? = 1
> configure:4346: result: no
> This failure was down to the fact that the libraries provided by ncurses are
> compiled without wide character (and UTF-8 support): libform.so.6
> libmenu.so.6 libncurses.so.6 libpanel.so.6, so a difference libcurses library
> needs to be referenced by the bluez spec. The "bluetoothctl" executable is
> still generated.
>
>
> In your opinion, is it a good idea to disable these 3 options? I wouldn't be
> averse to reducing the size even further with other settings, if that's
> possible.
readline uses only the termcap functions, which are low-level,
and don't use wide-characters (--disable-widec). The programs
are useful if you're customizing the terminal database - which
you're probably not doing. But you need either the terminal
database (or a subset as suggested in the FAQ), or build the
libraries with fallback entries compiled-in.
For what readline needs, you could build a libtinfo with fallback
entries and have that as about 300kb. (I don't know why you would
need a 20Mb development image if you're only using the library to
support readline).
Looking at the (versioned) symbols needed by readline on my machine,
the list is short:
BC@NCURSES6_TINFO_5.0.19991023
PC@NCURSES6_TINFO_5.0.19991023
UP@NCURSES6_TINFO_5.0.19991023
tgetent@NCURSES6_TINFO_5.0.19991023
tgetflag@NCURSES6_TINFO_5.0.19991023
tgetnum@NCURSES6_TINFO_5.0.19991023
tgetstr@NCURSES6_TINFO_5.0.19991023
tgoto@NCURSES6_TINFO_5.0.19991023
tputs@NCURSES6_TINFO_5.0.19991023
That is, there are few symbols used, and they're provided in ncurses
for the past 25 years.
>
> Regards.
> Peter
>
> -----Original Message-----
> From: Thomas Dickey <dickey@his.com>
> Sent: 13 September 2024 00:47
> 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 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$<mailto: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$<mailto: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$<mailto: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<mailto:dickey@his.com>>
> > Sent: 10 September 2024 01:30
> > 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 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$<mailto: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<mailto:dickey@his.com<mailto:dickey@his.com>>>
> > > Sent: 07 September 2024 19:21
> > > 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 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<mailto: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<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 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<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<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<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<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<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<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<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<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<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<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<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<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$<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<mailto: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@<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@<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<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<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<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<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<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<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>>>>>>;
> > > > > > > > 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<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<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<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<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<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<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 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
>
--
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/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, 2024/09/12
- 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 <=
- 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