Unable to build using last Ubuntu LTS 18.04

[dabrain34]

I tried to build using the package MediaInfo_CLI_19.09_GNU_FromSource.tar.xz but unfortunately I was facing some issue with automake version. I guess you should call autogen.sh in some way instead of configure directly in your script CLI_Compile.sh
This autogen.sh will be something like:

#!/bin/sh

rm -rf autom4te.cache
rm -f aclocal.m4 ltmain.sh

autoreconf -f -i -v --warnings=all || exit 1

if [ -z "$NOCONFIGURE" ]; then
	./configure "$@"
fi

I have to say I'm a bit confused how to create a PR to address this issue, can you guide me where on how I should provide you the patch if you want it

[JeromeMartinez]

I guess you should call autogen.sh

Not possible, it must be possible to launch the script and compile without autotools installed.

Unable to build using last Ubuntu LTS 18.04

With autotools installed, right?

I have to say I'm a bit confused how to create a PR to address this issue,

You need to do 1 PR per project (ZenLib, MediaInfoLib, MediaInfo), but for the moment I guess the first thing is to find a way to resolve your issue without breaking the compilation when autotools are not installed.

[dabrain34]

I guess you should call autogen.sh

Not possible, it must be possible to launch the script and compile without autotools installed.

In which use case ?

Unable to build using last Ubuntu LTS 18.04

With autotools installed, right?

Yes automake-1.15 but resquested 1.13

I have to say I'm a bit confused how to create a PR to address this issue,

You need to do 1 PR per project (ZenLib, MediaInfoLib, MediaInfo), but for the moment I guess
the first thing is to find a way to resolve your issue without breaking the compilation when autotools are not installed.

I already fixed the build and I have been able to run mediainfo (which is a great tool BTW)
The best would be use either autotools with subprojects or even better to use another buildsystem such as meson or cmake.

[JeromeMartinez]

In which use case ?

The case autotools is not installed ;-).
This is important for us, else we would not provide compiled ./configure files (useless if you have autotools installed) in the "all in one" package.
When autotools is installed, we expect that each project is built from the real source (the one without ./configure files).

I already fixed the build and I have been able to run mediainfo

With the support when autotools is not installed?
We are interested in the patch in this case.

(which is a great tool BTW)

:)

The best would be use either autotools with subprojects or even better to use another buildsystem such as meson or cmake.

We already have CMake files for ZenLib and MediaInfoLib, we'll add a CMake file for MediaInfo itself soon. But it will not replace ./configure, for the moment we don't want to force the user to install another tool for being able to compile, even more on e.g. on macOS with Xcode installed through the Mac App Store (so compiler available but not CMake).

[dabrain34]

Maybe we could provide a way to at least be able to regenerate with an easy way all the generated files from autotools (Here you are penalizing the platform natively using autotools ;) MacOs is supporting very well autotools with homebrew)

[JeromeMartinez]

MacOs is supporting very well autotools with homebrew

Not every macOS developer use homebrew, we try to support as many people as possible.

Maybe we could provide a way to at least be able to regenerate with an easy way all the generated files from autotools

Maybe detecting if autotools are installed and regenerate in the scripts.
What I don't want is that a patch for fixing something we should fix creates a regression for other users not like you.

Can you propose a PR with a fix for your issue which has no impact on users not like you?

[dabrain34]

#398

[g-maxime]

I tested the latest MediaInfo release sources on Ubuntu 18.04 it's works.

The configure script tries to re-execute autotools if autogenerated files content or timestamp are modified.

A currupted archive or filesystem can cause this problem.

[dabrain34]

What is the last MediaInfo ?

I unzipped this archive MediaInfo_CLI_19.09_GNU_FromSource.tar.xzand ran ./CLI_Compile.sh

Here is why I get (previoulsy it was only with MediaInfo):

checking build system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
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... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C preprocessor... gcc -E
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... dlltool
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating libzen-config
config.status: creating libzen.pc
config.status: creating Makefile
config.status: executing depfiles commands
config.status: executing libtool commands

Configured ZenLib for 'x86_64-unknown-linux-gnu'

  Unicode?                                                yes
  Large files support?                                    yes
  wstring missing support?                                no
  stream missing support?                                 no

  Create static lib?                                      yes
  Create shared lib?                                      no

  CXXFLAGS: -g -O2 -DUNICODE -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -DSIZE_T_IS_LONG -fPIC -O2
  LIBS: 
 cd . && /bin/sh /home/scerveau/DEV/EXTERNAL/MediaInfo_CLI_GNU_FromSource/ZenLib/Project/GNU/Library/missing automake-1.13 --foreign
configure.ac:19: error: version mismatch.  This is Automake 1.15.1,
configure.ac:19: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:19: comes from Automake 1.13.4.  You should recreate
configure.ac:19: aclocal.m4 with aclocal and run automake again.
WARNING: 'automake-1.13' is probably too old.
         You should only need it if you modified 'Makefile.am' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'automake' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
Makefile:456: recipe for target 'Makefile.in' failed
make: *** [Makefile.in] Error 1
 cd . && /bin/sh /home/scerveau/DEV/EXTERNAL/MediaInfo_CLI_GNU_FromSource/ZenLib/Project/GNU/Library/missing automake-1.13 --foreign
configure.ac:19: error: version mismatch.  This is Automake 1.15.1,
configure.ac:19: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:19: comes from Automake 1.13.4.  You should recreate
configure.ac:19: aclocal.m4 with aclocal and run automake again.
WARNING: 'automake-1.13' is probably too old.
         You should only need it if you modified 'Makefile.am' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'automake' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
Makefile:456: recipe for target 'Makefile.in' failed
make: *** [Makefile.in] Error 1

[g-maxime]

I've tested the same archive.
Probably a corruption or file mtime problem (network or fat filesystem ?)

Your PR is going to be accepted as soon I solve the problem with macOS

[dabrain34]

I dont know what you mean by corrupted here. But I strongly recommend to review your build instructions.

Relying on generated configure is by experience a bad idea :)

[JeromeMartinez]

I dont know what you mean by corrupted here. But I strongly recommend to review your build instructions.

You may try with a clean VM with Ubuntu freshly installed.
Up to now we got lot of users relying of this build instruction.

Relying on generated configure is by experience a bad idea :)

Please stop with that, Autotools is especially built for that.
https://en.wikipedia.org/wiki/GNU_Autotools#Usage
"In most cases users simply run the supplied configure script (which has no dependencies other than the presence of a Bourne-compatible shell), and then a make program."

The "dependencies" part of the sentence is what I am looking for (and a problem with e.g. CMake).