Commit graph

23 commits

Author SHA1 Message Date
Thibault Saunier
ae608845ca meson: require meson 0.36 and use new pic arg on static libs
Removes a meson warning and some special casing we had.
2016-11-14 19:21:13 +00:00
Thibault Saunier
c0bfb1b524 Revert "meson: Use the new pic argument on static libs"
This reverts commit a5752240a1.

pic was added after 0.35 and will be present in 0.36 (meson
documentation was wrong).
2016-10-20 17:19:25 -03:00
Thibault Saunier
a5752240a1 meson: Use the new pic argument on static libs
We depend on meson 0.35 which makes it simpler to handle

Removes a meson warning
2016-10-20 16:04:42 -03:00
Tim-Philipp Müller
557e06a6f1 meson: fix internal printf for %ll format modifier on 32-bit systems
gst/gstprintf unit test would fail on 32-bit x86 with:
gstprintf.c:83:printf_I32_I64:0: 'str' (64-bit x value = b5a6978f) is not equal to '"64-bit x value = f1e2d3c4b5a6978f"'
2016-09-24 18:12:46 +01:00
Nirbheek Chauhan
b2f9808722 Add support for Meson as alternative/parallel build system
https://github.com/mesonbuild/meson

With contributions from:

Tim-Philipp Müller <tim@centricular.com>
Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)

Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded

... and many more. For more details see:

http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.html
http://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html

Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
2016-08-19 21:26:14 +01:00
Nirbheek Chauhan
55f9406f30 printf: On MSVC, also define HAVE_STDINT_H_WITH_UINTMAX
MSVC provides stdint.h but not inttypes.h, and we need to include stdint.h to
get intmax_t
2016-02-20 10:07:37 +00:00
Tim-Philipp Müller
6c394643be printf: fix invalid memory access in case of %%
https://bugzilla.gnome.org/show_bug.cgi?id=748414
2015-04-24 15:16:24 +01:00
Aurélien Zanelli
3da3e8df3e printf: handle unsigned modifier for long long
Otherwise, an unsigned integer will be displayed as a signed one if we
use internal print, ie HAVE_LONG_LONG_FORMAT is not defined.

https://bugzilla.gnome.org/show_bug.cgi?id=746096
2015-03-12 15:23:20 +00:00
Matej Knopp
b7f958abad printf: add support for %I32
https://bugzilla.gnome.org/show_bug.cgi?id=744281
2015-03-12 13:29:00 +00:00
Tim-Philipp Müller
e8a9f7acdf printf: fix handling of old printf extension specifiers for ABI compatibility
Fixes abort when the old specifiers are used. Fix up the conversion
specifier, it would get overwritten with 'c' below to the extension
format char, which then later is unhandled, leading to the abort.
Also fix up and enable unit test for this.

https://bugzilla.gnome.org/process_bug.cgi
2013-04-18 00:46:58 +01:00
Tim-Philipp Müller
109be629b7 printf: disable some unused printf variants 2013-04-14 11:33:41 +01:00
Tim-Philipp Müller
91c42b9380 printf: use sprintf() to work around glibc complaining about %n in a writable format string
Don't use snprintf(), but use sprintf instead and do our own
length calculations, because glibc may complain about us passing
%n in a format string if the string is in writable memory, and
here the format string is always in writable memory since we
construct it on the fly. This happens if glibc has been compiled
with _FORTIFY_SOURCE=2, which seems to be the case on some
distros/systems). On the upside, we now use the sprintf code path
on all systems which should be better from a maintenance point
of view.

https://bugzilla.gnome.org/show_bug.cgi?id=697970
2013-04-14 11:23:10 +01:00
Tim-Philipp Müller
5299a0cd65 printf: deal with some of the HAVE_FOO used in the printf code
Probably needs some more work for MSVC.
2013-04-12 23:05:59 +01:00
Tim-Philipp Müller
3c1d9c6d41 printf: fix alloca use for windows with mingw32
Don't use just GLIB_HAVE_ALLOCA_H to check if alloca is available,
that's just for the header. GLib may define alloca for us otherwise
too irrespective of GLIB_HAVE_ALLOCA_H.

Fixes compiler warning with mingw32:
gst/printf/vasnprintf.c:73:0: warning: "alloca" redefined
2013-04-12 23:05:58 +01:00
Tim-Philipp Müller
ff292d530c printf: enable and fix compiler warnings
But suppress -Wformat-nonliteral warnings since sprintf
is used with a runtime-generated format string in our
vasnprintf implementation.
2013-04-12 23:05:58 +01:00
Tim-Philipp Müller
97b3948a9f printf: fix up dodgy use of #if HAVE_FOO and #if !HAVE_FOO
Should use #ifdef and #ifndef.
2013-04-12 23:05:58 +01:00
Tim-Philipp Müller
79d6b91e27 printf: mark internal functions as internal 2013-04-12 23:05:57 +01:00
Tim-Philipp Müller
3778c1878c printf: skip pointer extension signifier chars after %p
So they don't get printed after the serialised pointer string.
2013-04-12 23:05:57 +01:00
Tim-Philipp Müller
6d8a6470d5 printf: don't leak serialised pointer extension strings 2013-04-12 23:05:57 +01:00
Tim-Philipp Müller
9a9b449c5f printf: handle old GST_PTR_FORMAT %P and GST_SEGMENT_FORMAT %Q defines too
For binary backwards compatibility.
2013-04-12 23:05:57 +01:00
Tim-Philipp Müller
5803da553c printf: make printf parser recognise our pointer extension format
and call the hook to get a string for the pointer instead.

https://bugzilla.gnome.org/show_bug.cgi?id=613081
2013-04-12 23:05:57 +01:00
Tim-Philipp Müller
fe7f7135e0 printf: add infrastructure for pointer extensions hook
Does not do anything yet. On a sidenote, we can't just use
%p\001 or so to signal the extension because g-i complains
about an invalid ascii character then, so have to resort to
something more elaborate, such as %p\aA etc.

https://bugzilla.gnome.org/show_bug.cgi?id=613081
2013-04-12 23:05:57 +01:00
Tim-Philipp Müller
8fc876f09f printf: add our own printf implementation for debug logging
We will add support for our own printf modifiers, so we can
get nice debug log output on all operating systems irrespective
of the specific libc version used.

https://bugzilla.gnome.org/show_bug.cgi?id=613081
2013-04-12 23:05:56 +01:00