Apparently gcc warns that GstMiniObject is not castable to
GstEvent/Message/Buffer due to them containing 64bit variables, even
though ARM hackers claim that those only need 4byte alignment. And as
long as gcc behaves that way, this warning is not very useful.
So we'll remove the warning until this problem is fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=615698
Check for ability to divide uint128_t values, since that what
we actually use it for (in gstutils.c). The existence of a
uint128_t type doesn't mean the compiler can actually generate
code for it. Also make sure that we can actually link the
result successfully.
Fixes bug #614767.
This is how we do it in the other modules, and gets rid of the annoying
dirty status for common when doing git status (at least once you clean
out the old files from there).
prctl is supposed to take 5 arguments. It used to work with 2 arguments on some
versions of libc because it is defined as a varags function there.
See #611911
It triggers for a lot of GStreamer API (even though those triggers are
wrong most of the time).
I missed it because it only triggers with -O2, and I was using -O0.
None of these flags cause warnings anymore, so no fixes necessary.
The flags are:
-Wformat-nonliteral
-Wformat-security
-Wold-style-definition
-Wcast-align
-Winline
-Winit-self
-Wmissing-include-dirs
-Waddress
-Waggregate-return
-Wno-multichar
-Wnested-externs
The alignment guaranteed by malloc is not always sufficient. E.g. vector
instructions or hardware subsystems want specifically aligned buffers. The
attached patch will use posix_memalign if available to allocate buffers.
The desired alignment can be set when running configure using the new
--with-buffer-alignment option.
This changes some APIs in compatible ways:
- Some functions now take "const char *" arguments, not "char *"
- Some structs now have "conts char *" members, not "char *"
The changes may cause warnings when compiling with the right warning
flags. You've been warned.
Also adds -Wwrite-strings as a warning flag in configure.ac.
https://bugzilla.gnome.org/show_bug.cgi?id=611692
Adds that warning to configure.ac
Includes a tiny change of the GST_BOILERPLATE_FULL() macro:
The get_type() function is no longer declared before being defined.
https://bugzilla.gnome.org/show_bug.cgi?id=611692
Add check to make sure gst-plugin-scanner really gets installed where
we will look for it later, ie. paths and prefixes are set at configure
time and not specified via make.
Fixes#609941.
We require threads to be supported in any case and defining this
will simplify the mutex, condition variable, etc. macros from gthread
to not always check if threads are really supported.
Fixes bug #607481.
Move SHAVE_INIT behind all other checks, in particular AG_GST_CHECK_CHECKS.
This should fix problems with header checking and checking for localtime_r,
which causes compilation errors with clean checkouts where common/shave has
not been created yet when those checks are run. It seems like SHAVE_INIT
changes the environment so that checks depending on a compiler need shave
to exist at that point, which will fail if AC_OUTPUT hasn't created it yet.
Fixes#605930.
and install into a different directory $(libexecdir/gstreamer-0.10) so that
everything is versioned properly.
NOTE: run 'make clean' after updating; if you are running an uninstalled setup,
you will need to update your gst-uninstalled script (unless it's symlinked
to gstreamer core master) and exit/enter your uninstalled environment to get
the updated environment. If you are running an installed setup, you should
run 'make uninstall' before merging this change or remove the old
plugin-scanner binary manually.
Fixes#601698.
Add a simple version check when starting the plugin-scanner so we can
verify we're talking to one that talks the same language.
First try a plugin-scanner in the installed path, then try one via the
GST_PLUGIN_SCANNER env var if that doesn't work.
Update the uninstalled script.
Install the plugin-scanner to the libexec dir
This is available in newer gcc releases and it should only exist
on platforms that provide some native 128bit integer arithmetic
instructions.
The x86-64 assembly for this is still kept for non-gcc compilers
that don't provide __uint128_t magic.
