a while ago that removed the incorrect automatic addition of Haiku header
directories in case of targets other than "haiku". The app server test
environment does now almost build again. The problem left is related to the
recent changes of the accelerant interface. I suppose someone in the knows
should decide if we can simply use our header or if special handling is
needed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22630 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Unfortunately it's not allowed to set user xattrs on symlinks. So, if
we've failed in fs_write_attr() to set an extended attribute, we check
whether the node is a symlink and the attribute just a "BEOS:TYPE",
and pretend to have succeeded in this case. Thus we avoid annoying
error messages e.g. in unzip.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22183 a95241bf-73f2-0310-859d-f6bbb57e9c96
symlinks to be not openable.
* When _kern_open() created a new file, invalid stat data were accessed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22176 a95241bf-73f2-0310-859d-f6bbb57e9c96
to be problematic.
* Changed our xattr attribute namespace to "user.haiku." to prevent
xattrs from other programs (e.g. Beagle) to end up on the image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22167 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
