On 7/27/2016 1:50 PM, Jim Michaels wrote:
> On 7/26/2016 12:21 PM, André Hentschel wrote:
>> Am 25.07.2016 um 12:21 schrieb dw:
>>> Thank you for the link, I was not aware of this.  I'm using Msys2, so
>>> the linux issues should not affect me.
>>>
>>> While I got the associated binutils to build (which gets me an 'as'
>>> build that supports the .def directive, yay!), I have been totally
>>> unable to get the patched gcc to build.
>>>
>>> The patches here are from ~3 years ago (2013-03-17), but the PKGBUILD
>>> seems to download gcc's current 'trunk.'  Does that seem right?  Not
>>> surprisingly, the patches fail in a number of places. I have tried to
>>> fix them, but I'm not having much luck.  Would it make sense to git a 3
>>> year old version of gcc (~215509) instead?  Would -e prevent makepkg
>>> from trying to update it?
>> older gcc seems like a solution, or you can compile mingw-w64 for clang 
>> instead
>>
>>> My end goal here is to test a mingw-w64 source code change to make sure
>>> I'm not breaking ARM builds.
>>>
>>> I gotta wonder: How do other people do ARM builds?
>> There are not too many people doing that
>>
>>
> ARM comes in 3 interesting flavors: so make a triple decker.
>
> ARM32\ (formerly arm)
> ARM64V80\ (64-bit, different instruction set than arm32 which are
> earlier versions of arm)
> ARM64V81\ (arm v8.1, different instruction set than v80)
>
> so I would suggest that for one compiler, it could have these
> directories and
>
> x86\lib
> x86_64\lib
> ARM32\lib\
> ARM64V80\lib\
> ARM64V81\lib\
>
> x86\include\
> x86_64\include\
> ARM32\include\
> ARM64V80\include\
> ARM64V81\include\
>
> include\x86\c++\7.0.0\
> include\x86_64\c++\7.0.0\
> include\ARM32\c++\7.0.0\
> include\ARM64V80\c++\7.0.0\
> include\ARM64V81\c++\7.0.0\
>
> x86\bin\
> x86_64\bin\
> ARM32\bin\
> ARM64V80\bin\
> ARM64V81\bin\
> no, x86 and x86_64 do not mesh well together, because the DLLs have the
> same name, and the exes do not mix either for same reason. if someone
> wants to do simultaneous builds
>
>
> to build for multiplatform, a for statement in the cmd shell can do this:
> for %x in (x86 x86_64 ARM32 ARM64V80, ARM64V81) do (\gcc-7-win32\%x\g++
> -static... > %x-error.txt)
> in a batch file you change %x to %%x.

My problem isn't "adding support for multiplatform."  It's getting *any* 
ARM build to work.  Any at all.

I've gotten a couple of binutils to build, but I'm not 100% certain they 
are correct.  Should armv7-w64-ming32 support CFI? Windows is a COFF 
system, and CFI is normally associated with ELF.  However compiling C 
programs with i686-w64-mingw32 outputs CFI directives and that's a COFF 
system.  None of the gas builds I have done so far support CFI, but some 
of the files in a gcc build use cfi directives.  Does that mean I'm 
building gas wrong?  Or that I'm configuring things wrong when I build 
gcc so that files that shouldn't be built (since they contain CFI) are 
being built by mistake?  Or are the files that use .cfi directives 
without checking for something like __ELF__ just wrong?

I'm having even less luck trying to do a cross build of gcc (possibly 
due to my gas problems).  There are several packages out there that 
purport to do this, but none of them actually seem to work.  Some fail 
because they try to build from 'trunk' using 2-3 year old patches.  Some 
fail because they depend on specific versions of build tools that MSys 
doesn't support any more.  Some are designed for cygwin vs MSys 
(although I'd be willing to switch if it would help), assume customized 
headers installed, etc.  The PKGBUILD I'm experimenting with right now 
won't build "mingw-w64-cross-gcc" because it has a dependency on 
"mingw-w64-cross-crt."  But you can't build cross crt because it depends 
on "mingw-w64-cross-gcc."

I'm not sure how many people have actually succeeded in building a 
armv7-w64-ming32 version of mingw-w64, but I think André was being 
generous when he said "There are not too many people doing that." I'm 
clearly not going to be the first (unless I'm seriously being punked 
here), but we may still be in single digits.

dw

------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to