c++ dmalloc library versions not building for Rocko

c++ dmalloc library versions not building for Rocko

[forstevers]

[-- Attachment #1: Type: text/plain, Size: 1843 bytes --]

Trying to produce c++ versions of dmalloc libraries.The dmalloc recipe dmalloc_5.5.2.bb looks to be configured to build the c++ versions with:

'EXTRA_OECONF += "--enable-threads *--enable-cxx* --enable-shlib"'

But in the log.do_configure I see that the autoconf fails to find a c++ compiler, and I end up with the 'c' versions of the dmalloc library.

configure: configurations for the dmalloc library
configure: build utilities
checking for aarch64-xilinx-linux-gcc... aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
checking for aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether aarch64-xilinx-linux-g++  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
configure: *WARNING: could not find C++ compiler*

Any suggestions on how to get this recipe to build the requested c++ versions. Is there a dependency I can add in an append file to force it to recognize the compiler?

[-- Attachment #2: Type: text/html, Size: 1974 bytes --]

Re: [yocto] c++ dmalloc library versions not building for Rocko

[Khem Raj]

On Tue, Jul 20, 2021 at 8:25 AM forstevers via lists.yoctoproject.org
<steve=echodyne.com@lists.yoctoproject.org> wrote:
>
> Trying to produce c++ versions of dmalloc libraries.The dmalloc recipe dmalloc_5.5.2.bb looks to be configured to build the c++ versions with:
>
> 'EXTRA_OECONF += "--enable-threads --enable-cxx --enable-shlib"'
>
> But in the log.do_configure I see that the autoconf fails to find a c++ compiler, and I end up with the 'c' versions of the dmalloc library.
>
> configure: configurations for the dmalloc library
> configure: build utilities
> checking for aarch64-xilinx-linux-gcc... aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... yes
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
> checking for aarch64-xilinx-linux-gcc  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot option to accept ISO C89... none needed
> checking whether we are using the GNU C++ compiler... yes
> checking whether aarch64-xilinx-linux-g++  --sysroot=/extra_disk/home/ECHODYNE.INT/steve/projects/develop/jup-bsp/build/tmp/work/aarch64-xilinx-linux/dmalloc/5.5.2-r0/recipe-sysroot accepts -g... yes
> configure: WARNING: could not find C++ compiler
>
> Any suggestions on how to get this recipe to build the requested c++ versions. Is there a dependency I can add in an append file to force it to recognize the compiler?

there should be a config.log generated in this component's build
directory which should have more information on what check failed and
perhaps some more errors to tell what went wrong.

> 
>