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

[Martell Malone via cfe-commits]

>
> This breaks mingw support on openSUSE :

My first question is why on SUSE is clang installed in /opt while mingw-w64
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.

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.

If Yaron approves this idea I will commit it with a test case for SUSE so
we don't break it again :)
Yaron your thoughts?

Kind Regards
Martell

On Tue, Nov 24, 2015 at 12:02 AM, Ismail Donmez  wrote:

> Hi,
>
> On Mon, Nov 23, 2015 at 8:59 PM, Martell Malone via cfe-commits
>  wrote:
> > Author: martell
> > Date: Mon Nov 23 12:59:48 2015
> > New Revision: 253898
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=253898=rev
> > Log:
> > Driver: fallback to the location of clang if no sysroot,
> >
> > hard coding /usr makes little sense for mingw-w64.
> > If we have portable toolchains having /usr breaks that.
> > If the clang we use is in /usr/bin or /usr/sbin etc this will
> > still detect as though it was hard coded to /usr
> >
> > This makes the most sense going forward for mingw-w64 toolchains
> > on both linux and mac
>
> This breaks mingw support on openSUSE :
>
> λ cat hello.c
> #include 
>
> int main()
> {
> return 0;
> }
>
> λ clang -v -target x86_64-w64-mingw32 hello.c
> clang version 3.8.0 (trunk 253903)
> Target: x86_64-w64-windows-gnu
> Thread model: posix
> InstalledDir: /opt/clang/bin
>  "/opt/clang/bin/clang-3.8" -cc1 -triple x86_64-w64-windows-gnu
> -emit-obj -mrelax-all -disable-free -main-file-name hello.c
> -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno
> -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64
> -momit-leaf-frame-pointer -v -dwarf-column-info -resource-dir
> /opt/clang/bin/../lib64/clang/3.8.0 -internal-isystem
> /opt/clang/bin/../lib64/clang/3.8.0/include -internal-isystem include
> -internal-isystem /opt/clang/x86_64-w64-mingw32/sys-root/mingw/include
> -internal-isystem include-fixed -internal-isystem
> /opt/clang/x86_64-w64-mingw32/include -internal-isystem
> /opt/clang/include -fdebug-compilation-dir /home/ismail -ferror-limit
> 19 -fmessage-length 127 -fno-use-cxa-atexit -fobjc-runtime=gcc
> -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/hello-f129aa.o
> -x c hello.c
> clang -cc1 version 3.8.0 based upon LLVM 3.8.0svn default target
> x86_64-suse-linux
> ignoring nonexistent directory "include"
> ignoring nonexistent directory
> "/opt/clang/x86_64-w64-mingw32/sys-root/mingw/include"
> ignoring nonexistent directory "include-fixed"
> ignoring nonexistent directory "/opt/clang/x86_64-w64-mingw32/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /opt/clang/bin/../lib64/clang/3.8.0/include
>  /opt/clang/include
> End of search list.
> hello.c:1:10: fatal error: 'stdlib.h' file not found
> #include 
>  ^
> 1 error generated.
>
> x86_64-w64-mingw32-gcc is in $PATH, and this used to work fine before
> this commit.
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Ismail Donmez via cfe-commits]

On Tue, Nov 24, 2015 at 12:43 PM, Martell Malone
 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
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Martell Malone via cfe-commits]

>
> 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  wrote:

> On Tue, Nov 24, 2015 at 12:43 PM, Martell Malone
>  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
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Yaron Keren 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.

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



2015-11-24 16:36 GMT+02:00 Martell Malone :

> 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  wrote:

> On Tue, Nov 24, 2015 at 12:43 PM, Martell Malone
>  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
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: 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  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 :
>
>> 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  wrote:
>
>> On Tue, Nov 24, 2015 at 12:43 PM, Martell Malone
>>  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
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits