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