This link points to the mingw recipe for building flex: http://sourceforge.net/projects/mingw/files/MSYS/Extension/flex/flex-2.5.35-2/

Unfortunately I have not been able to build it myself.
For that reason and the fact that i am not really familiar with cerbero, I did not attempt to fix cerbero.

Made some progress: I was able to compile flex using the link given in last comment.
Not sure if this helps fixing the cerbero build system but it is a step forward ;)

Sebastian,
When building flex via cerbero, the first error I get is about a missing regex.h.
Apparently you already addressed that issue. Could you share that fix?

Ok, building flex the msys way is not very interesting as the resulting binaries will be dependent on msys-1.0.dll (which provides thin POSIX layer, including fork()...). Learning...

(In reply to Philippe Renon from comment #4)
> Ok, building flex the msys way is not very interesting as the resulting
> binaries will be dependent on msys-1.0.dll (which provides thin POSIX layer,
> including fork()...). Learning...

I think that's acceptable. It's only used as a build tool, not distributed in the binaries.

(In reply to Philippe Renon from comment #3)
> Sebastian,
> When building flex via cerbero, the first error I get is about a missing
> regex.h.
> Apparently you already addressed that issue. Could you share that fix?

There's a mingw-regex recipe in recipes/build-tools. That provides it, but you have to patch that into the flex build.

After adding mingw-regex as a dependency, flex compiled but fails at linking with:

libtool: link: i686-w64-mingw32-gcc -Wall -g -O2 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -o .libs/flex.exe ccl.o dfa.o ecs.o scanflags.o gen.o main.o misc.o nfa.o parse.o scan.o skel.o sym.o tblcmp.o yylex.o options.o scanopt.o buf.o tables.o tables_shared.o filter.o regex.o  -LD:/MinGW/msys/1.0/home/Utilisateur/cerbero/build-tools/lib lib/.libs/libcompat.a /D/MinGW/msys/1.0/home/Utilisateur/cerbero/build-tools/lib/libintl.dll.a -L/D/MinGW/msys/1.0/home/Utilisateur/cerbero/build-tools/lib /D/MinGW/msys/1.0/home/Utilisateur/cerbero/build-tools/lib/libiconv.dll.a
main.o: In function `flex_main':
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/main.c:168: undefined reference to `wait'
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/main.c:169: undefined reference to `WIFEXITED'
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/main.c:168: undefined reference to `wait'
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/main.c:170: undefined reference to `WEXITSTATUS'
tables.o: In function `yytbl_write32':
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/tables.c:289: undefined reference to `htonl'
tables.o: In function `yytbl_write16':
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/tables.c:308: undefined reference to `htons'
filter.o: In function `filter_apply_chain':
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/filter.c:159: undefined reference to `pipe'
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/filter.c:162: undefined reference to `fork'
filter.o: In function `filter_tee_header':
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/filter.c:332: undefined reference to `wait'
filter.o: In function `filter_fix_linedirs':
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/filter.c:416: undefined reference to `regexec'
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/filter.c:365: undefined reference to `regexec'
regex.o: In function `flex_regcomp':
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/regex.c:56: undefined reference to `regcomp'
D:\MinGW\msys\1.0\home\Utilisateur\cerbero\sources\build-tools\flex-2.5.39/regex.c:66: undefined reference to `regerror'

All these symbols are defined in ./MinGW/msys/1.0/lib/libmsys-1.0.dll.a.
How do I declare this lib and have its corresponding dll copyied to the distribution?

*** Bug 748757 has been marked as a duplicate of this bug. ***

I figured out how to add the msys-1.0 lib.

These are the changed line in flex.recipe:
    platform_deps = {Platform.WINDOWS: ['gettext', 'mingw-regex']}

    def prepare(self):
        if self.config.target_platform == Platform.WINDOWS:
            self.append_env['LDFLAGS'] = '-lmsys-1.0'

Now the configure step fails with:

Running command './configure --prefix /D/MinGW/msys/1.0/home/Utilisateur/cerbero/build-tools --libdir /D/MinGW/msys/1.0/
home/Utilisateur/cerbero/build-tools/lib  --disable-maintainer-mode  --disable-silent-rules  --disable-introspection  am
_cv_python_platform="win32" ne_cv_libsfor_gethostbyname="-lws2_32" ac_cv_c_attribute_aligned="64" ac_cv_func_realloc_0_n
onnull="yes" lt_cv_deplibs_check_method="pass_all" am_cv_python_pyexecdir="D:/MinGW/msys/1.0/home/Utilisateur/cerbero/bu
ild-tools/lib/python2.7/site-packages" ac_cv_lib_bz2_BZ2_bzlibVersion="yes" am_cv_python_version="2.7" ne_cv_libsfor_soc
ket="-lws2_32" am_cv_python_pythondir="D:/MinGW/msys/1.0/home/Utilisateur/cerbero/build-tools/lib/python2.7/site-package
s" ac_cv_func_malloc_0_nonnull="yes" --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32'
configure: WARNING: unrecognized options: --disable-maintainer-mode, --disable-introspection
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking whether NLS is requested... yes
checking for msgfmt... /usr/home/Utilisateur/cerbero/build-tools/bin/msgfmt
checking for gmsgfmt... /usr/home/Utilisateur/cerbero/build-tools/bin/msgfmt
checking for xgettext... /usr/home/Utilisateur/cerbero/build-tools/bin/xgettext
checking for msgmerge... /usr/home/Utilisateur/cerbero/build-tools/bin/msgmerge
checking for style of include used by make... GNU
checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc
checking whether the C compiler works... no
configure: error: in `/usr/home/Utilisateur/cerbero/sources/build-tools/flex-2.5.39':
configure: error: C compiler cannot create executables
See `config.log' for more details
Recipe 'flex' failed at the build step 'configure'

Please note that the "official" msys flex build requires the use of an MSYS shell. The msys flex build script will check for that and fail explicitly if a MINGW shell is used.
Flex needs to be built with the gcc that comes with MSYS and not the MINGW one.

Is that possible at all from cerbero?

Side question: is it possible to (monumentally) force cerbero to use a pre-built version of flex?
That would allow me to start testing the rest of the build...

You could just make sure it's in the PATH and remove flex from bootstrap.

I have been able to build master on windows. 

There are a issues with flex obviously but also bison.

m4.exe is also problematic. It keeps crashing. Up to twice per recipe.
I get a crash report popup each time but it does not stop the build and does not seem to have any impact on the build result. Strange...
But it is a real pain as you have to sit and wait for the popups during the whole build to let it continue. Takes ages on windows ;)

I am going to start the build with a fresh install of mingw/msys as the one I am using has been tweaked beyond recognition.

I'll do a more detailed report later.

What are the problems with m4 you see? I did a clean bootstrap and build now, everything seemed to work just fine except for flex and bison (for those I used the versions shipped by msys as a temporary solution).

m4 crashes on each invocation but without any noticeable effect on the build (as if crashing when exiting). The build proceeds and finishes as expected.
But it is a major pain as you need to baby sit the build and close all crash popups as they happen.

But again, I have tweaked my mingw/msys a lot by installing all sorts of additional modules.

On my system m4 is gotten from /bin and m4 --version yields:

$ m4 --version
m4 (GNU M4) 1.4.16
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Rene' Seindal.

I am not totally comfortable with cerbero and don't know what needs to be done from a regular shell and what needs to be done from the cerbero shell.

I'll try to find time next week to start the build from scratch with a clean mingw/msys install.

Quick question : 

I am supposed to use git://cgit.freedesktop.org/gstreamer/cerbero/
or git://cgit.freedesktop.org/gstreamer/sdk/cerbero/

I was using the former up to now...

The former is correct, and the latter is just a symlink :) Just don't use the gstreamer-sdk/cerbero one (- instead of /)

Strange, I used gstreamer/sdk/cerbero by mistake and bootstrap went fine.

I wiped everything out and switched to gstreamer/cerbero and bootstrap fails with :



WARNING: Using default configuration because D:/MinGW/msys/1.0/home/Utilisateur/.cerbero/cerbero.cbc is missing
WARNING: Could not recover status
Traceback (most recent call last):

+ Trace 235134

***** Error running 'bootstrap' command:
Fatal Error: Recipe flex has a unknown dependency mingw-gettext

I know how to fix it but is that expected?

m4 crashes are back...

Here is what I did:

1/ loosely followed http://docs.gstreamer.com/display/GstSDK/Building+from+source+using+Cerbero

Namely:
- installed Python 2.7, Git and Msys/MinGW
- installed the following Msys/MinGW Basic Setup packages : mingw-developper-toolkit,  mingw32-base, mingw32-gcc-g++, msys-base.
- setup path, etc...
- echo "alias cerbero='~/cerbero/cerbero-uninstalled'" >> ~/.bashrc
- and that's it...

2/ then did

git clone git://cgit.freedesktop.org/gstreamer/cerbero/
cd cerbero
cerbero bootstrap
cerbero package gstreamer-1.0

With those steps m4 keeps crashing but the build proceeds fine.

I tried to get rid of the crashes :
Both Msys and Git come with m4. Removing both m4 exes yields this :

