I started looking at the differences between gettext-tools version 0.19.4 and 0.19.5.1 and noted potential culprit changes in :
- gettext-runtime/libasprintf/configure
- gettext-runtime/libasprintf/Makefile.in

Both those files have added references to LT_SYS_LIBRARY_PATH in various places.

This might be the cause of libtool picking up asprintf from the sys library path.

I am not sure how to proceed to fix or workaround this issue.

I am also wondering why no one else has this issue... ;)

Forgot to mention that the failure happens during "cerbero bootstrap" execution.

Duh...

It is not getttext-tools/gettext-runtime/libasprintf that fails to compile, but getttext-tools/gnulib-lib

Created attachment 312441 [details] [review]
windows: don't use mingw ansi stdio

This fixes the gettext-tools build failure on windows/mingw.

Can you explain why this is needed and what it does? :)

Well, I was happily compiling and coding with gstreamer 1.5.x with msys/mingw until gettext-tools version got bumped from version 0.19.4 to 0.19.5.1 (see http://cgit.freedesktop.org/gstreamer/cerbero/commit/?id=ff87925304c88f15e814f34bea010d5ecf5d5d71).

After that version bump, I started seeing the compilation error shown in first message in this bug report. The error happens when doing "cerbero bootstrap".

The duplicate definition comes from .\cerbero\mingw\w32\i686-w64-mingw32\include\stdio.h

Here is a relevant extract:

#if __USE_MINGW_ANSI_STDIO
/*
 * User has expressed a preference for C99 conformance...
 */

[SNIP]

static __attribute__ ((__unused__))
__attribute__ ((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull (1,2)))
int asprintf(char **__ret, const char *__format, ...)
{
  register int __retval;
  __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
  __retval = __mingw_vasprintf( __ret, __format, __local_argv );
  __builtin_va_end( __local_argv );
  return __retval;
}

[SNIP]

#endif /* __USE_MINGW_ANSI_STDIO */


Another relevant part is found in .\mingw\w32\i686-w64-mingw32\include\_mingw.h

#if defined(_POSIX) && !defined(__USE_MINGW_ANSI_STDIO)
/* Enable __USE_MINGW_ANSI_STDIO if _POSIX defined
 * and If user did _not_ specify it explicitly... */
#  define __USE_MINGW_ANSI_STDIO			1
#endif



Now I am not sure why the issue started but adding the patch addresses it.
With the patch I am able to run "cerbero bootstrap" and "cerbero package gstreamer-1.0" to completion.

I am not sure it is the best solution but it does the job...

Something that gets me wondering though is that there is another gettext recipe that is triggered when running "cerbero package gstreamer-1.0" which compiles the same version of gettext tool but without any errors.

To resume the patch forces the __USE_MINGW_ANSI_STDIO define to be set to 0.

This instructs mingw includes (stdio.h and others) to not define a bunch of symbols that gettext-tools defines itself.

But, again, I don't know why the duplicate symbols errors appeared all of the sudden.

The one built at bootstrap is used during building only, the one built during "package" is part of the resulting binaries.

It would be good to know why the latter builds just fine :)

Yes, knowing why the latter build fine would be good.

Knowing why I am, apparently, the only one getting this issue would be good too. I am the only one to build with msys/mingw ? ;)

There are some differences between the build-tools/gettext-tools.recipe and gettext.recipe but none that could explain, to my knowledge, why one succeeds to compile and not the other.

The gettext.recipe applies a patch that sounds related to the issue but adding the same to build-tools/gettext-tools.recipe did not make a difference.

I think I know why gettext compiles while gettext-tools does not.

gettext-tools.recipe will compile gettext/gettext-tools and by extension gettext/gettext-tools/gnulib-lib which has an asprintf.c file.

gettext.recipe will compile gettext/gettext-runtime and by extension gettext/gettext-runtime/gnulib-lib which has *not* an asprintf.c file.

Sorry to spam... to bad one cannot modify a comment...

But the difference between the two recipes that ...makes a difference... lies in the different value given to the srcdir property.

