etc/CONFIGURE_FEDORA36.bash: ./configure: line 20598: 0: command not found

[sbarber2]

Summary: ./configure: line 20598: 0: command not found message appears when running etc/CONFIGURE_FEDORA36.bash

Impact: none known, just the message, as the script completes and subsequent makes/runs of bulk_extractor aren't obviously affected

Steps to create/configure the VM

(That said, the problem is reproducible at will just by re-running the CONFIGURE_FEDORA36.bash script on the VM, so not sure how much of the environmental setup is going to be relevant. VM setup steps are from memory, and may be out of order or may be some missing.)

Create a fresh Fedora 36 VM using Fedora-Everything-netinst-x86_64-36-1.5.iso on VirtualBox 7.0.6 (8GB RAM, 4 processors, 35GB disk) (from https://fedora.mirror.constant.com/fedora/linux/releases/36/Everything/x86_64/iso/) Become root Add user account sbarber as a sudoer following steps at https://www.server-world.info/en/note?os=Fedora_36&p=initial_conf&f=1 dnf -y update dnf -y install git dnf upgrade --refresh dnf -y group install "Basic Desktop" GNOME startx Login as sbarber, bring up Terminal, sudo bash

Steps to reproduce the error Follow the instructions in README.md to configure for Fedora 36:

git clone --recurse-submodules https://github.com/simsong/bulk_extractor.git 
$ cd bulk_extractor/etc
$ bash CONFIGURE_FEDORA36.bash 2>&1 | tee cfgfed36-2.log 

Observed output

[sbarber@fedora etc]$ cat cfgfed36-2.log | grep "command not found"
./configure: line 20598: 0: command not found

Expected/Desired output [sbarber@fedora etc]$ cat cfgfed36-2.log | grep "command not found"

See attached cfgfed36-2.log for stdout/stderr of the above config run

cfgfed36-2.log

[sbarber2]

Also note: Host machine is a Lenovo Yoga model 80Y7 running Microsoft Windows 10 Home version 10.0.19044 Build 19044. Intel Core i7-8550, 4 physical cores, 16GB RAM, samsung mzvlb512hajq-000L2 512MB SSD drive

[simsong]

This appears to be a problem in the libewf autoconf script. Here is the error from your output:

Now installing libewf into libewf-20140814
2023-04-03 14:18:34 URL:https://objects.githubusercontent.com/github-production-release-asset-2e65be/102821841/4a9d45d1-faab-4b4b-8e77-c4605f3922a8?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230403%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230403T181833Z&X-Amz-Expires=300&X-Amz-Signature=020373fc1fa9e4be0a3f67600bbf85792262e0fa8becbf956adbd0668e464aa5&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=102821841&response-content-disposition=attachment%3B%20filename%3Dlibewf-20140814.tar.gz&response-content-type=application%2Foctet-stream [2393406/2393406] -> "libewf-20140814.tar.gz" [1]
./configure: line 20598: 0: command not found
config.status: creating po/POTFILES
config.status: creating po/Makefile

Do you have the configure script that libewf created? It would be great if you could post lines 20890-20810. (use cat -n to get line numbers, I believe.)

@joachimmetz - are you familiar with this problem?

[joachimmetz]

Looks like:

     if 0; then
  HAVE_CXX11_TRUE=
  HAVE_CXX11_FALSE='#'
else 
  HAVE_CXX11_TRUE='#'
  HAVE_CXX11_FALSE=
fi  

presumably generated from AX_CXX_COMPILE_STDCXX_11(noext, optional)

maybe due to an older version of https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html during generation of configure

[simsong]

Well, that's from libewf, not from bulk_extractor. Here is the relevant code in BE:

https://github.com/simsong/bulk_extractor/blob/deddeb267a846b6ea9e1d1326562a55f614d71bc/configure.ac#L30-L48

[simsong]

Diagnosis: This is a libewf distribution problem, not a bulk_extractor problem. But it is not a big deal.

[joachimmetz]

Diagnosis: This is a libewf problem, not a bulk_extractor problem.

technically a distro problem, that is shipping older version of autoconf scripts

[simsong]

Correct. My apologies.

[sbarber2]

So, then, wouldn't a resolution of this issue from the point of view of the current bulk_extractor repository be to update the autoconf scripts to a later version explicitly in etc/CONFIGURE_FEDORA36.bash?

[simsong]

The issue is not the bulk_extractor autoconf script, but the version that is included with libewf. We are using the last stable version of libewf, with many bugfixes and patches. I suppose we could update the libewf script, but that does not seem necessary at the moment, and it might break other things. @joachimmetz is the one to make that decision.

[simsong]

We are using this version of libewf: https://github.com/libyal/libewf-legacy @joachimmetz has recommended it for bulk_extractor over this version: https://github.com/libyal/libewf

[sbarber2]

Ah. Understood. Thanks. Moving on . . . .

[joachimmetz]

the configure script of both libewf version are build with the same tool chain, this issue is caused by an outdated version of one of the m4 scripts (stdcxx11.m4) provided by the distro (namely #serial 3 where upstream seems to be on #serial 18).

@sbarber2 if you want to help, file an issue against Fedora to update this script.

[simsong]

I'm confused. I thought that the stdcxx11.m4 script used from the distro got used when the configure script was created, not when the script ran? However, is there even a reason to run stdcxx11.m4 at this point? For bulk_extractor I use these scripts, which I provide:

• https://github.com/simsong/bulk_extractor/blob/main/m4/ax_cxx_compile_stdcxx.m4
• https://github.com/simsong/bulk_extractor/blob/main/m4/ax_cxx_compile_stdcxx_17.m4

[joachimmetz]

However, is there even a reason to run stdcxx11.m4 at this point?

this libewf-legacy ewftools-mt that use it, it is not build by default and can be safely ignored. libewf experimental no longer provides these

[joachimmetz]

I thought that the stdcxx11.m4 script used from the distro got used when the configure script was created, not when the script ran?

that is correct, that by coincidence is also Fedora

[simsong]

Well, this is why bulk_extractor started including its own m4 macros.

[joachimmetz]

Correction: this file is actually included as third party macro in libewf, distro autotools doesn't provide it (did not realize this first since the rest of libyal does not use this). Updated the macro file.