[(4/87) libffi -> configure ]
Running command 'autoreconf -f -i'
autom4te: need GNU m4 1.4 or later: /bin/m4
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1
Recipe 'libffi' failed at the build step 'configure'

Looks like something is hardwired to /bin/m4 and ./cerbero/build-tools/bin/m4 is not used.

Please note that I did not create a cerbero.cbc file so cerbero is using the windows_7 defaults.

Are you guys using an old trusted build environment for which the "recipe" was lost or am I being a noob ?

The build later fails to compile gstfilesink.c because of 'undefined reference to `fsync''.
This issue was fixed for MSC but apparently not for MinGW. I worked around myself out of it.

Not sure, I was doing a clean build this weekend. Removed all of cerbero and the previous build, then ran bootstrap (after removing flex/bison) and package gstreamer-1.0. No problems with m4 at all here.


It might use /bin/m4 in some cases though, we should ideally fix those.


The fsync issue should be fixed now.

The m4 crashes went away... I interrupted and restarted the build several times and at some point m4 stopped crashing.

I'll need to investigate further...

I'll try to find where /bin/m4 comes from.

Hi Sebastian,

Could you share how you setup your MinGW/Msys environment.
I must be doing something wrong.

In addition to the m4.exe crashes, I also have issue with autoreconf.
Running autoreconf in any source directory yields:

Utilisateur@ASUS-SEVEN-PC ~/cerbero/sources/windows_x86/gst-plugins-ugly-1.0-1.5
$ autoreconf
configure.ac:1: error: Autoconf version 2.69 or higher is required
configure.ac:1: the top level
autom4te-2.68: /bin/m4 failed with exit status: 63
aclocal-1.11: /mingw/bin/autom4te-2.68 failed with exit status: 63
autoreconf-2.68: aclocal failed with exit status: 63

I believe it is due to having MinGW autoreconf present.

Utilisateur@ASUS-SEVEN-PC ~/cerbero/sources/windows_x86/gst-plugins-ugly-1.0-1.5
$ which autoreconf
/mingw/bin/autoreconf

Utilisateur@ASUS-SEVEN-PC ~/cerbero/sources/windows_x86/gst-plugins-ugly-1.0-1.5
$ autoreconf --version
autoreconf (GNU Autoconf) 2.68

Did a fresh install of MinGW/Msys again and this time only installed the packages that would allow cerbero to proceed after a failure.

Looks like it is ok now. m4 is not giving me trouble anymore and autoreconf is fine.

I still have a /bin/m4.exe which was installed as a dependency of flex (but cerbero does to seem to mind...).

Here are the installed packages:

$ mingw-get-info installed
mingw32-binutils-bin:
  Installed Version:  binutils-2.24-1-mingw32-bin.tar.xz
  Repository Version: binutils-2.24-1-mingw32-bin.tar.xz
mingw32-libgcc-dll:
  Installed Version:  libgcc-4.8.1-4-mingw32-dll-1.tar
  Repository Version: libgcc-4.8.1-4-mingw32-dll-1.tar
mingw32-libgmp-dll:
  Installed Version:  libgmp-5.1.2-1-mingw32-dll-10.tar
  Repository Version: libgmp-5.1.2-1-mingw32-dll-10.tar
mingw32-libiconv-dll:
  Installed Version:  libiconv-1.14-3-mingw32-dll-2.tar
  Repository Version: libiconv-1.14-3-mingw32-dll-2.tar
mingw32-libintl-dll:
  Installed Version:  libintl-0.18.3.2-1-mingw32-dll-8.tar.xz
  Repository Version: libintl-0.18.3.2-1-mingw32-dll-8.tar.xz
mingw32-libmpc-dll:
  Installed Version:  libmpc-1.0.1-2-mingw32-dll-3.tar
  Repository Version: libmpc-1.0.1-2-mingw32-dll-3.tar
mingw32-libmpfr-dll:
  Installed Version:  libmpfr-3.1.2-2-mingw32-dll-4.tar
  Repository Version: libmpfr-3.1.2-2-mingw32-dll-4.tar
mingw32-mingw-get-bin:
  Installed Version:  mingw-get-0.6.2-mingw32-beta-20131004-1-bin.tar.xz
  Repository Version: mingw-get-0.6.2-mingw32-beta-20131004-1-bin.tar.xz
mingw32-mingw-get-gui:
  Installed Version:  mingw-get-0.6.2-mingw32-beta-20131004-1-gui.tar.xz
  Repository Version: mingw-get-0.6.2-mingw32-beta-20131004-1-gui.tar.xz
mingw32-mingw-get-lic:
  Installed Version:  mingw-get-0.6.2-mingw32-beta-20131004-1-lic.tar.xz
  Repository Version: mingw-get-0.6.2-mingw32-beta-20131004-1-lic.tar.xz
msys-base-bin:
  Installed Version:  msys-base-2013072300-msys-bin.meta
  Repository Version: msys-base-2013072300-msys-bin.meta
msys-bash-bin:
  Installed Version:  bash-3.1.23-1-msys-1.0.18-bin.tar.xz
  Repository Version: bash-3.1.23-1-msys-1.0.18-bin.tar.xz
msys-bison-bin:
  Installed Version:  bison-2.4.2-1-msys-1.0.13-bin.tar.lzma
  Repository Version: bison-2.4.2-1-msys-1.0.13-bin.tar.lzma
msys-bzip2-bin:
  Installed Version:  bzip2-1.0.6-1-msys-1.0.17-bin.tar.lzma
  Repository Version: bzip2-1.0.6-1-msys-1.0.17-bin.tar.lzma
msys-core-bin:
  Installed Version:  msysCORE-1.0.18-1-msys-1.0.18-bin.tar.lzma
  Repository Version: msysCORE-1.0.18-1-msys-1.0.18-bin.tar.lzma
msys-core-doc:
  Installed Version:  msysCORE-1.0.18-1-msys-1.0.18-doc.tar.lzma
  Repository Version: msysCORE-1.0.18-1-msys-1.0.18-doc.tar.lzma
msys-core-ext:
  Installed Version:  msysCORE-1.0.18-1-msys-1.0.18-ext.tar.lzma
  Repository Version: msysCORE-1.0.18-1-msys-1.0.18-ext.tar.lzma
msys-core-lic:
  Installed Version:  msysCORE-1.0.18-1-msys-1.0.18-lic.tar.lzma
  Repository Version: msysCORE-1.0.18-1-msys-1.0.18-lic.tar.lzma
msys-coreutils-bin:
  Installed Version:  coreutils-5.97-3-msys-1.0.13-bin.tar.lzma
  Repository Version: coreutils-5.97-3-msys-1.0.13-bin.tar.lzma
msys-diffutils-bin:
  Installed Version:  diffutils-2.8.7.20071206cvs-3-msys-1.0.13-bin.tar.lzma
  Repository Version: diffutils-2.8.7.20071206cvs-3-msys-1.0.13-bin.tar.lzma
msys-dos2unix-bin:
  Installed Version:  dos2unix-7.2.2-1-msys-1.0.18-bin.tar.lzma
  Repository Version: dos2unix-7.2.2-1-msys-1.0.18-bin.tar.lzma
msys-file-bin:
  Installed Version:  file-5.04-1-msys-1.0.13-bin.tar.lzma
  Repository Version: file-5.04-1-msys-1.0.13-bin.tar.lzma
msys-findutils-bin:
  Installed Version:  findutils-4.4.2-2-msys-1.0.13-bin.tar.lzma
  Repository Version: findutils-4.4.2-2-msys-1.0.13-bin.tar.lzma
msys-flex-bin:
  Installed Version:  flex-2.5.35-2-msys-1.0.13-bin.tar.lzma
  Repository Version: flex-2.5.35-2-msys-1.0.13-bin.tar.lzma
msys-gawk-bin:
  Installed Version:  gawk-3.1.7-2-msys-1.0.13-bin.tar.lzma
  Repository Version: gawk-3.1.7-2-msys-1.0.13-bin.tar.lzma
msys-grep-bin:
  Installed Version:  grep-2.5.4-2-msys-1.0.13-bin.tar.lzma
  Repository Version: grep-2.5.4-2-msys-1.0.13-bin.tar.lzma
msys-gzip-bin:
  Installed Version:  gzip-1.3.12-2-msys-1.0.13-bin.tar.lzma
  Repository Version: gzip-1.3.12-2-msys-1.0.13-bin.tar.lzma
msys-less-bin:
  Installed Version:  less-436-2-msys-1.0.13-bin.tar.lzma
  Repository Version: less-436-2-msys-1.0.13-bin.tar.lzma
msys-libbz2-dll:
  Installed Version:  libbz2-1.0.6-1-msys-1.0.17-dll-1.tar.lzma
  Repository Version: libbz2-1.0.6-1-msys-1.0.17-dll-1.tar.lzma
msys-libcrypt-dll:
  Installed Version:  libcrypt-1.1_1-3-msys-1.0.13-dll-0.tar.lzma
  Repository Version: libcrypt-1.1_1-3-msys-1.0.13-dll-0.tar.lzma
msys-libexpat-dll:
  Installed Version:  libexpat-2.0.1-1-msys-1.0.13-dll-1.tar.lzma
  Repository Version: libexpat-2.0.1-1-msys-1.0.13-dll-1.tar.lzma
msys-libgdbm-dll:
  Installed Version:  libgdbm-1.8.3-3-msys-1.0.13-dll-3.tar.lzma
  Repository Version: libgdbm-1.8.3-3-msys-1.0.13-dll-3.tar.lzma
msys-libiconv-dll:
  Installed Version:  libiconv-1.14-1-msys-1.0.17-dll-2.tar.lzma
  Repository Version: libiconv-1.14-1-msys-1.0.17-dll-2.tar.lzma
msys-libintl-dll:
  Installed Version:  libintl-0.18.1.1-1-msys-1.0.17-dll-8.tar.lzma
  Repository Version: libintl-0.18.1.1-1-msys-1.0.17-dll-8.tar.lzma
msys-liblzma-dll:
  Installed Version:  liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma
  Repository Version: liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma
msys-libmagic-dll:
  Installed Version:  libmagic-5.04-1-msys-1.0.13-dll-1.tar.lzma
  Repository Version: libmagic-5.04-1-msys-1.0.13-dll-1.tar.lzma
msys-libopenssl-dll:
  Installed Version:  libopenssl-1.0.0-1-msys-1.0.13-dll-100.tar.lzma
  Repository Version: libopenssl-1.0.0-1-msys-1.0.13-dll-100.tar.lzma
