[haiku-commits] Re: haiku: hrev46660 - build/jam src/system/libroot/posix/glibc/stdio-common

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 16 Jan 2014 11:22:41 +0100

On 01/15/2014 04:46 PM, Jonathan Schleifer wrote:
Am 15.01.2014 um 11:49 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:

I had a closer look at the clang setup and I think before continuing with the 
jam part of the build system, the first step should be to set up a clang cross 
compilation environment that no longer depends on gcc.

This is unfortunately not possible yet, I guess. Clang uses gcc as assembler 
and linker. We can force Clang to use its own assembler using -integrated-as. I 
already force the integrated assembler, as Clang currently blindly passes all 
-f flags to the assembler as well, making it fail at flags like 
-fheinous-gnu-extensions as GCC does not know them. However, that keeps the 
linker. So, unless we change linking to using ld directly, we're stuck with 
having a dependency on GCC 4.x for Clang.
>
This is unfortunate, but fixable in Clang itself. But that also means we need 
to wait until the next Clang release. The problem exists for many platforms 
which are not primary targets of Clang. E.g. on MinGW32, it also calls back 
into the MinGW32 GCC as assembler and linker, which causes configure scripts to 
fail if they use clang-only flags. So if we want to get GCC-free, we need to 
teach Clang how to invoke the linker directly on Haiku. I think this is 
something we should definitely in the future, and then raise our minimum Clang 
version.

For the time being (or probably even permanently) we could host "our" version of clang somewhere to avoid having to wait for the next official release.

BTW, I'm less concerned about calling the assembler and the linker than about the actual gcc dependencies like the glue code, libgcc, lib{sup,std}c++. I hope there are equivalent replacements for clang.

When it is clear how that can be done, the configure script should be adjusted to support clang. We'll probably 
want to define a jam variable HAIKU_COMPILER_<arch> to identify the compiler ("gcc", 
"gcc2", "clang"). Then we can refactor the related code in the jam build system. The current 
approach, fixing the compilation while not even using a proper compilation environment, is just backward.

Yes, I very much agree that the current approach is only a hack. It's a hack so 
that it's possible to at least build a Clang-only build. So I think we should 
come up with 2 solution: One short-term solution and a long-term solution.

Since there's no real hurry, I'd rather do it right in the first place. Temporary solutions/hacks have a tendency to be rather long-lived.

As the Jam system seems to be not so well-understood by many Haiku developers 
and it seems you and Axel are the only ones who know enough about it / really 
care about it, I would suggest that we 3 have a discussion on IRC so we can 
talk through the different approaches and select the best one (we could even do 
that in German then, to make things easier), as the problem seems to be more 
complex than any of us thought at first. After that discussion, we could send 
another mail to the list summarizing our decision to document it. Do you two 
agree on that?

I believe you're right in that the knowledge about build system internals isn't particularly wide-spread, since most developers only interface with certain parts of the build system, like the Jamfiles or image/package content definitions (and that's fine, too). I guess, if anything, that's a reason for keeping discussions on-list.

That being said, I don't think there isn't that much left to discuss. I actually already started to work on refactoring the compiler specific parts until I noticed that due to the entanglement of clang with gcc that can't be cleanly done yet. Hence I'd rather see those disentangled first.

CU, Ingo


Other related posts: