After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745804 - flex fails to build on Windows
flex fails to build on Windows
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: cerbero
git master
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 748757 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-03-07 16:01 UTC by Sebastian Dröge (slomo)
Modified: 2018-11-03 10:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix mingw path (1.12 KB, patch)
2015-06-25 19:56 UTC, Philippe Renon
committed Details | Review
Disable flex and bison recipes and adds missing msys deps (1.12 KB, patch)
2015-06-25 19:58 UTC, Philippe Renon
committed Details | Review
windows: Add host toolchain prefix to the PATH (1.49 KB, patch)
2015-08-04 20:48 UTC, Nicolas Dufresne (ndufresne)
none Details | Review
windows: Don't append cross toolchain as host compiler (1.61 KB, patch)
2015-08-04 20:50 UTC, Nicolas Dufresne (ndufresne)
committed Details | Review

Description Sebastian Dröge (slomo) 2015-03-07 16:01:05 UTC
This happens because
a) flex requires POSIX regex (i.e. regex.h), for that I already packaged the mingw standalone version of it. Needs to be integrated into the recipe for Windows but that's simple and works
b) flex uses various other POSIX API not available on Windows, like fork() and wait(). There must be compatibility implementations available somewhere as mingw ships flex binaries but I didn't find them yet and also not the build steps used to build the mingw flex binaries

Must be fixed before we can do a new release.
Comment 1 Philippe Renon 2015-05-31 23:16:20 UTC
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.
Comment 2 Philippe Renon 2015-06-01 08:02:00 UTC
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 ;)
Comment 3 Philippe Renon 2015-06-01 14:37:45 UTC
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?
Comment 4 Philippe Renon 2015-06-01 15:22:59 UTC
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...
Comment 5 Sebastian Dröge (slomo) 2015-06-01 16:05:04 UTC
(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.
Comment 6 Philippe Renon 2015-06-01 20:30:05 UTC
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?
Comment 7 Philippe Renon 2015-06-01 20:40:23 UTC
*** Bug 748757 has been marked as a duplicate of this bug. ***
Comment 8 Philippe Renon 2015-06-01 21:07:52 UTC
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?
Comment 9 Philippe Renon 2015-06-01 23:57:48 UTC
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...
Comment 10 Sebastian Dröge (slomo) 2015-06-02 06:49:56 UTC
You could just make sure it's in the PATH and remove flex from bootstrap.
Comment 11 Philippe Renon 2015-06-04 19:49:24 UTC
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.
Comment 12 Sebastian Dröge (slomo) 2015-06-07 18:04:49 UTC
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).
Comment 13 Philippe Renon 2015-06-07 18:30:53 UTC
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.
Comment 14 Philippe Renon 2015-06-08 18:52:54 UTC
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...
Comment 15 Sebastian Dröge (slomo) 2015-06-08 18:58:06 UTC
The former is correct, and the latter is just a symlink :) Just don't use the gstreamer-sdk/cerbero one (- instead of /)
Comment 16 Philippe Renon 2015-06-08 19:07:56 UTC
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):
  • File "D:/MinGW/msys/1.0/home/Utilisateur/cerbero\cerbero\main.py", line 105 in run_command
    res = commands.run(command, self.config, self.args)
  • File "D:/MinGW/msys/1.0/home/Utilisateur/cerbero\cerbero\commands\__init__.py", line 78 in run
    return _commands[command].run(config, args)
  • File "D:/MinGW/msys/1.0/home/Utilisateur/cerbero\cerbero\commands\bootstrap.py", line 38 in run
    bootstrapper.start()
  • File "D:/MinGW/msys/1.0/home/Utilisateur/cerbero\cerbero\bootstrap\build_tools.py", line 102 in start
    oven.start_cooking()
  • File "D:/MinGW/msys/1.0/home/Utilisateur/cerbero\cerbero\build\oven.py", line 87 in start_cooking
    recipes = self.cookbook.list_recipe_deps(recipe)
  • File "D:/MinGW/msys/1.0/home/Utilisateur/cerbero\cerbero\build\cookbook.py", line 259 in list_recipe_deps
    return self._find_deps(recipe, {}, [])
  • File "D:/MinGW/msys/1.0/home/Utilisateur/cerbero\cerbero\build\cookbook.py", line 314 in _find_deps
    % (recipe.name, recipe_name)))
FatalError: Fatal Error: Recipe flex has a unknown dependency mingw-gettext
***** Error running 'bootstrap' command:
Fatal Error: Recipe flex has a unknown dependency mingw-gettext

I know how to fix it but is that expected?
Comment 17 Philippe Renon 2015-06-08 22:34:35 UTC
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.
Comment 18 Sebastian Dröge (slomo) 2015-06-09 08:21:56 UTC
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.
Comment 19 Philippe Renon 2015-06-09 10:36:15 UTC
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.
Comment 20 Philippe Renon 2015-06-14 21:02:28 UTC
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
Comment 21 Philippe Renon 2015-06-15 06:57:14 UTC
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
Comment 22 Philippe Renon 2015-06-15 06:59:41 UTC
PS :
mingw-get-info is a script I got here : http://sourceforge.net/p/mingw/bugs/1525/
Comment 23 Sebastian Dröge (slomo) 2015-06-15 08:24:39 UTC
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?
Comment 24 Philippe Renon 2015-06-15 08:42:43 UTC
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.
Comment 25 Sebastian Dröge (slomo) 2015-06-15 09:00:04 UTC
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?
Comment 26 Andoni Morales 2015-06-15 10:58:29 UTC
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.
Comment 27 Philippe Renon 2015-06-18 00:21:21 UTC
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.
Comment 28 Philippe Renon 2015-06-21 21:20:06 UTC
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...
Comment 29 Sebastian Dröge (slomo) 2015-06-22 12:20:22 UTC
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.
Comment 30 Philippe Renon 2015-06-22 13:15:44 UTC
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.
Comment 31 Sebastian Dröge (slomo) 2015-06-22 13:21:15 UTC
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.
Comment 32 Philippe Renon 2015-06-22 16:38:24 UTC
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.
Comment 33 Sebastian Dröge (slomo) 2015-06-22 20:11:26 UTC
As the first step of bootstrap, a toolchain for Windows is downloaded that should contain ar.exe too :/
Comment 34 Philippe Renon 2015-06-25 19:54:08 UTC
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.
Comment 35 Philippe Renon 2015-06-25 19:56:24 UTC
Created attachment 306130 [details] [review]
Fix mingw path

Adds ./mingw/w32/i686-w64-mingw32/bin to the path
Comment 36 Philippe Renon 2015-06-25 19:58:29 UTC
Created attachment 306131 [details] [review]
Disable flex and bison recipes and adds missing msys deps
Comment 37 Sebastian Dröge (slomo) 2015-08-03 15:49:02 UTC
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 :)
Comment 38 Nicolas Dufresne (ndufresne) 2015-08-04 20:42:53 UTC
> 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
Comment 39 Nicolas Dufresne (ndufresne) 2015-08-04 20:48:03 UTC
Created attachment 308753 [details] [review]
windows: Add host toolchain prefix to the PATH
Comment 40 Nicolas Dufresne (ndufresne) 2015-08-04 20:49:57 UTC
Comment on attachment 308753 [details] [review]
windows: Add host toolchain prefix to the PATH

oops
Comment 41 Nicolas Dufresne (ndufresne) 2015-08-04 20:50:22 UTC
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 42 Nicolas Dufresne (ndufresne) 2015-08-04 20:50:40 UTC
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
Comment 43 Sebastian Dröge (slomo) 2018-05-05 13:13:30 UTC
This is not actually fixed. We use flex/bison from mingw instead of our own versions (and everywhere else we use our own versions)
Comment 44 GStreamer system administrator 2018-11-03 10:18:43 UTC
-- 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.