msys-libregex-dll:
  Installed Version:  libregex-1.20090805-2-msys-1.0.13-dll-1.tar.lzma
  Repository Version: libregex-1.20090805-2-msys-1.0.13-dll-1.tar.lzma
msys-libtermcap-dll:
  Installed Version:  libtermcap-0.20050421_1-2-msys-1.0.13-dll-0.tar.lzma
  Repository Version: libtermcap-0.20050421_1-2-msys-1.0.13-dll-0.tar.lzma
msys-libxml2-dll:
  Installed Version:  libxml2-2.7.6-1-msys-1.0.13-dll-2.tar.lzma
  Repository Version: libxml2-2.7.6-1-msys-1.0.13-dll-2.tar.lzma
msys-m4-bin:
  Installed Version:  m4-1.4.16-2-msys-1.0.17-bin.tar.lzma
  Repository Version: m4-1.4.16-2-msys-1.0.17-bin.tar.lzma
msys-make-bin:
  Installed Version:  make-3.81-3-msys-1.0.13-bin.tar.lzma
  Repository Version: make-3.81-3-msys-1.0.13-bin.tar.lzma
msys-perl-bin:
  Installed Version:  perl-5.8.8-1-msys-1.0.17-bin.tar.lzma
  Repository Version: perl-5.8.8-1-msys-1.0.17-bin.tar.lzma
msys-perl-doc:
  Installed Version:  perl-5.8.8-1-msys-1.0.17-doc.tar.lzma
  Repository Version: perl-5.8.8-1-msys-1.0.17-doc.tar.lzma
msys-perl-html:
  Installed Version:  perl-5.8.8-1-msys-1.0.17-html.tar.lzma
  Repository Version: perl-5.8.8-1-msys-1.0.17-html.tar.lzma
msys-perl-lic:
  Installed Version:  perl-5.8.8-1-msys-1.0.17-lic.tar.lzma
  Repository Version: perl-5.8.8-1-msys-1.0.17-lic.tar.lzma
msys-perl-man:
  Installed Version:  perl-5.8.8-1-msys-1.0.17-man.tar.lzma
  Repository Version: perl-5.8.8-1-msys-1.0.17-man.tar.lzma
msys-sed-bin:
  Installed Version:  sed-4.2.1-2-msys-1.0.13-bin.tar.lzma
  Repository Version: sed-4.2.1-2-msys-1.0.13-bin.tar.lzma
msys-tar-bin:
  Installed Version:  tar-1.23-1-msys-1.0.13-bin.tar.lzma
  Repository Version: tar-1.23-1-msys-1.0.13-bin.tar.lzma
msys-termcap-bin:
  Installed Version:  termcap-0.20050421_1-2-msys-1.0.13-bin.tar.lzma
  Repository Version: termcap-0.20050421_1-2-msys-1.0.13-bin.tar.lzma
msys-texinfo-bin:
  Installed Version:  texinfo-4.13a-2-msys-1.0.13-bin.tar.lzma
  Repository Version: texinfo-4.13a-2-msys-1.0.13-bin.tar.lzma
msys-wget-bin:
  Installed Version:  wget-1.12-1-msys-1.0.13-bin.tar.lzma
  Repository Version: wget-1.12-1-msys-1.0.13-bin.tar.lzma
msys-wget-doc:
  Installed Version:  wget-1.12-1-msys-1.0.13-doc.tar.lzma
  Repository Version: wget-1.12-1-msys-1.0.13-doc.tar.lzma
msys-wget-lang:
  Installed Version:  wget-1.12-1-msys-1.0.13-lang.tar.lzma
  Repository Version: wget-1.12-1-msys-1.0.13-lang.tar.lzma
msys-wget-lic:
  Installed Version:  wget-1.12-1-msys-1.0.13-lic.tar.lzma
  Repository Version: wget-1.12-1-msys-1.0.13-lic.tar.lzma
msys-xz-bin:
  Installed Version:  xz-5.0.3-1-msys-1.0.17-bin.tar.lzma
  Repository Version: xz-5.0.3-1-msys-1.0.17-bin.tar.lzma
msys-zlib-dll:
  Installed Version:  zlib-1.2.7-1-msys-1.0.17-dll.tar.lzma
  Repository Version: zlib-1.2.7-1-msys-1.0.17-dll.tar.lzma

PS :
mingw-get-info is a script I got here : http://sourceforge.net/p/mingw/bugs/1525/

I'm probably running ancient versions of all this, I set up the mingw years ago and never updated it. I don't even have mingw-get-info :)


Are you running your commands from the cerbero shell and after running bootstrap? Or how did you call autoreconf when it failed?

I am using latest MinGW/Msys.

I tried to run autoreconf both from bash directly and from cerbero shell (after cerbero bootstrap...).
But it is sorted out now...
I was really careful to install only the minimum required set of MinGW/Msys packages. If you install autoconf and all then you run into problems.

The cerbero shell should make sure we only use our versions of autoconf and everything, it's setting environment variables for that. So that apparently does not work perfectly.


Can you write down what exactly you installed from mingw? Or even better update the README in cerbero accordingly and send a patch?

There is a bug in Windows with the shell command and you need to add the buildtools/bin path to PATH manually at the beginning of the PATH after entering the shell. Msys puts back /bin/ at the start of PATH when the new shell is spawned wich makes it use the wrong build tools from the shell.

I confirm the PATH bug:

$ echo $PATH
.:/usr/local/bin:/mingw/bin:/bin:/usr/home/Utilisateur/cerbero/build-tools/bin:/usr/home/Utilisateur/cerbero/dist/windows_x86/bin:/usr/home/Utilisateur/cerbero/mingw/w32/bin:/usr/home/Utilisateur/cerbero/mingw/w32/bin:.:/usr/local/bin:/ming
w/bin:/usr/bin:[SNIP]

I'll update the README for MinGW/Msys build environments.

Here is are the steps to get a windows build using MinGW/Msys.

First step was to install MinGW and the msys-base package.

Then I started the build process and addressed issues as they arose.

$ cerbero bootstrap

1/ [(2/15) gettext -> configure ]; Hangs when checking bison version
The bison version was the one coming with Git bash.
Note : any time an exe from git bash is found and used, the build hangs and a full CPU is just churning.

Solution : install msys-bison package with:
$ mingw-get install msys-bison
This also installed m4.

2/ [(3/15) libiconv -> compile ] : Fails with ar command not found

Solution : install msys-binutils with:
$ mingw-get install msys-binutils

3/ [(4/15) autoconf -> configure ] Hangs when checking for perl
Again perl was found in Git bash.

Solution : install msys-perl with :
$ mingw-get install msys-perl

4/ [(9/15) libtool -> compile ] m4 crashes 
That one is weird. It does not cause the build to fail but the crash popups need to be closed for the build to proceed.

Solution : rename or remove Git bash m4 (???)

cerbero bootstrap completes correctly...

$ cerbero package gstreamer-1.0

1/ [(8/87) gstreamer-1.0 -> configure ] Hangs when checking for flex
Again Git bash...

Solution  : install msys-flex package with:
$ mingw-get install msys-flex

cerbero package gstreamer-1.0 completes correctly

To resume:
- Install MinGW and msys-base
- Install msys-binutils msys-flex msys-bison msys-perl
- Remove Git bash m4.exe (???)

The need to remove m4.exe is really strange as cerbero should pick the one from msys...

This sounds like none of the cerbero versions of the tools are used, or did you forget bootstrap? Compiler and linker for example are the first thing installed by bootstrap.

I guess my last message was not clear enough...

My approach was to install a minimal MinGW/Msys and then proceed with "cerbero bootstrap" and "cerbero package gstreamer-1.0". The idea was to discover and address issue as they arose, with the goal to find out exactly which msys packages are needed.