Could that dependency be the cause of our woes :

Platform.WINDOWS:  ['mingw-runtime']

Apparently gettext and gettext-tools are the only two recipes to have this dep.

Does it work without any other changes if you remove that dependency? Not sure why it is there

If you do tests, please do so from a "clean" setup. i.e. wipe --force --build-tools

Otherwise it might pick up stuff from previous builds.

I tested without the mingw-runtime dependency and got the same issue.
Seems that the dependency is not needed but removing it did not address the issue.

I'll try again with a wipe (and with and without my proposed fix).

Will report back later.

New test after a wipe confirms that removing the  mingw-runtime dependency does not address the issue.

I noticed that the configure step reports:

Running command './configure --prefix /D/dev/MinGW/msys/1.0/home/Philippe.Renon/cerbero/build-tools --libdir /D/dev/MinG
W/msys/1.0/home/Philippe.Renon/cerbero/build-tools/lib  --disable-java --disable-csharp --disable-native-java --without-
csv --enable-threads=win32 --disable-maintainer-mode  --disable-silent-rules  --disable-introspection  ne_cv_libsfor_get
hostbyname="-lws2_32" ac_cv_c_attribute_aligned="64" ac_cv_func_realloc_0_nonnull="yes" lt_cv_deplibs_check_method="pass
_all" am_cv_python_pyexecdir="D:/dev/MinGW/msys/1.0/home/Philippe.Renon/cerbero/build-tools/lib/python2.7/site-packages"
 ac_cv_lib_bz2_BZ2_bzlibVersion="yes" am_cv_python_version="2.7" ne_cv_libsfor_socket="-lws2_32" am_cv_python_platform="
win32" am_cv_python_pythondir="D:/dev/MinGW/msys/1.0/home/Philippe.Renon/cerbero/build-tools/lib/python2.7/site-packages
" ac_cv_func_malloc_0_nonnull="yes" --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32'
[SNIP]
checking for asprintf... no
[SNIP]

But compilation fails with:

libtool: compile:  i686-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\".exe\" -DEXEEXT=\".exe\" -DEXEEXT=\".exe\"
 -I. -I.. -I../intl -I../intl -I.. -I.. -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -DLIBXML_STATIC -DUSER_LABEL_PREFIX_UNDERSCORE -DGNULIB_DEFINED_ERROR -I./libcroco -I/D/dev/MinGW/msys/1.0/home/Philippe.Renon/cerbero/build-tools/include -Wall -g -O2 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -c asprintf.c  -DDLL_EXPORT -DPIC -o .libs/asprintf.o
asprintf.c:30:1: error: redefinition of 'asprintf'
In file included from ./stdio.h:43:0,
                 from asprintf.c:24:

There is no reference to /D/dev/MinGW/msys/1.0/home/Philippe.Renon/cerbero/build-tools/include when configuring but it shows up when compiling.

your not the only one having this problem. I am also having it. I have a clean installation in a virtual machine.

Thank Keith, good to know.

My last sentence in my last message is not relevant. Please ignore it.
I need sleep...

I also have the issue, trying to build gstreamer to cook my own patch to solve an issue.

Removing the mingw-runtime dependency and applying my patch works.

So it looks like this dependency is not need (but does not cause the issue).

mingw-runtime *is* needed. It copies some mingw libraries to the gstreamer dist dir.

Seems like this commit did what was suggested here : http://cgit.freedesktop.org/gstreamer/cerbero/commit/?id=6c8bf12e230778cc7bfd296ac7b5d29b3d5e0145

Not completely, it's only undefining that for this single file as for others it's beneficial to have. The gnulib configure macros are actually explicitly checking for the existence of this.

No problems... Just wanted to link to your fix.

Sure, I completely forgot about this bug actually :) It's good to have this tracked in Bugzilla in any case.

Created attachment 365770 [details] [review]
m4: Fix build issue on windows

m4 fails too for me. Exactly the same patch fixed it.

Xavier, the Clone button is hidden bottom right. Thread reason we want this is because we cannot set two versions in which it was fixed.