DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0F3583858C53
MIME-Version: 1.0
References: <CADt9577Y5_BM8KeXZ-upOU6P-Lj78W7TUxi37PNCF8G2mr3GYg AT mail DOT gmail DOT com>
 <a3fc36ac-9467-474c-ad89-d84eab10a1bf AT dronecode DOT org DOT uk>
In-Reply-To: <a3fc36ac-9467-474c-ad89-d84eab10a1bf@dronecode.org.uk>
Date: Mon, 22 Jul 2024 10:42:47 +0200
Message-ID: <CADt9577tzWEa_qPtgMXs6uhtH_7vjDy_oOsyUmUmVUUx35LmZQ@mail.gmail.com>
Subject: Re: CYGPORT not setting CMAKE_SYSTEM_PROCESSOR when cross compiling
 with aarch64-w64-mingw32.
To: cygwin AT cygwin DOT com
From: "Carlo B. via Cygwin" <cygwin AT cygwin DOT com>
Reply-To: "Carlo B." <carlo DOT bramini AT gmail DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

Hello,
thank you for your reply.
The patch is a good start to me.
However, I think that it would be better to remove the error if CHOST
or CTARGET include something different from x86_64, i686 or aarch64.
Otherwise, you won't be able to cross compile anything with CMake,
except for those CPUs.
Instead, in my opinion it would be better to return an empty string,
to be assigned to a variable at the calling function.
So, if that variable will not empty, then CMAKE_SYSTEM_PROCESSOR will
be appended to crossargs with that value.
Otherwise, CMAKE_SYSTEM_PROCESSOR won't be added to crossargs and it
will work as it worked until now.
According to the documentation:
https://cmake.org/cmake/help/latest/variable/CMAKE_HOST_SYSTEM_PROCESSOR.html
when it is not cross compiling, CMake assignes the return value of
"uname" to CMAKE_SYSTEM_PROCESSOR.
So, some of the possible values of that variable could be:
    alpha
    arc
    arm
    aarch64_be (arm64 big endian)
    aarch64 (arm64)
    armv8b (arm64 compat big endian)
    armv8l (arm64 compat little endian)
    blackfin
    c6x
    cris
    frv
    h8300
    hexagon
    ia64
    m32r
    m68k
    metag
    microblaze
    mips (native or compat)
    mips64 (mips)
    mn10300
    nios2
    openrisc
    parisc (native or compat)
    parisc64 (parisc)
    ppc (powerpc native or compat)
    ppc64 (powerpc)
    ppcle (powerpc native or compat little endian)
    ppc64le (powerpc little endian)
    s390 (s390x compat)
    s390x
    score
    sh
    sh64 (sh)
    sparc (native or compat)
    sparc64 (sparc)
    tile
    unicore32
    i386 (x86)
    i686 (x86 compat)
    x86_64 (x64)
    xtensa
If there will be the need to add some of them in the future, somebody
may add them.
Perhaps, it would be useful to add also this information to the patch
as a comment, just for reference.
Thank you very much for your time.

Sincerely,

Carlo Bramini.

Il giorno sab 20 lug 2024 alle ore 20:18 Jon Turney
<jon DOT turney AT dronecode DOT org DOT uk> ha scritto:
>
> On 19/07/2024 09:08, Carlo B. via Cygwin wrote:
> > Hello,
> >
> > GCC development branch includes experimental support Windows on ARM64
> > (WOA), which will be officially released next year with version 15, at
> > least according to latest news.
> > So, I compiled it and I created a number of packages for CYGWIN
> > including binutils, gcc, mingw runtime and several libraries, not
> > released yet to my repository.
> > Although the "aarch64-w64-mingw32" target is still experimental, I
> > have to say that this cross compiler worked very well, at least until
> > now.
>
> Great work! We'd certainly welcome and appreciate your help getting
> packages for this into our repository, also.
>
> > However, some problems appear because there are some thirdy party
> > tools not expecting to have mingw combined with something different
> > than i686 or x86_64.
> > For example, it is impossible to create a shared library when using
> > libtool, more details could be found here:
> > https://savannah.gnu.org/support/?111081
>
> Huh. I guess someone should fix that, then!
>
> I think for a start, the regex around line 5724 in libtool (near the
> comment about keeping it in sync with _LT_CHECK_MAGIC_METHOD) needs
> updating to match arm64 archives...
>
> > For this reason, you have to use CMake or other alternative tools
> > instead of autotools.
> >
> > Actually, another problem can happen when creating the packages for
> > CYGWIN with CYGPORT utility.
> > For example, I tried to build a noarch package of libpng for CYGWIN,
> > by using the new aarch64-w64-mingw32.
> > I have used CMake to bypass the above trouble with libtool.
> > Unfortunately, the build process still fails because it didn't compile
> > the sources for adding the functions with NEON acceleration.
> > The cause of the problem is the variable CMAKE_SYSTEM_PROCESSOR that is empty.
> > This is not a bug of CMake, because CMAKE_SYSTEM_PROCESSOR is
> > typically set into CMAKE_TOOLCHAIN_FILE by the user when cross
> > compiling.
> > At the moment, I bypassed the trouble by adding
> > "-DCMAKE_SYSTEM_PROCESSOR=aarch64" to CYGCMAKE_ARGS into my script.
> > I gave a look into /usr/share/cygport/cygclass/cmake.cygclass and it
> > seems to me that there is nothing for setting the CPU type.
> > Perhaps it would be worth to add support for setting
> > CMAKE_SYSTEM_PROCESSOR into cmake.cygclass, by checking the content of
> > ${CTARGET}, if it exists with a known CPU.
>
> Interesting.
>
> I took a look and there are several existing packages which have been
> cross-built for x86 and x86_64 MinGW using cmake, so either it seems
> this hasn't yet appeared as a problem for those arches and/or packages...
>
> It's not terribly clear what the valid values are for that cmake
> variable, and what it controls, but the answer [1] makes it seem like
> it's not a lot:
>
> [1]
> https://stackoverflow.com/questions/70475665/what-are-the-possible-values-of-cmake-system-processor
>
> But yeah, this seems eminently fixable in cygport, something like the
> attached I think.
>

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple