delorie.com/archives/browse.cgi | search |
DKIM-Filter: | OpenDKIM Filter v2.11.0 delorie.com 46M8hVk22424461 |
Authentication-Results: | delorie.com; |
dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=rLEKx1sD | |
X-Recipient: | archive-cygwin AT delorie DOT com |
DKIM-Filter: | OpenDKIM Filter v2.11.0 sourceware.org 243D43858401 |
DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; |
s=default; t=1721637810; | |
bh=RB9Ws2cyCRSFP1gmguvfWPP6HrXNslf2If870L/afWU=; | |
h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: | |
List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: | |
From; | |
b=rLEKx1sD8iUBiqdK98vHZTU8pxjGDfZgiT0zNLkqMTVI20y0KP0W5peheTEgvER5F | |
pOeEjW3Bkao+xpVdxtJ2wgbSRsSnlMCAFCjPbkOxfiASjKbb3/q8b68fZDwPuJxHkO | |
GBZtn9g9ut+/N9N3eQCzxogZWyre215vPGi0ZQ2c= | |
X-Original-To: | cygwin AT cygwin DOT com |
Delivered-To: | cygwin AT cygwin DOT com |
DMARC-Filter: | OpenDMARC Filter v1.4.2 sourceware.org 0F3583858C53 |
ARC-Filter: | OpenARC Filter v1.0.0 sourceware.org 0F3583858C53 |
ARC-Seal: | i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721637778; cv=none; |
b=vqQlZZ/DG2/i2DIxavU7GQck1vkMv+pbWXzqvM/pUbG6+ARBrsFnnSClYYdOA1dSkIKOlZCcqhvjwdC2AUYUnivbgXMRAwkkbChKf/iFsceipUP0dKRR/S+mno/gKqCB4xknmnQmyIi0OU+gms01GyDuHYeSCVRPYsmXgXeYDho= | |
ARC-Message-Signature: | i=1; a=rsa-sha256; d=sourceware.org; s=key; |
t=1721637778; c=relaxed/simple; | |
bh=ZUcAaDnaPUcR/6yUKhk5F6S+T771zHopqcJII969TTA=; | |
h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; | |
b=jOTjwbTK4T2DP9tpq4XK1gplESpHVswIABrf54zaH8mxvOt2AX5QgAEngwCO6nWzAJQQ0jiyQzOB4Hp5hxtDHdT6SmnVEiKaplMkbwQnEvjhIw42UDgO5zwkFT82nrEdK9HDObxyoC/+jXpL/zSNyOyt3lPw9TmtLAsX/7ldOuo= | |
ARC-Authentication-Results: | i=1; server2.sourceware.org |
X-Google-DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; |
d=1e100.net; s=20230601; t=1721637773; x=1722242573; | |
h=to:subject:message-id:date:from:in-reply-to:references:mime-version | |
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; | |
bh=jECIUVPKSQDUo3jRrvorC0tdl1ek5o6QSIBKcLwJ3jE=; | |
b=px/P+OXM644WtMx166evTwJPc9zfDH3w3KNoyM4BK6cinxdnxGIFSmZwa9i43I2ukc | |
+dMhPD+xV3M1ciJ2yndC6kK82AlkeeUvNKRbzkQdjh0dLkv+XcTwkgtJeA3eGm4ZU65m | |
GDeFDouZOyKsXqmas/6BeweZlT1m1WFdQbCL0O8XnRdBfbUGUGawT7Z8/OnfFK+X90RS | |
Kj7OVrW/ejKDyDPYu+MUfMqB/jm55tiW2q9vW0skpYfkCg2BAuqn3cR7DujoXYsJS3r4 | |
fjRxziQN4LMBsy8fRq9l+IvS0nrFlN/iL2w2WFFzwvipNb2hO95FjiHEoREN8pBILzi7 | |
iYRg== | |
X-Gm-Message-State: | AOJu0YxAjf3yEzqVlAKAu75oPwq0BZbTWW7QP2fjVPyBiLK7g8nE9xtI |
/Z1fynpEXWRK8LU2NqKn9BKyF255JAd33lOwnTEb12IJ41aH4yfxSKFAor6qoR5+wtnoWfwhIKG | |
9H36kbDIyeT8QhKghmC7gTkZOFDd9P6ym | |
X-Google-Smtp-Source: | AGHT+IGAR3D2BdNOMgsOZvq1+03ge/Lb/tYo/zRec60xHlL9rIkyogKYjEjD7HqvwQhQHKzGcAmNG8MyMsuYao7MTsg= |
X-Received: | by 2002:adf:f581:0:b0:367:99fd:d7ba with SMTP id |
ffacd0b85a97d-368315f3b26mr8207454f8f.3.1721637773427; Mon, 22 Jul 2024 | |
01:42:53 -0700 (PDT) | |
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 |
X-Spam-Status: | No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, |
DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, | |
SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 | |
X-Spam-Checker-Version: | SpamAssassin 3.4.6 (2021-04-09) on |
server2.sourceware.org | |
X-BeenThere: | cygwin AT cygwin DOT com |
X-Mailman-Version: | 2.1.30 |
List-Id: | General Cygwin discussions and problem reports <cygwin.cygwin.com> |
List-Archive: | <https://cygwin.com/pipermail/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-request AT cygwin DOT com?subject=help> |
List-Subscribe: | <https://cygwin.com/mailman/listinfo/cygwin>, |
<mailto:cygwin-request AT cygwin DOT com?subject=subscribe> | |
From: | "Carlo B. via Cygwin" <cygwin AT cygwin DOT com> |
Reply-To: | "Carlo B." <carlo DOT bramini AT gmail DOT com> |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |