for add-ons/libraries that don't have a signature. I threw our BAppFileInfo
code into libhaikucompat_build.a and link <build>mimeset and
<build>setversion against it, thus overriding the uncooperative BAppFileInfo
implementation in the host platform's libbe. Earlier or later we should use
libbe_build.so on BeOS compatible platforms as well, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21560 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also ported over the new MessageAdapter class
* Removed old BMessage implementation prototypes that apparently were left in the private folder
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21515 a95241bf-73f2-0310-859d-f6bbb57e9c96
-The biggest problem with linking host libraries (libbe_build and libroot_build) was not having the source files compiled with the -fPIC flag. As far as I can tell, we want to do this on all of the other host platforms as well, so hacked the jam files a bit to add it.
Forgive me if I've committed more Jamfile sins.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21423 a95241bf-73f2-0310-859d-f6bbb57e9c96
-fs_shell was using weak aliases, which is apparently not supported on the darwin toolchain
(or it's supported in some different way)
-remove building strl* routines for some of the host tools, since that already exists in libSystem
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21407 a95241bf-73f2-0310-859d-f6bbb57e9c96
xattrs. It can be enabled with the configure switch "--use-xattr". Note
that the amount of data stored in attributes may be limited by the used
file system -- e.g. AFAIK ext3 has a limit of one block (usually 4 KB)
for all attributes of a file, which might not suffice. XFS should be
fine, as should ReiserFS 3.6 (or any FS which stores attributes in
hidden files).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20609 a95241bf-73f2-0310-859d-f6bbb57e9c96
overwrite them with the host platform errno again. We do now track
changes and use a hopefully reasonable strategy for updating the host
errno.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20608 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Reorganized sources a bit:
- The descriptor support is in a separate file now.
- Disentangled the attribute support from the other stuff.
* Removed broken xattr use for attribute support.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20606 a95241bf-73f2-0310-859d-f6bbb57e9c96
again for target libbe_test. Added respective syscall stubs and other functions
to libhaikucompat.a.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20447 a95241bf-73f2-0310-859d-f6bbb57e9c96
It's hopefully now used everywhere instead of B_RAW_TYPE where appropriate.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19219 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Furthermore, this call crashes when called with a NULL version info
* Fixed some typos that should have proven problematic under R5/BONE.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19205 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_NAME_NOT_FOUND instead of B_ENTRY_NOT_FOUND for all missing types).
* Also, BMimeType::GuessMimeType() doesn't seem to work at all under BeOS.
* The build's MIME updater no longer ignores the error from DoMimeUpdate() - so that
you'll now may get error messages during the build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19202 a95241bf-73f2-0310-859d-f6bbb57e9c96
A consequence is the FileType tracker addon (which hasn't a signature) has now its attributes set on Linux builds
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17642 a95241bf-73f2-0310-859d-f6bbb57e9c96
of an object file, if the file's resources didn't specify supported
types. Both under Haiku itself and for the Linux build. This finally closes
bug 170 (AboutHaiku not being startable from Deskbar when built under
Linux).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17354 a95241bf-73f2-0310-859d-f6bbb57e9c96
read from (and the system version_info missing) GetVersionInfo() always
failed. Given that rc only writes the app version_info, mimeset never
created a BEOS:APP_VERSION attribute (nor ones for supported types icons).
The version attribute was usually created nevertheless, as a side effect
of the subsequent setversion invocation.
Under Linux the attribute emulation can accidentially pick up the
attributes of an earlier deleted node that had the the same node ID as the
file in question, which in this case could cause an invalid
BEOS:APP_VERSION attribute (the app version_info part at least).
Now GetVersionInfo() doesn't fail anymore, when only one info could be
read (the other one is zeroed). Not sure, if that is what BeOS does, but
it shouldn't harm. This fixes bug #100.
Also made SetVersionInfo() zero out what couldn't be read before writing it
back.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16320 a95241bf-73f2-0310-859d-f6bbb57e9c96
build platforms a bit. Generally extended attributes seem to be
supported up to a very limited size per node, thus a one-to-one
mapping isn't a good idea, but I figured, they could at least
help to recognize when and attribute directory doesn't belong to
a node (in case the original node had been removed and the a new
one created with the same node ID).
The implementation should ensure that, but I can't really test
it, since ReiserFS 3.6 under my SuSE Linux 9.2 installation
apparently doesn't support extended attributes. So it's disabled
for the time being.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16228 a95241bf-73f2-0310-859d-f6bbb57e9c96
Sorry, that was the problem actually reported by Alexander Deynichenko...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16216 a95241bf-73f2-0310-859d-f6bbb57e9c96
or resource to be read did not exist and the method was told to
allocate a buffer, it would try to allocate the buffer with an
uninitialized size value. This basically concerned SetSupportedTypes()
and methods using that one (IsSupportedType(), Supports()).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16131 a95241bf-73f2-0310-859d-f6bbb57e9c96
reported from our build tools under Linux. As it seems Linux does not
translate dirent::d_ino for mount points (BeOS and Haiku do), which
caused us not to find a mount point entry in its parent directory.
Thanks to Vampyre for the hint.
Fixes bugs #73 and #76.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15726 a95241bf-73f2-0310-859d-f6bbb57e9c96
be legal. This might even fix the bug that build tools like xres or
settype couldn't find an existing file under Linux (was never able to
reproduce that one, though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14900 a95241bf-73f2-0310-859d-f6bbb57e9c96
Library names are now mapped for all targets but "host" (not only for
"haiku") -- added one more level of indirection to achieve that.
(TARGET_LIBRARY_NAME_MAP -> *_LIBRARY_NAME_MAP_*).
* Renamed build/HaikuBuildCompatibility.h to BeOSBuildCompatibility.h
(auto-included when compiling something that uses the Be API for platform
"host" on anon-BeOS platform), and introduced build/HaikuBuildCompatibility.h,
which can be included when compiling something that can be built for both,
Haiku and BeOS compatible platforms.
* Introduced libhaikucompat.a, a library that adds a few functions existing
under Haiku, but not under BeOS.
* New rule AddSubDirSupportedPlatforms.
* Renamed libopenbeos.so to libbe_haiku.so.
* Introduced new target platform "libbe_test", which is basically equivalent
to a BeOS compatible host platform target, with the exception, that instead
of the host platform's libbe.so a special build of Haiku's libbe.so
(libbe_haiku.so (formerly known as libopenbeos.so)) is used. Furthermore
Haiku's public app, interface, storage, and support kit headers are used
when compiling. This replaces the less nice way in which the test app server
and applications for this test environment were built.
When building for platform "libbe_test", the library name "be" is
autotranslated to "libbe_haiku.so". Thus most applications don't need
special fiddling when them building them for the app server test environment;
usually an "AddSubDirSupportedPlatforms libbe_test ;" will suffice.
* Reduced the dependencies of <syscalls.h> and fixed problems caused by this
(e.g. source files not including the needed headers directly).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14749 a95241bf-73f2-0310-859d-f6bbb57e9c96
