it's signature indicates that it should - the callers just never use
the value currently, so it caused no harm
* squashed a TODO in the runtime_loader about the resolving strategy
for undefined symbols in add-ons: I've implemented the breadth-first
strategy (leaving out the add-on itself), as that one made most sense to
me.
This avoids loader problems with older optional packages of Pe on gcc4, as some
add-ons (e.g. "Expand Tabs") could not be loaded due to them containing undefined
symbols that are found in second level dependencies (libstdc++.so in this case).
Ingo: please review.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31465 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the default ABI for gcc2 builds should be B_HAIKU_ABI_GCC_2_HAIKU, not B_HAIKU_ABI_GCC_2, as the latter
is equal to B_HAIKU_ABI_GCC_2_ANCIENT and enforces the old symbol resolving behaviour.
If our build isn't ..._HAIKU, what is? ;-)
This fixes a whole lot of perl tests, which failed because the required shared libs could not be loaded
(as they contained undefined symbols that are only found in second level dependencies).
Note: the existing perl optional package works, since it does not contain any ABI specification symbol yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31464 a95241bf-73f2-0310-859d-f6bbb57e9c96
KPartition::CreateChild(). CreateChild() calls AddChild(), which publishes
the new partition, though at that point offset and size were not set, so that
the published devices would not be usable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31463 a95241bf-73f2-0310-859d-f6bbb57e9c96
keeps its own idea about what a wchar_t is and that was still a short.
This of course made the data structure of a streambuf incompatible with the
"lower" half - the glibc part - causing (potentially all sorts of) crashes
when these classes were used.
This should fix the crash of gensyscalls when building haiku natively
on a gcc2-haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31462 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added links to bug tracker and mailing list etiquettes. I don't think those
have to be available offline. Other opinions?
* Moved warning about the alpha status in welcome.html into a warning box.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31461 a95241bf-73f2-0310-859d-f6bbb57e9c96
offset as minimum and the maximum partition size as maximum value. It's now
the partition start and end offset.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31459 a95241bf-73f2-0310-859d-f6bbb57e9c96
* We can actually tell libavformat to discard packets for streams that
we are not interested in. Found this in the ffplay code. This should hopefully
avoid the efficiency impact of using one AVFormatContext per stream.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31458 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refactored NegotiateOutputFormat() and Decode() into two separate private
methods each, one for video and one for audio.
* Keep reading chunks when video decoding, until we have got a picture. This
gets us scrambled video instead of a black picture for h264 in mpegts.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31457 a95241bf-73f2-0310-859d-f6bbb57e9c96
context has AVPrograms. I gather this feature is for container streams
that contain multiple "groups of streams" like how it would work for
satilite mpeg-ts streams with multiple TV channels in one stream. For this
to be properly supported, we should extend the BMediaFile/Track API. For
now, the AVFormatReader uses the first program, if one is there. This
was also needed to get make mpegts demuxer work, but it is not yet enabled
for other reasons.
* Read more probe data. 1024 bytes were not enough to detect "mpegts" properly
for example.
* For now, I disabled the locking in the AVFormatReader hooks themselves,
this should not be necessary, though I hope libavformat is reentrant as
long as you have your own AVFormatContext for each thread. So far everything
hints that it is the case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31454 a95241bf-73f2-0310-859d-f6bbb57e9c96
we need to parse the "Unrecognized Type ..." strings we produce for partition
type IDs we can't match to a name. This fixes the "Failed to prepare
modifications" error the userland tools would produce when a partition with
such a type was encountered.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31453 a95241bf-73f2-0310-859d-f6bbb57e9c96
it (headers and library) from the image. The libiconv in our tree is
only used internally as a backend for libtextencoding. The real libiconv
is provided as an optional package.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31452 a95241bf-73f2-0310-859d-f6bbb57e9c96
* gcc-4.3.3 did contain too-far-stripped versions of static libraries, missing all symbols.
Now only the unneeded ones have been removed - fixing the build of the kernel on haiku natively
* libiconv was missing the shared versions of the libraries. I have updated the package to 1.13.1
and built it with shared libs (which took me considerable time to get right - the auto*-suite
basically sucks)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31450 a95241bf-73f2-0310-859d-f6bbb57e9c96
a good part of the source tree, so I rather get those changes into the
repository before continuing.
The general aim of the work is to deal with multiple instances of the same
function, e.g. inlined or non-inlined inline functions or those weird duplicates
gcc (4 at least) seems to be generating for no apparent reason.
* Added classes FunctionInstance (wrapping FunctionDebugInfo) and Function.
FunctionInstance represents a physical instance of a function (e.g. inlined
function at a particular address). A Function collects all FunctionInstances
referring to the same source code location.
* Moved the SourceCode property from FunctionDebugInfo to Function accordingly.
* Since SourceCode is no longer associated with a concrete function instance,
several methods dealing with statements have been removed and the
functionality has been provided through other means (e.g. TeamDebugModel or
SpecificImageDebugModel). This part is not yet completed.
* Introduced UserBreakpoint and UserBreakpointInstance. The user sets a
breakpoint at a source code location, which is represented by a
UserBreakpoint. Since that source location can be mapped to one address per
instance of the respective function, UserBreakpoint has a
UserBreakpointInstance per such function instance, which in turn refers to a
Breakpoint (an actual breakpoint at an address).
* Adjusted Breakpoint, BreakpointManager, and TeamDebugger accordingly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31447 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Move code between parent & children classes of the Accessors
- a bit Styling
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31446 a95241bf-73f2-0310-859d-f6bbb57e9c96
* SetBusy(): Use AddFlags() instead of SetFlags() so that the other flags
aren't cleared.
* AddChild(): Publish the newly added child partition. Otherwise no-one can do
anything with it without rebooting first. Other children may need to be
republished under a new name, if their index changes, which doesn't happen
yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31444 a95241bf-73f2-0310-859d-f6bbb57e9c96
the blanker. This is a regression introduced with r29488.
* This fixes bug #4069.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31441 a95241bf-73f2-0310-859d-f6bbb57e9c96
just architecture specific flags, call them just HAIKU_FFMPEG_DEFINES.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31432 a95241bf-73f2-0310-859d-f6bbb57e9c96
contents.html on every page.
* Added an index box to Queries, Tracker, Email prefs, workshop and Deskbar. If
anybody find another topic should get an index box, I'll add it.
* Little css tweak for the contents/index box.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31426 a95241bf-73f2-0310-859d-f6bbb57e9c96
how everything currently worked. (Packet peaking was only done once in Init().)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31423 a95241bf-73f2-0310-859d-f6bbb57e9c96
container formats we support. I hope I have turned on only those that don't
have an implementation already (did we support ASF already?). I mostly tested
with AVI and that works reasonably well, but I only tested raw audio so far.
However, the backend for Marcus' avi_reader is much nicer than FFmpeg, so I
think it should stay and have disabled the support for AVI in AVFormatReader.
A big disappointment is that MPG containers only give scrambled video. It may
be a problem of the AVCodecDecoder, but I am not so sure. After all, it works
fine for other container formats. If I am not mistaken, VLC also does not use
the mpeg demuxer from FFmpeg. :-\ On top of that, libavformat detects the
time_base and stream duration wrongly for one of my test MPGs.
As for the implementation: Although seeking in libavformat happens for an
individual stream, in reality, the packets for all other streams need to be
flushed (that's also what happens in the libavformat tutorials I've seen).
Since our MediaKit API allows to seek tracks indivually, this is of course
a no-go, since then all other tracks would be out of sync. My solution is to
simply open the demuxer once for each stream and then completely ignore the
packets of the respective other streams. This also works around the problem
that libavformat is unable to provide packets by stream, requiring the
API user to queue the packets that he needs not now, but later for other
streams. It also means we have to no memory copies, since we can directly
use the packet buffer until the next call to GetNextChunk().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31421 a95241bf-73f2-0310-859d-f6bbb57e9c96
multiple jobs. The problem was that the dummy targets used to compose the
scripts were independent from each other and jam could thus execute their
respective actions concurrently. We do now create a dependency chain between
the dummy targets of each script, so that jam is forced to execute the actions
sequentially.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31419 a95241bf-73f2-0310-859d-f6bbb57e9c96
Hope you don't mind, Ryan.
* Moved Stippi's tip about the context menu in I-O-M into the path section.
Hope you don't mind, Stephan.
* Linked to the Icon-O-Matic page where icons are discussed.
* Changed the index box at the top of I-O-M to use css and added the entries
into Haiku-doc.css.
I really don't know what I'm doing exactly here. Can someone have a look and
improve things? I'd soon like to add such an index box to other long topics.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31414 a95241bf-73f2-0310-859d-f6bbb57e9c96
Re-use the kernel emulation of the FS shell to implement a FUSE module
for BFS. In theory, it could use any Haiku file system implementation
just like the FS shell itself, but currently only the BFS code supports
being compiled as an FS shell module. The build target is <build>bfs_fuse
On Ubuntu, you would do this:
sudo apt-get install libfuse-dev
jam \<build\>bfs_fuse
mkdir path/to/moundPoint
path/to/bfs_fuse /dev/sdaX path/to/mountPoint
And that will mount your BFS volume at /dev/sdaX
read/write. As this is new code, you should be careful with your
data and expect potential data loss. Not that I don't trust Raghu's
code, but a warning is always better with such things. So far, my
tests have been successful and it is great to finally have write
support for BFS in Linux! Thanks a lot, Raghu, for your great work!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31409 a95241bf-73f2-0310-859d-f6bbb57e9c96
seemed odd to me. The default settings made it feel too slow in coming up, and
even the fastest settings still felt awkward. So after some trial and error I
came up with a reasonable default that feels nice to me.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31407 a95241bf-73f2-0310-859d-f6bbb57e9c96
