Searched +hist:5 +hist:e19679e (Results 1 - 8 of 8) sorted by relevance

/haiku/src/bin/rc/
H A DJamfilediff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
diff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
/haiku/src/build/libroot/
H A Dfunction_remapper.cppdiff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
diff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
H A DJamfilediff 699b4bba Fri Dec 29 19:26:00 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> libroot_build: *Actually* fix attribute usage on Haiku.

To quote jscipione (from 95e8362c52af35a4012ca4d0facd62fb9856b619),
"Let me tell you a story about a bug" -- though this tale spans a much
lesser time than that one did.

In 5e19679ea35a79a26477c6215c7abba9bb7c4d00, I enabled libroot_build for
Haiku, instead of using the system libroot as we had before. There were
a number of bugs introduced along with this that I hadn't fixed (and there
may be more after this), but most of the obvious ones (crashes on x86_64...)
were fixed shortly enough.

Attribute usage, though, was a different story. Unlike most of the POSIX
calls in libroot, which were aliasing system functions no matter what the
platform, the attribute calls were not, as they are specific to Haiku.

Initially I had completely forgot about them, and it wasn't until a few days
later when I noticed that I had an "attributes" directory in my generated
that I realized that the "generic" attribute layer was being used on Haiku.
I attempted a fix for this in 5e19679ea35a79a26477c6215c7abba9bb7c4d00,
thinking that would clear the problem up, but I didn't actually run a test
beyond seeing that my BuildConfig had been updated properly. In fact,
BuildSetup was hard-wired to not even pass that definition through on
Haiku, and so that commit had in effect caused nothing.

My initial "fix" of just changing BuildSetup then caused a build failure,
as while libroot_build itself compiled, it ran into errors whenever attributes
were used, because in letting the real libroot's attribute calls shine
through, I had bypassed libroot_build's FD emulation/shim layer.

Then I tried and failed at three separate attempts to solve this with code:
- a version of the "fs_attr_...h" interface for Haiku. This proved possible
in theory, but in practice I would need to reimplement a lot of attribute
handling code in it, because all I had access to from there was syscalls.

- a version of "fs_attr_untyped" that bypassed its reimplementations of
the "fs*attr" functions for the libroot ones, only using the FD shim layer.
This proved possibly not even theoretically possible because it would have
caused preprocessor hell in some of the build headers, and also assumptions
about how attributes are read were totally different.

- a completely new "fs_attr_haiku" that was a completely new interface to
the fs*attr functions. This proved practically impossible because of the
need to include structures from the system libroot to call out to readdir,
etc. that attempts to solve would also have caused preprocessor hell.

Then I realized that the Linux xattr emulation library, which I'd used
as a reference when attempting the first solution, was shipped by default
as a system library in all builds of Haiku ... and so I could just tell
fs_attr_untyped to use the Linux xattr handler, and then link against libgnu.

So that is how I arrived at this strange and decidedly unorthodox solution
to a problem of my own creation.
diff 699b4bba Fri Dec 29 19:26:00 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> libroot_build: *Actually* fix attribute usage on Haiku.

To quote jscipione (from 95e8362c52af35a4012ca4d0facd62fb9856b619),
"Let me tell you a story about a bug" -- though this tale spans a much
lesser time than that one did.

In 5e19679ea35a79a26477c6215c7abba9bb7c4d00, I enabled libroot_build for
Haiku, instead of using the system libroot as we had before. There were
a number of bugs introduced along with this that I hadn't fixed (and there
may be more after this), but most of the obvious ones (crashes on x86_64...)
were fixed shortly enough.

Attribute usage, though, was a different story. Unlike most of the POSIX
calls in libroot, which were aliasing system functions no matter what the
platform, the attribute calls were not, as they are specific to Haiku.

Initially I had completely forgot about them, and it wasn't until a few days
later when I noticed that I had an "attributes" directory in my generated
that I realized that the "generic" attribute layer was being used on Haiku.
I attempted a fix for this in 5e19679ea35a79a26477c6215c7abba9bb7c4d00,
thinking that would clear the problem up, but I didn't actually run a test
beyond seeing that my BuildConfig had been updated properly. In fact,
BuildSetup was hard-wired to not even pass that definition through on
Haiku, and so that commit had in effect caused nothing.

My initial "fix" of just changing BuildSetup then caused a build failure,
as while libroot_build itself compiled, it ran into errors whenever attributes
were used, because in letting the real libroot's attribute calls shine
through, I had bypassed libroot_build's FD emulation/shim layer.

Then I tried and failed at three separate attempts to solve this with code:
- a version of the "fs_attr_...h" interface for Haiku. This proved possible
in theory, but in practice I would need to reimplement a lot of attribute
handling code in it, because all I had access to from there was syscalls.

- a version of "fs_attr_untyped" that bypassed its reimplementations of
the "fs*attr" functions for the libroot ones, only using the FD shim layer.
This proved possibly not even theoretically possible because it would have
caused preprocessor hell in some of the build headers, and also assumptions
about how attributes are read were totally different.

- a completely new "fs_attr_haiku" that was a completely new interface to
the fs*attr functions. This proved practically impossible because of the
need to include structures from the system libroot to call out to readdir,
etc. that attempts to solve would also have caused preprocessor hell.

Then I realized that the Linux xattr emulation library, which I'd used
as a reference when attempting the first solution, was shipped by default
as a system library in all builds of Haiku ... and so I could just tell
fs_attr_untyped to use the Linux xattr handler, and then link against libgnu.

So that is how I arrived at this strange and decidedly unorthodox solution
to a problem of my own creation.
diff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
diff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
/haiku/headers/build/os/support/
H A DErrors.hdiff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
diff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
/haiku/src/build/
H A DJamfilediff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
diff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
/haiku/src/tools/rc/
H A DJamfilediff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
diff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
/haiku/build/jam/
H A DMainBuildRulesdiff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
diff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
H A DBuildSetupdiff 5c93058a Sat Mar 30 14:55:27 MDT 2019 Augustin Cavalier <waddlesplash@gmail.com> BuildSetup: Stop defining __INTEL__ for the host tools.

Nothing in the tree uses __INTEL__ anymore, so this is no longer
needed.
diff 699b4bba Fri Dec 29 19:26:00 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> libroot_build: *Actually* fix attribute usage on Haiku.

To quote jscipione (from 95e8362c52af35a4012ca4d0facd62fb9856b619),
"Let me tell you a story about a bug" -- though this tale spans a much
lesser time than that one did.

In 5e19679ea35a79a26477c6215c7abba9bb7c4d00, I enabled libroot_build for
Haiku, instead of using the system libroot as we had before. There were
a number of bugs introduced along with this that I hadn't fixed (and there
may be more after this), but most of the obvious ones (crashes on x86_64...)
were fixed shortly enough.

Attribute usage, though, was a different story. Unlike most of the POSIX
calls in libroot, which were aliasing system functions no matter what the
platform, the attribute calls were not, as they are specific to Haiku.

Initially I had completely forgot about them, and it wasn't until a few days
later when I noticed that I had an "attributes" directory in my generated
that I realized that the "generic" attribute layer was being used on Haiku.
I attempted a fix for this in 5e19679ea35a79a26477c6215c7abba9bb7c4d00,
thinking that would clear the problem up, but I didn't actually run a test
beyond seeing that my BuildConfig had been updated properly. In fact,
BuildSetup was hard-wired to not even pass that definition through on
Haiku, and so that commit had in effect caused nothing.

My initial "fix" of just changing BuildSetup then caused a build failure,
as while libroot_build itself compiled, it ran into errors whenever attributes
were used, because in letting the real libroot's attribute calls shine
through, I had bypassed libroot_build's FD emulation/shim layer.

Then I tried and failed at three separate attempts to solve this with code:
- a version of the "fs_attr_...h" interface for Haiku. This proved possible
in theory, but in practice I would need to reimplement a lot of attribute
handling code in it, because all I had access to from there was syscalls.

- a version of "fs_attr_untyped" that bypassed its reimplementations of
the "fs*attr" functions for the libroot ones, only using the FD shim layer.
This proved possibly not even theoretically possible because it would have
caused preprocessor hell in some of the build headers, and also assumptions
about how attributes are read were totally different.

- a completely new "fs_attr_haiku" that was a completely new interface to
the fs*attr functions. This proved practically impossible because of the
need to include structures from the system libroot to call out to readdir,
etc. that attempts to solve would also have caused preprocessor hell.

Then I realized that the Linux xattr emulation library, which I'd used
as a reference when attempting the first solution, was shipped by default
as a system library in all builds of Haiku ... and so I could just tell
fs_attr_untyped to use the Linux xattr handler, and then link against libgnu.

So that is how I arrived at this strange and decidedly unorthodox solution
to a problem of my own creation.
diff 699b4bba Fri Dec 29 19:26:00 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> libroot_build: *Actually* fix attribute usage on Haiku.

To quote jscipione (from 95e8362c52af35a4012ca4d0facd62fb9856b619),
"Let me tell you a story about a bug" -- though this tale spans a much
lesser time than that one did.

In 5e19679ea35a79a26477c6215c7abba9bb7c4d00, I enabled libroot_build for
Haiku, instead of using the system libroot as we had before. There were
a number of bugs introduced along with this that I hadn't fixed (and there
may be more after this), but most of the obvious ones (crashes on x86_64...)
were fixed shortly enough.

Attribute usage, though, was a different story. Unlike most of the POSIX
calls in libroot, which were aliasing system functions no matter what the
platform, the attribute calls were not, as they are specific to Haiku.

Initially I had completely forgot about them, and it wasn't until a few days
later when I noticed that I had an "attributes" directory in my generated
that I realized that the "generic" attribute layer was being used on Haiku.
I attempted a fix for this in 5e19679ea35a79a26477c6215c7abba9bb7c4d00,
thinking that would clear the problem up, but I didn't actually run a test
beyond seeing that my BuildConfig had been updated properly. In fact,
BuildSetup was hard-wired to not even pass that definition through on
Haiku, and so that commit had in effect caused nothing.

My initial "fix" of just changing BuildSetup then caused a build failure,
as while libroot_build itself compiled, it ran into errors whenever attributes
were used, because in letting the real libroot's attribute calls shine
through, I had bypassed libroot_build's FD emulation/shim layer.

Then I tried and failed at three separate attempts to solve this with code:
- a version of the "fs_attr_...h" interface for Haiku. This proved possible
in theory, but in practice I would need to reimplement a lot of attribute
handling code in it, because all I had access to from there was syscalls.

- a version of "fs_attr_untyped" that bypassed its reimplementations of
the "fs*attr" functions for the libroot ones, only using the FD shim layer.
This proved possibly not even theoretically possible because it would have
caused preprocessor hell in some of the build headers, and also assumptions
about how attributes are read were totally different.

- a completely new "fs_attr_haiku" that was a completely new interface to
the fs*attr functions. This proved practically impossible because of the
need to include structures from the system libroot to call out to readdir,
etc. that attempts to solve would also have caused preprocessor hell.

Then I realized that the Linux xattr emulation library, which I'd used
as a reference when attempting the first solution, was shipped by default
as a system library in all builds of Haiku ... and so I could just tell
fs_attr_untyped to use the Linux xattr handler, and then link against libgnu.

So that is how I arrived at this strange and decidedly unorthodox solution
to a problem of my own creation.
diff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
diff 5e19679e Wed Dec 13 17:47:39 MST 2017 Augustin Cavalier <waddlesplash@gmail.com> build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).
diff 64d7ff77 Thu Jan 02 10:24:13 MST 2014 Alexander von Gluck IV <kallisti5@unixzen.com> BuildSetup: Refactor 5e97cd45cf to better detect b.e.

* Looking back, we should not assume little endian if
we see armv* as armv7l is little endian while armv7b
is big endian
diff 5e97cd45 Wed Jan 01 22:20:12 MST 2014 Alexander von Gluck IV <kallisti5@unixzen.com> BuildSetup: Add better arm host detection

* rather unlikely... unless you're insane like me
* BeagleBoard is armv7l-, so lets look for armv*
(I don't want to do arm* as it is less precise)
diff 5f4df83c Sun Nov 18 12:09:35 MST 2012 Alex Smith <alex@alex-smith.me.uk> Fixed ARM build.
diff 5abaa7eb Thu Aug 03 11:50:19 MDT 2006 Ingo Weinhold <ingo_weinhold@gmx.de> We do now include HaikuBuildCompatibility.h and link against libhaikucompat.a
automatically for all BeOS compatible target platforms but Haiku. This should
allow more Haiku code to build for BeOS.

Disclaimer: I couldn't really test it, since my BeOS working tree is switched
to my layout branch and under Linux I obviously can't test building for BeOS.
So, if you have complaints, keep them to yourself and just fix the problem.
;-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18372 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 64d7ff778b606794db4800ed950cc27c2d7012b0 Thu Jan 02 10:24:13 MST 2014 Alexander von Gluck IV <kallisti5@unixzen.com> BuildSetup: Refactor 5e97cd45cf to better detect b.e.

* Looking back, we should not assume little endian if
we see armv* as armv7l is little endian while armv7b
is big endian

Completed in 325 milliseconds