This allowed me to discover that in addition to msys-base, the following msys packages are required : msys-binutils, msys-flex, msys-bison and msys-perl.
With those, both bootstrap and gstreamer-1.0 compile fine. 

Remains the really weird issue with git m4 being used. It is strange because msys m4 is also present (installed as a dependency of msys-bison/flex). And msys comes before git in PATH.

Note that "cerbero package gstreamer-1.0" is not done from a cerbero shell but from a regular bash.

msys-binutils, msys-flex, msys-bison shouldn't be required as bootstrap should give us those (well, flex fails which is the point of this bug). msys-perl is required indeed.

Yes, msys-flex/msys-bison are workaround to this bug.

msys-binutils was required to get ar.exe. I don't know if bootstrap is supposed to provide it, but bootstrap fails at step [(3/15) libiconv -> compile ] because it can't find it.

As the first step of bootstrap, a toolchain for Windows is downloaded that should contain ar.exe too :/

The downloaded toolchain was only partially used because ./mingw/w32/i686-w64-mingw32/bin is not added to the path.

I am attaching a patch that is addressing this issue.

Created attachment 306130 [details] [review]
Fix mingw path

Adds ./mingw/w32/i686-w64-mingw32/bin to the path

Created attachment 306131 [details] [review]
Disable flex and bison recipes and adds missing msys deps

Thanks, merged both:

commit a51c825241d32ab74aab980447561cf399399b9d
Author: Philippe Renon <philippe_renon@yahoo.fr>
Date:   Mon Aug 3 18:47:33 2015 +0300

    windows: Add host toolchain prefix to the PATH
    
    https://bugzilla.gnome.org/show_bug.cgi?id=745804

commit 05a4c32202798067146b8e9eb28fa66aef23898c
Author: Philippe Renon <philippe_renon@yahoo.fr>
Date:   Mon Aug 3 18:45:39 2015 +0300

    windows: Take flex/bison from msys until we can actually build our versions
    
    https://bugzilla.gnome.org/show_bug.cgi?id=745804



Let's keep this open until someone fixes the bison/flex build :)

> commit a51c825241d32ab74aab980447561cf399399b9d
> Author: Philippe Renon <philippe_renon@yahoo.fr>
> Date:   Mon Aug 3 18:47:33 2015 +0300
>
>    windows: Add host toolchain prefix to the PATH

This breaks the cross-build. You should only set the host path if you are running Windows has an host.

Freetype:
checking for x86_64-pc-linux-gnu-gcc... no
checking for gcc... gcc
checking for gcc... (cached) gcc
checking for suffix of native executables... gcc: error trying to exec 'cc1': execvp: No such file or directory
configure: error: native C compiler is not working
builds/unix/detect.mk:86: recipe for target 'setup' failed
make: *** [setup] Error 1

Created attachment 308753 [details] [review]
windows: Add host toolchain prefix to the PATH

Comment on attachment 308753 [details] [review]
windows: Add host toolchain prefix to the PATH

oops

Created attachment 308754 [details] [review]
windows: Don't append cross toolchain as host compiler

When cross-compiling for Windows, don't append 'gcc' to the PATH unless
we are running Windows platform. The appended 'gcc' is not a valid host
compiler and prevents building packages that need to compile generators
for the host platform (e.g. freetype).

Comment on attachment 308754 [details] [review]
windows: Don't append cross toolchain as host compiler

commit 4e6451099624febe6960e4551887ec25142b0bc2
Author: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Date:   Tue Aug 4 16:45:53 2015 -0400

    windows: Don't append cross toolchain as host compiler
    
    When cross-compiling for Windows, don't append 'gcc' to the PATH unless
    we are running Windows platform. The appended 'gcc' is not a valid host
    compiler and prevents building packages that need to compile generators
    for the host platform (e.g. freetype).
    
    https://bugzilla.gnome.org/show_bug.cgi?id=745804

This is not actually fixed. We use flex/bison from mingw instead of our own versions (and everywhere else we use our own versions)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/cerbero/issues/11.