On Wed, Feb 5, 2014 at 1:17 AM, Michel Alexandre Salim <salimma@xxxxxxxxxxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/03/2014 10:31 PM, Dave Johansen wrote:
> On Sun, Feb 2, 2014 at 7:58 PM, Dave Johansen
> <davejohansen@xxxxxxxxx <mailto:davejohansen@xxxxxxxxx>> wrote:
>
> The EL6 build of llvm 3.4 is currently in testing and it was just
> pointed out that there's a potential issue with the build (
> https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0264/llvm-3.4-5.el6
>
>
).
>
> If you examine the build.log (
> http://kojipkgs.fedoraproject.org//work/tasks/593/6470593/build.log
>
>
) It looks like the include path is being included twice and that's
> causing the warning about the invalid host type. Is there
> something wrong with the .spec file? Or is there something I can do
> to fix/prevent this issue?
>
> Thanks, Dave
>
>
> I was able to get a hold of the original submitter of the issue and
> the issue is because of the multiple paths that exist on EL6.
> Here's his explanation and recommended solution:
>
>> $ echo /usr/lib/gcc/x86_64*/*/include
>> /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/include
>>
>> EL6 originally had gcc-4.4.4 and gcc-4-4.7 still has the old
>> path
> included for compatibility. Because of the space inbetween
> configure thinks /usr/lib/gcc/x86_64-redhat-linux/4.4.7/include is
> a host type.
>>
>> The files in /usr/lib/gcc/x86_64-redhat-linux/4.4.7/include have
> nothing to do with C++. Clang has own versions of these files in
> /usr/lib/clang/3.4/include.
>>
>> Therefore it should just be
>> --with-c-include-dirs=%{_includedir},
> which is also the default if you specify nothing.
>>
>> C++ headers and runtime libs from gcc are selected by clang at
>> runtime:
>>
>> $ clang -v clang version 3.4 (tags/RELEASE_34/final) Target:
>> x86_64-redhat-linux-gnu Thread model: posix Found candidate GCC
>> installation: /usr/lib/gcc/x86_64-redhat-linux/4.4.4 Found
>> candidate GCC installation:
>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7 Selected GCC installation:
>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7
> So my question is if the same sort of change also needs to be madeOn Fedora there is no compatibility symlink; IIRC the
> in the Fedora .spec file that the EL6 one is based on.
>
00with-c-include-dirs was added (by myself) because at the time LLVM
and Clang's detection routines were less reliable (there was a list of
GCC versions it knows about, and if the version installed is newer -
as is likely at every Fedora cycle - it breaks, unless the include
directory is manually specified)
I'm no longer routinely involved in LLVM maintenance, but agree that
it might be worth re-checking the Fedora .spec.
I don't have a machine with rawhide available at the moment, but it sounds like this is worth looking into.
I'll try rebuilding Pure once the LLVM update lands - does Clang now
ship a complete set of C++ headers as well? That was a sticking point
earlier as the headers shipped by GCC in EL6 is too old for newer
versions of LLVM-targeting apps.
I'm not familiar with Pure, but apparently the newest version doesn't work with the glibc that's available on EL6 ( see https://bugzilla.redhat.com/show_bug.cgi?id=1058472 ), so it's just obsoleted by the llvm 3.4 package for the time being.
libc++ is complete ( http://libcxx.llvm.org/ ) and I've been wondering if the EL6 llvm package should ship with them just so the C+11/14 stuff will work, but are there going to be any issues with that?
One other issue is that I had to make the following change to get libffi support working properly in EL6. I'm not sure if the same change is needed on Fedora or not, but I just wanted to throw it out there so that someone with a rawhide machine could see if this same change was need there as well.
http://pkgs.fedoraproject.org/cgit/llvm.git/commit/?h=el6&id=5b96b3dfff9ec6beaaa7d4fa7ee17a79cd58214c
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
