* Ingo copied the methods into a shared location, and then obviously
"forgot" to let BFS use them. As a side note for Ingo: the complete
error GCC reported was "std::fssh_size_t" not defined with the macro
wrapper as code location. The actual problem was a "using std::size_t"
in some C++ header that accidentally got included after the wrapper.
* The shared Query code is not yet used. That'll be done another time.
* Renamed BFS_SHELL define to FS_SHELL, such that QueryParserUtils can be
used in any file system shell, not just the bfs_shell.
* When restoring shared attributes, don't affect CDDB:lookup status
* Volume renames should not affect CDDB:lookup status, only file renames should
This fixes some of the "cddb_daemon not updating CD info" problems.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
* Add ".wav" to the ends of filenames
* Add a track number at the beginning of the filename, e.g. "01"
* Don't hard-fail if the FreeDB response contains an invalid year
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
The workaround triggers the loading of all media plugins prior to using
methods of class BMediaFormats. Using the function get_next_encoder()
is used because of two facts
1. It is publicly available and thus can be used by 3rd party apps,
too.
2. It is already available by including BMediaFormats.h, so there is
no need to include another header for this workaround.
Signed-off-by: Colin Günther <coling@gmx.de>
(cherry picked from commit a89b0a4e69f18b2b3b2c2f5615450a5ddac838af)
The workaround triggers the loading of all media plugins prior to using
methods of class BMediaFormats. Using the function get_next_encoder()
is used because of two facts
1. It is publicly available and thus can be used by 3rd party apps,
too.
2. It is already available by including BMediaFormats.h, so there is
no need to include another header for this workaround.
Signed-off-by: Colin Günther <coling@gmx.de>
(cherry picked from commit 80354716fe8b25c81ec45bd96ae36e171228b8a0)
- Compiling dvb.media_addon with DEBUG on fails with error message:
generated/objects/haiku/x86/debug_1/add-ons/media/media-add-ons/dvb/
MediaFormat.o: In function `av_log2_c': /boot/home/Development/haiku-a4/
generated/build_packages/ffmpeg-0.10.2-r1a4-x86-gcc2-2012-08-30/common/
include/libavutil/common.h:80: undefined reference to `ff_log2_tab'
collect2: ld returned 1 exit status"
- Research done to narrow down the solution space:
- ff_log2_tab is a array that is nowhere needed in the dvb.media_addon
- ff_log2_tab is defined as an extern array in the ffmpeg header file
libavutil/common.h
- ff_log2_tab is used in the inline function av_log2_c (libavutil/common.h)
which doesn't get optimized away when compiling with debug information
- MediaFormat.cpp needs only some Codec-IDs from the ffmpeg header file
avcodec.h
- The following fixes were tried:
- Trying to eliminate unused debug symbols with compilation
flag -feliminate-unused-debug-types (see gcc documentation
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Debugging-Options.html#Debugging-Options)
by adding the following lines to UserBuildConfig
AppendToConfigVar C++FLAGS : HAIKU_TOP src : -feliminate-unused-debug-types : global ;
AppendToConfigVar CCFLAGS : HAIKU_TOP src : -feliminate-unused-debug-types : global ;
-> Failed, because flag -feliminate-unused-debug-types is not supported by GCC 2.95.3
- Trying to eliminate unused debug symbols in the linker stage
-> This worked, by removing the LINKFLAG "-Xlinker --no-undefined" when
linking all objects into the dvb.media_addon we are getting our addon
with debug symbols.
- Final solution:
- Instead of adding/removing flags, we just add the missing implementation
for the ff_log2_tab array in MediaFormat.cpp. This -feels- the seems to
be the cleanest solution as it is more obvious what's goin' on compared
to hiding the solution in the Jamfile.
Signed-off-by: Colin Günther <coling@gmx.de>
Make sure the compressed/uncompressed heap size and the chunk size
table look plausible, so we can rely on the values later. Fixes
potential crashes for corrupt packages.
* The number of IO vectors is not 256 on x86, but rather 224 as set by
NUM_IO_VECTORS in "arch_int.h".
* Jessicah mentioned hearing about MSI crashes before, but that was a
few weeks ago.
* These were the only CIDs in the MSI code.
Signed-off-by: Michael Lotz <mmlr@mlotz.ch>
- This test currently fails and thus showing that there is something wrong in
the Media Kit.
- This test was first developed and tested on Haiku R1 Alpha 4.1 where
every thing was hacked together to make this test succeed, thus showing that
the current Media Kit state of affair has some issues and not this test :)
- The test comes with documentation (@see mp3_decoder_test.cpp).
Signed-off-by: Colin Günther <coling@gmx.de>
- This test currently fails and thus showing that there is something wrong in
the Media Kit.
- This test was first developed and tested on Haiku R1 Alpha 4.1 where
every thing was hacked together to make this test succeed, thus showing that
the current Media Kit state of affair has some issues and not this test :)
- The test comes with documentation (@see mpeg2_decoder.test.cpp).
Signed-off-by: Colin Günther <coling@gmx.de>
* I tried having this test in KDiskDeviceManager.cpp, but it
failed booting in one case and did not solve the problem in another.
I think this is because there is an Open() call here, and that rereads
the blocksize.
* Tested and it solved the problem for me.
* Should fix#10717 and #9489 at least.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
* There was a version mismatch between HaikuPorts gcc_bootstrap recipe
and build/jam/repositories/HaikuPortsCross/arm which prevented
building @bootstrap-raw for ARM. Thanks Ingo for helping out!
* Ditto for ppc, x86, x86_64.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
* Building gcc-4.8.3 on x86_64 with TLS support fails with an internal
compiler error. Until that problem is fixed, don't use TLS on x86_64,
which (due to libstdc++ compatibility) requires the same for the
host cross compiler.
This needs to be run under haiku as it uses the package tool. It can be
used to remove the _bootstrap tagging from bootstrap packages and then
upload them to the repos as normal packages. The goal is to make
non-bootstrap builds work even for archs where the bootstrap isn't
working yet.
Packages built that way should be replaced as soon as better ones are
obtained by the proper bootstrapping process.
John Scipione