../version:1:1: error: expected unqualified-id #1086
Comments
|
Thx, this looks familiar to me. Isn't this fixed in current HEAD?
Uli
Ryan Carsten Schmidt ***@***.***> schrieb am Fr., 13. Dez.
2024, 20:59:
… Building nxcomp 3.5.99.22 on a case-insensitive filesystem (e.g. on macOS)
with a C++20-capable compiler (e.g. Apple clang version 14.0.0
(clang-1400.0.29.202)) fails:
../version:1:1: error: expected unqualified-id
3.5.99.22
^
This is because C++20 has a header called <version> and on a
case-insensitive filesystem your VERSION file will be found instead.
Solutions include:
- Stop adding the -I flag that points to the directory where the
VERSION file is located. With a project like this one that uses autoconf,
this -I flag is added automatically because this is the directory
where config.h is created. So one solution is to move config.h to a
different directory.
- Move the VERSION file to a different directory, one for which an -I
flag is not added, and update all references to it, e.g. in version.sh.
- Rename the VERSION file to something else, e.g. VERSION.txt, and
update all references to it.
—
Reply to this email directly, view it on GitHub
<#1086>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABQHBZEEQQWH6NVRVGYSXTT2FM4BVAVCNFSM6AAAAABTSURF76VHI2DSMVQWIX3LMV43ASLTON2WKOZSG4ZTSMJRGU2TQNQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I don't know. I'm sure a lot has changed in the nearly five years since 3.5.99.22 was released. That's the latest version I see at https://code.x2go.org/releases/source/nx-libs/ . Maybe it's time to release a new version. |
|
I tested the latest commit on the 3.6.x branch, 58d42b6, and the problem is still there. |
|
Alright, then we will have to patch this. But AFAIK we have MacOS builds at
x2go. So how were they made? What's the default regarding
case-insensitivity on MacOS?
Ryan Carsten Schmidt ***@***.***> schrieb am Sa., 14. Dez.
2024, 03:15:
… I tested the latest commit on the 3.6.x branch, 58d42b6
<58d42b6>,
and the problem is still there.
—
Reply to this email directly, view it on GitHub
<#1086 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABQHBZCNPRYSN2MTYCZILIT2FOIFXAVCNFSM6AAAAABTSURF76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBSGY3DOMZYHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
nx-libs was always built via MacPorts and bundled manually into the X2Go Client package. The system header must be relatively new, which is why it worked fine previously, but fails now.
Unfortunately, HFS+ and APFS are case-insensitive by default. HFS+ supports case sensitivity, and APFS might also, but that's never actually used (and a lot of the ecosystem breaks, especially third-party applications, if case sensitivity is turned on, because almost nobody tests that).
Yeah, definitely. A few weeks ago, during X2Go The Spread (annual online meeting for the past COVID times), it was brought to my attention that X2Go's nx-libs and Arctica are quite out of sync by now, so I'll sync up our nightly builds to the current Arctica nightly version and jump to the current Arctica release within X2Go. Note that X2Go is not upstream for nx-libs any longer, we're just fetching Arctica's releases and re-release them without changes if possible, or with build fixes if necessary, but I've been lagging behind on that. We typically also want to test new nx-libs releases before actually pushing them as a new stable version at X2Go to make sure that the backend isn't suddenly broken. Mike wants to release a new version of nx-libs because we haven't had a release in Arctica for quite some time either and a lot of fixes have made their way into the code, so I intended to wait for the new version to do a sync-up in X2Go realm.
That's probably the best way to go, at least for the autotools-based directories. The |
Compilers that support C++20 and later have this header. According to MacPorts research this is clang 16 and later from llvm.org and clang 1500 and later from Apple Xcode 15 and later.
Yes, APFS also supports case-sensitivity. I do use case-sensitive volumes for the MacPorts buildbot machines for the benefit of the one or two ports that require it.
Where are upstream releases for nx-libs now? There are none at https://github.com/ArcticaProject/nx-libs/releases . There are tags there, yes, but tarballs automatically generated from tags by GitHub are not guaranteed to be immutable, which is a desirable quality of release downloads. |
But evidently some earlier versions also have enough partial support for C++20 be affected, since I saw it with Apple clang 1400. |
Building nxcomp 3.5.99.22 on a case-insensitive filesystem (e.g. on macOS) with a C++20-capable compiler (e.g. Apple clang version 14.0.0 (clang-1400.0.29.202)) fails:
This is because C++20 has a header called
versionwhich other system headers include, and on a case-insensitive filesystem yourVERSIONfile will be found instead.Solutions include:
-Iflag that points to the directory where theVERSIONfile is located. With a project like this one that uses autoconf, this-Iflag is added automatically because this is the directory where config.h is created. So one solution is to move config.h to a different directory.VERSIONfile to a different directory, one for which an-Iflag is not added, and update all references to it, e.g. in version.sh.VERSIONfile to something else, e.g.VERSION.txt, and update all references to it.The text was updated successfully, but these errors were encountered: