r253898 - Driver: fallback to the location of clang if no sysroot,

[Martell Malone via cfe-commits]

>
> Searching for gcc on Linux is not a good idea, you'll find the system one
> not the mingw one. Searching for i686-w64-mingw32-gcc or
> x86_64-w64-mingw32-gcc should work better, that is searching for:
>   getTriple().getArchName()) + "-w64-mingw32-gcc"

Moreover, this should work on Windows as well, mingw-w64 distribution has
> [i686|x86_64]-w64-mingw32-gcc.exe at the same location as gcc.exe. For this
> you can unite the code for both Linux and Windows.
>
Agreed this makes most sense.

To continue supporting mingw.org, if this search fails, search for
> mingw32-gcc.

I'll make a patch for review, I won't be able todo it until the weekend
because of work but I will get to it

On Tue, Nov 24, 2015 at 7:03 AM, Yaron Keren <yaron.keren at gmail.com> wrote:

> Searching for gcc on Linux is not a good idea, you'll find the system one
> not the mingw one. Searching for i686-w64-mingw32-gcc or
> x86_64-w64-mingw32-gcc should work better, that is searching for:
>
>   getTriple().getArchName()) + "-w64-mingw32-gcc"
>
> Moreover, this should work on Windows as well, mingw-w64 distribution has
> [i686|x86_64]-w64-mingw32-gcc.exe at the same location as gcc.exe. For this
> you can unite the code for both Linux and Windows.
>
> To continue supporting mingw.org, if this search fails, search for
> mingw32-gcc.
>
>
>
> 2015-11-24 16:36 GMT+02:00 Martell Malone <martellmalone at gmail.com>:
>
>> Why not hardcode /usr for Linux hosts?
>>
>> Portable toolchain packages exist but can't on linux if you do this.
>> but in general I'm sure most would agree that detection is much better
>> then hard coding.
>> This is why Yaron approved the patch
>>
>> Well this is a custom clang it can be anywhere. Official one is in /usr.
>>
>> This means that your earlier statement of "This breaks mingw support on
>> openSUSE" is incorrect.
>> The official SUSE packages still work with this patch.
>>
>> More accurately it breaks your setup of having clang and mingw-w64 in 2
>> completely separate install locations.
>> Which is not a typical use case even for gcc and one would be expected to
>> pass a sysroot for this.
>>
>> For a more immediate solution for your specific setup I would create a
>> bash script called
>> x86_64-w64-mingw32-clang
>> with this content like this
>> #!/usr/bin/env bash
>> /opt/bin/clang -target x86_64-windows-gnu -sysroot=/usr "$@"
>>
>> It seems as though SUSE''s binutils is built with sysroot so this should
>> be acceptable
>>
>> https://build.opensuse.org/package/view_file/windows:mingw:win64/mingw64-cross-binutils/mingw64-binutils.spec?expand=1
>>
>> Other then that we should wait for Yaron's thoughts on mingw-gcc
>> detection on linux :)
>>
>>
>>
> On Tue, Nov 24, 2015 at 2:53 AM, Ismail Donmez <ismail at i10z.com> wrote:
>
>> On Tue, Nov 24, 2015 at 12:43 PM, Martell Malone
>> <martellmalone at gmail.com> wrote:
>> >> This breaks mingw support on openSUSE :
>> >
>> > My first question is why on SUSE is clang installed in /opt while
>> mingw-w64
>> > in /usr?
>>
>> Well this is a custom clang it can be anywhere. Official one is in /usr.
>>
>> >> x86_64-w64-mingw32-gcc is in $PATH, and this used to work fine before
>> >> this commit.
>> >
>> > It doesn't look for gcc on linux that is a windows host only thing.
>> > It didn't do that before this commit also.
>> > SUSE was just lucky because we hard coded /usr as the base path.
>>
>> This is not a SUSE only thing, afaik Fedora has the same setup.
>>
>> > I don't like the idea of hard coding for just a single distro so I think
>> > We could optionally do some search for "x86_64-w64-mingw32-gcc" on non
>> > windows hosts
>> > Just like we do for "gcc" on windows hosts.
>> > This should fix SUSE while maintaining the new more reasonable search
>> > pattern.
>>
>> Why not hardcode /usr for Linux hosts?
>>
>> Thanks,
>> ismail
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151124/9f850c30/attachment.html>