Simon Wright

Building alr with alr, shared vs static library issue

[{"_id":"63456d14b918e158f314c791","body":"I tried to build alr using x86_64 alr as well, and it works on `master`, if `native` toolchain is selected\r\n\r\nIf I choose `gnat_arm_elf` toolchain, I get this:\r\n\r\n```\r\ngprconfig: can't find a native toolchain for language 'ada'\r\ngprconfig: can't find a native toolchain for language 'ada'\r\naaa.gpr:1:09: warning: there are no sources of language \"C\" in this project\r\najunitgen.gpr:3:09: warning: there are no sources of language \"C\" in this project\r\nxml_ez_out.gpr:1:09: warning: there are no sources of language \"C\" in this project\r\nansi.gpr:1:09: warning: there are no sources of language \"C\" in this project\r\nclic.gpr:6:09: warning: there are no sources of language \"C\" in this project\r\nsimple_logging.gpr:1:09: warning: there are no sources of language \"C\" in this project\r\nminirest.gpr:5:09: warning: there are no sources of language \"C\" in this project\r\noptional.gpr:1:09: warning: there are no sources of language \"C\" in this project\r\nsemantic_versioning.gpr:1:09: warning: there are no sources of language \"C\" in this project\r\nspdx.gpr:1:09: warning: there are no sources of language \"C\" in this project\r\nstopwatch.gpr:1:09: warning: there are no sources of language \"C\" in this project\r\ntoml_slicer.gpr:3:09: warning: there are no sources of language \"C\" in this project\r\nuri.gpr:1:09: warning: there are no sources of language \"C\" in this project\r\nsi_units.gpr:1:17: no compiler for language \"Ada\", cannot compile \"si_units-metric.adb\"\r\ngprbuild: *** compilation phase failed\r\n```","issue_id":1660428198474,"origin_id":1105682707,"user_origin_id":452,"create_time":1650570109,"update_time":1650570109,"id":1665494292143,"updated_at":"2022-10-11T13:18:12.143000Z","created_at":"2022-10-11T13:18:12.143000Z"},{"_id":"63456d14b918e158f314c792","body":"@simonjwright I've seen your problem some time building with GNATstudio. It was fixable by setting clic build to static or static-pic, I can't exactly remember.\r\n\r\n@yrashk that's funny because if `gprbuild` can find the `gnat_native` compiler it should have no trouble either with a `gnat_arm_elf`. Since that's a different issue though, I suggest you open a new one if you want to pursue it.","issue_id":1660428198474,"origin_id":1105693100,"user_origin_id":264377,"create_time":1650570800,"update_time":1650570800,"id":1665494292146,"updated_at":"2022-10-11T13:18:12.146000Z","created_at":"2022-10-11T13:18:12.146000Z"},{"_id":"63456d14b918e158f314c793","body":"I get the same result on x86_64. If I set `CLIC_LIBRARY_TYPE=static` the build succeeds.\r\n\r\nAn interesting result: having just got the successful build above,\r\n```\r\n$ LIBRARY_TYPE=static bin\/alr build\r\nerror: Trying to set an alredy defined environment variable:\r\nerror: LIBRARY_TYPE is already defined as 'static' but new value is 'static-pic'\r\n```\r\n","issue_id":1660428198474,"origin_id":1105771844,"user_origin_id":1824512,"create_time":1650576019,"update_time":1650576019,"id":1665494292151,"updated_at":"2022-10-11T13:18:12.150000Z","created_at":"2022-10-11T13:18:12.150000Z"},{"_id":"63456d14b918e158f314c794","body":"@yrashk The `gnat_arm_elf` toolchain is for MCU (bare-board) targets, and needs to have a runtime specified. `alire` is never going to run on bare-board targets.","issue_id":1660428198474,"origin_id":1105778075,"user_origin_id":1824512,"create_time":1650576461,"update_time":1650576461,"id":1665494292163,"updated_at":"2022-10-11T13:18:12.163000Z","created_at":"2022-10-11T13:18:12.163000Z"},{"_id":"63456d14b918e158f314c795","body":"Got it. I was hoping it was suitable for M1, haha! So far, it looks like only `x86_64` is feasible as a target on M1.","issue_id":1660428198474,"origin_id":1105779624,"user_origin_id":452,"create_time":1650576574,"update_time":1650576574,"id":1665494292167,"updated_at":"2022-10-11T13:18:12.167000Z","created_at":"2022-10-11T13:18:12.167000Z"},{"_id":"63456d14b918e158f314c796","body":"@yrashk See https:\/\/github.com\/simonjwright\/distributing-gcc\/releases\/tag\/aarch64-apple-darwin21-2\r\nBe warned, I made a mistake with aunit, you\u2019ll get warnings about mismatched macOS versions (12.3 vs 12.0) - ignore","issue_id":1660428198474,"origin_id":1105785716,"user_origin_id":1824512,"create_time":1650577072,"update_time":1650577072,"id":1665494292171,"updated_at":"2022-10-11T13:18:12.171000Z","created_at":"2022-10-11T13:18:12.171000Z"},{"_id":"63456d14b918e158f314c797","body":"@simonjwright amazing, this worked for my project! Thank you\r\n\r\n Though still can't rebuild master `alr` using it:\r\n\r\n```\r\n\u24d8 Building alr\/alr.gpr...\r\nCompile\r\n [Ada] alr-main.adb\r\n [Ada] gnatcoll-io-remote-windows.adb\r\n [Ada] gnatcoll-io-remote-unix.adb\r\n [Ada] gnatcoll-ravenscar-timed_out_sporadic_server.adb\r\n [Ada] gnatcoll-memory.adb\r\n [Ada] gnatcoll-format_columns_vertical.ads\r\n [Ada] gnatcoll-ravenscar-sporadic_server_with_callback.adb\r\n [Ada] gnatcoll-utils.adb\r\n [Ada] gnatcoll-pools.adb\r\n [Ada] gnatcoll-scripts-shell.adb\r\ngnatcoll-utils.adb:618:34: warning: pragma Unreferenced given for \"Result\" [enabled by default]\r\ngnatcoll-io-remote-windows.adb:496:36: warning: pragma Unreferenced given for \"Status\" [enabled by default]\r\ngnatcoll-io-remote-unix.adb:409:36: warning: pragma Unreferenced given for \"Status\" [enabled by default]\r\ngnatcoll-io-remote-unix.adb:434:36: warning: pragma Unreferenced given for \"Status\" [enabled by default]\r\ngnatcoll-scripts-shell.adb:38:06: warning: unnecessary with of ancestor [-gnatwr]\r\n\r\n compilation of gnatcoll-scripts-shell.adb failed\r\n compilation of gnatcoll-utils.adb failed\r\n compilation of gnatcoll-io-remote-unix.adb failed\r\n compilation of gnatcoll-io-remote-windows.adb failed\r\n\r\ngprbuild: *** compilation phase failed\r\n```","issue_id":1660428198474,"origin_id":1105954734,"user_origin_id":452,"create_time":1650596576,"update_time":1650596576,"id":1665494292175,"updated_at":"2022-10-11T13:18:12.175000Z","created_at":"2022-10-11T13:18:12.175000Z"},{"_id":"63456d14b918e158f314c798","body":"@yrashk See issue #960 - these warnings (there are others) are because of a change to the semantics of `pragma Unreferenced` - it used to mean just \"never read, even though assigned\" as well as \"never referenced\", but now it means just \"never referenced\".\r\n\r\nThis builds OK:\r\n```\r\ngprbuild -j0 -Palr_env -XOS=macOS -gnatwn\r\n```\r\n","issue_id":1660428198474,"origin_id":1106208393,"user_origin_id":1824512,"create_time":1650617659,"update_time":1650617659,"id":1665494292178,"updated_at":"2022-10-11T13:18:12.177000Z","created_at":"2022-10-11T13:18:12.177000Z"},{"_id":"63456d14b918e158f314c799","body":"Building from master with commit 63820d3, gnat-native=11.2.4, gprbuild=21.0.2, is successful.\r\n\r\nHowever, there\u2019s some weirdness with `CLIC_LIBRARY_TYPE=static` vs `LIBRARY_TYPE=static-pic`:\r\n```\r\ndetail: Env: Alire sets 'True' to 'ALIRE'\r\ndebug: Skipping identical key value: ALIRE=True\r\ndebug: Setenv ALIRE=True\r\ndebug: Setenv BUILD=DEBUG\r\ndebug: Setenv CLIC_LIBRARY_TYPE=static\r\ndebug: Setenv GNATCOLL_OS=osx\r\ndebug: Setenv GPR_PROJECT_PATH=...\r\ndebug: Setenv LIBRARY_TYPE=static-pic\r\ndebug: Setenv OS=macOS\r\ndebug: Setenv PATH=...\r\n```\r\nI tried using `git bisect` to see where the change happened; was OK by f6b58d7, but the build totally failed at bec5bd0 because clic and stopwatch were missing.","issue_id":1660428198474,"origin_id":1106484368,"user_origin_id":1824512,"create_time":1650631959,"update_time":1650631959,"id":1665494292180,"updated_at":"2022-10-11T13:18:12.180000Z","created_at":"2022-10-11T13:18:12.180000Z"},{"_id":"63456d14b918e158f314c79a","body":"The build succeeds at e6e19a7 (28 Sep 2021), but this commit isn\u2019t in v1.2.2 (27 Jan 2022).\r\ne6e19a7 is \"Enable and update self-build\" - the lack of this might explain this issue?","issue_id":1660428198474,"origin_id":1106511825,"user_origin_id":1824512,"create_time":1650633782,"update_time":1650633782,"id":1665494292183,"updated_at":"2022-10-11T13:18:12.183000Z","created_at":"2022-10-11T13:18:12.183000Z"},{"_id":"63456d14b918e158f314c79b","body":"Thanks for the investigation, Simon. So I understand the problem is only with `alr build`ing alr itself on v1.1.2 due to missing https:\/\/github.com\/alire-project\/alire\/commit\/e6e19a74656e4b9c6077d158d6096fe604a10c57","issue_id":1660428198474,"origin_id":1106586214,"user_origin_id":264377,"create_time":1650638589,"update_time":1650638589,"id":1665494292185,"updated_at":"2022-10-11T13:18:12.185000Z","created_at":"2022-10-11T13:18:12.185000Z"},{"_id":"63456d14b918e158f314c79c","body":"@mosteo after the next release, building Alire with Alire should probably be the main workflow.","issue_id":1660428198474,"origin_id":1106634738,"user_origin_id":12136138,"create_time":1650641926,"update_time":1650641926,"id":1665494292188,"updated_at":"2022-10-11T13:18:12.188000Z","created_at":"2022-10-11T13:18:12.188000Z"},{"_id":"63456d14b918e158f314c79d","body":"@mosteo Yes, the problem is half-solved with V1.1.2 + e6e19a7; after fixing up the conflicts the build starts, but fails later,\r\n```\r\nalire-properties-configurations.adb:48:19: no selector \"Item_Kind\" for private type \"TOML_Value\" defined at toml.ads:35\r\nalire-properties-configurations.adb:140:19: no selector \"Item_Kind\" for private type \"TOML_Value\" defined at toml.ads:35\r\nalire-properties-configurations.adb:141:62: no selector \"Item_Kind\" for private type \"TOML_Value\" defined at toml.ads:35\r\nalire-properties-configurations.adb:704:44: no selector \"Item_Kind_Set\" for private type \"TOML_Value\" defined at toml.ads:35\r\nalire-properties-configurations.adb:706:41: no selector \"Item_Kind\" for private type \"TOML_Value\" defined at toml.ads:35\r\n```","issue_id":1660428198474,"origin_id":1106701087,"user_origin_id":1824512,"create_time":1650647073,"update_time":1650647073,"id":1665494292191,"updated_at":"2022-10-11T13:18:12.190000Z","created_at":"2022-10-11T13:18:12.190000Z"}]

Checked out alire at tag v1.1.2 on my M1 machine, and used the downloaded x86_64 alr to build (alr build): ``` ... [mkdir] object directory for project URI [mkdir] exec...

Building alr with GCC-12.0.1

[{"_id":"6345787e09a35269b781018a","body":">I'm sure - without actually trying - that it'd be the same on x86_64\r\n\r\nIt is.","issue_id":1660428198552,"origin_id":1083355932,"user_origin_id":1824512,"create_time":1648657485,"update_time":1648657485,"id":1665497214121,"updated_at":"2022-10-11T14:06:54.120000Z","created_at":"2022-10-11T14:06:54.120000Z"},{"_id":"6345787e09a35269b781018b","body":"Thanks for the report, Simon.","issue_id":1660428198552,"origin_id":1084371340,"user_origin_id":264377,"create_time":1648721617,"update_time":1648721617,"id":1665497214124,"updated_at":"2022-10-11T14:06:54.124000Z","created_at":"2022-10-11T14:06:54.124000Z"},{"_id":"6345787e09a35269b781018c","body":"Hi @mosteo \r\n\r\nJust successfully built `alr` using the *Build* instructions from the repository's `README.md`, and using @simonjwright native Apple Silicon `arm64` version of `GNAT` here: [aarch64-apple-darwin21-2](https:\/\/github.com\/simonjwright\/distributing-gcc\/releases\/tag\/aarch64-apple-darwin21-2)\r\n\r\nHit the same bug I think, with the following output:\r\n```console\r\n [Ada] gnatcoll-io-remote-unix.adb\r\ngnatcoll-io-remote-windows.adb:496:36: warning: pragma Unreferenced given for \"Status\" [enabled by default]\r\ngnatcoll-io-remote-unix.adb:409:36: warning: pragma Unreferenced given for \"Status\" [enabled by default]\r\ngnatcoll-io-remote-unix.adb:434:36: warning: pragma Unreferenced given for \"Status\" [enabled by default]\r\n\r\n compilation of gnatcoll-io-remote-unix.adb failed\r\n compilation of gnatcoll-io-remote-windows.adb failed\r\n\r\ngprbuild: *** compilation phase failed\r\n```\r\n\r\nUsed the suggested work around from Simon above, and instead built with: `gprbuild -j0 -Palr_env -XOS=macOS -gnatws`\r\n\r\nAll working now - so better get back to programming in Ada again, and using `alr` after a two years hiatus :)\r\n\r\n```\r\n% file .\/alr \r\nalr: Mach-O 64-bit executable arm64\r\n\r\n% .\/alr version\r\nAPPLICATION \r\nalr version: 1.2.0-dev \r\nlibalire version: 1.2.0-dev \r\ncompilation date: 2022-04-01 14:48:59 \r\ncompiler version: 12.0.1 20220312 (experimental) \r\n \r\nCONFIGURATION \r\nconfig folder: \/Users\/simon\/.config\/alire \r\nforce flag: FALSE \r\nnon-interactive flag: FALSE \r\ncommunity index branch: stable-1.1 \r\nindexes folder: \/Users\/simon\/.config\/alire\/indexes\r\nindexes metadata: OK \r\ntoolchain assistant: enabled \r\ntool #1 gnat: not configured \r\ntool #2 gprbuild: not configured \r\n \r\nWORKSPACE \r\nroot status: VALID \r\nroot release: alr=1.2.0-dev \r\nroot load error: none \r\nroot folder: \/Users\/simon\/scratch\/ada\/alire \r\ncurrent folder: \/Users\/simon\/scratch\/ada\/alire \r\n \r\nSYSTEM \r\ndistribution: DISTRO_UNKNOWN \r\nhost-arch: ARCHITECTURE_UNKNOWN \r\nos: MACOS \r\ntarget: NATIVE \r\ntoolchain: USER \r\nword-size: BITS_64 \r\n```\r\n","issue_id":1660428198552,"origin_id":1085942817,"user_origin_id":6184230,"create_time":1648821787,"update_time":1648821787,"id":1665497214127,"updated_at":"2022-10-11T14:06:54.127000Z","created_at":"2022-10-11T14:06:54.127000Z"},{"_id":"6345787e09a35269b781018d","body":"> Used the suggested work around from Simon above, and instead built with: gprbuild -j0 -Palr_env -XOS=macOS -gnatws\r\n\r\nI think `-gnatwn` (normal warning mode (cancels -gnatws\/-gnatwe)) would have been better.","issue_id":1660428198552,"origin_id":1085955257,"user_origin_id":1824512,"create_time":1648822341,"update_time":1648822341,"id":1665497214130,"updated_at":"2022-10-11T14:06:54.130000Z","created_at":"2022-10-11T14:06:54.130000Z"},{"_id":"6345787e09a35269b781018e","body":">The warnings in e.g. alire-hashes.ads appear to be a genuine compiler problem: how is Char not used in\r\n\r\n > function Is_Well_Formed (Hash_Img : String) return Boolean is\r\n (for some Char of Hash_Img => Char = ':' and then\r\n Is_Known (Utils.Head (Hash_Img, ':')));\r\n\r\nTurns out that what they want is to put the `for some Char of Hash_Img => Char = ':'` part in parens - makes sense if you think about it. I suppose `conjunct`, `disjunct` are terms of art in the formal methods world - see [Wikipedia](https:\/\/en.wikipedia.org\/wiki\/Logical_conjunction) for `conjunct`.","issue_id":1660428198552,"origin_id":1085988370,"user_origin_id":1824512,"create_time":1648824214,"update_time":1648824214,"id":1665497214133,"updated_at":"2022-10-11T14:06:54.132000Z","created_at":"2022-10-11T14:06:54.132000Z"},{"_id":"6345787e09a35269b781018f","body":"Great news all around. I do wonder about the `host-arch: ARCHITECTURE_UNKNOWN` bit. What is the the output of `uname -m` in these machines?","issue_id":1660428198552,"origin_id":1086171720,"user_origin_id":264377,"create_time":1648834770,"update_time":1648834770,"id":1665497214135,"updated_at":"2022-10-11T14:06:54.135000Z","created_at":"2022-10-11T14:06:54.135000Z"},{"_id":"6345787e09a35269b7810190","body":"Yes - definitely nice to know it is working \ud83d\udc4d \r\n\r\nA couple of `uname` outputs below for reference:\r\n```\r\n% uname -m \r\narm64\r\n\r\n# MacBook Pro (Apple M1 Pro)\r\n% uname -a\r\nDarwin cogentmoons.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15\/RELEASE_ARM64_T6000 arm64\r\n\r\n# Mac mini (Apple M1)\r\n% uname -a\r\nDarwin minimoons.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:47:26 PDT 2022; root:xnu-8020.101.4~15\/RELEASE_ARM64_T8101 arm64\r\n```\r\n\r\nThere is also a few similar commands to `uname -m` - but not sure if they are unique to macOS though:\r\n```\r\n# outputs the same on Mac mini and MacBook Pro \r\n% machine\r\narm64e\r\n\r\n% arch\r\narm64\r\n```\r\n\r\nThey are both recently updated macOS systems:\r\n```\r\n% sw_vers \r\nProductName:\tmacOS\r\nProductVersion:\t12.3.1\r\nBuildVersion:\t21E258\r\n```\r\n\r\nLet me know if you need anything else :)\r\n","issue_id":1660428198552,"origin_id":1086182534,"user_origin_id":6184230,"create_time":1648835663,"update_time":1648835663,"id":1665497214138,"updated_at":"2022-10-11T14:06:54.137000Z","created_at":"2022-10-11T14:06:54.137000Z"},{"_id":"6345787e09a35269b7810191","body":"Thanks for that info, Simon. Indeed we do not have `arm64` as a known architecture. Do you know if that would be equivalent to `aarch64`?","issue_id":1660428198552,"origin_id":1087437842,"user_origin_id":264377,"create_time":1649071603,"update_time":1649071603,"id":1665497214140,"updated_at":"2022-10-11T14:06:54.140000Z","created_at":"2022-10-11T14:06:54.140000Z"},{"_id":"6345787e09a35269b7810192","body":"As far as I can see, `arm64` is equivalent to `aarch64`.","issue_id":1660428198552,"origin_id":1087460833,"user_origin_id":12136138,"create_time":1649073239,"update_time":1649073239,"id":1665497214144,"updated_at":"2022-10-11T14:06:54.143000Z","created_at":"2022-10-11T14:06:54.143000Z"},{"_id":"6345787e09a35269b7810193","body":"So do we want to conflate both in our detection process?","issue_id":1660428198552,"origin_id":1087465153,"user_origin_id":264377,"create_time":1649073569,"update_time":1649073569,"id":1665497214147,"updated_at":"2022-10-11T14:06:54.146000Z","created_at":"2022-10-11T14:06:54.146000Z"},{"_id":"6345787e09a35269b7810194","body":"Hi Alejandro\r\n\r\nI am by no means an authority on *ARM* chipsets - but from what I understand they are both 'equivalent' as you suggest.\r\n\r\nThe `aarch64` is generally the 64bit version of the *ARM* architecture, that came after the 32bit `aarch32` equivalent.\r\n\r\nThe `arm64` is Apple's *version* of that architecture, licensed from *ARM*, but adapted to suit Apple's needs. \r\n\r\nI suppose Apple's `arm64` just differentiates it from the existing `aarch64` used in computers such as *Raspberry Pi* for example, Amazon [Graviton](https:\/\/www.arm.com\/partners\/aws), or Microsoft's use of SQ1 or SQ2 ARM processor in their [Surface X](https:\/\/en.wikipedia.org\/wiki\/Surface_Pro_X) computers, and so on. I think all those would be `aarch64`, but also known by the names: `arm64`; `Graviton`; `SQ2`; etc.\r\n\r\nMy understanding is that all ARM `aarch64` processors would be the same 'equivalent' family - but have quite different features, capabilities and so on. \r\n\r\nThere is a better `aarch64` explanation on [Wikipedia aarch64 page](https:\/\/en.wikipedia.org\/wiki\/AArch64). From an *Apple* perspective, there is also a [Wikipedia Apple Silicon page](https:\/\/en.wikipedia.org\/wiki\/Apple_silicon) that includes some `M1` processor information too.\r\n\r\nApple has some specific information here: [Writing ARM64 Code for Apple Platforms](https:\/\/developer.apple.com\/documentation\/xcode\/writing-arm64-code-for-apple-platforms) in case that is useful.\r\n\r\nSimon \r\n\r\n","issue_id":1660428198552,"origin_id":1087487009,"user_origin_id":6184230,"create_time":1649074893,"update_time":1649074893,"id":1665497214149,"updated_at":"2022-10-11T14:06:54.149000Z","created_at":"2022-10-11T14:06:54.149000Z"},{"_id":"6345787e09a35269b7810195","body":"> So do we want to conflate both in our detection process?\r\n\r\nSorry - my reply crossed over with your exchange with Fabien :)\r\n\r\nIf it helps - my view would be keep it simple, so no. \r\n\r\nShowing `aarch64` would be correct. The fact the `alr` version outputs also include `os: MACOS` would be enough to know it is and Apple computer using `aarch64` vs a Raspberry Pi running Linux as `aarch64` too.\r\n\r\nOthers might disagree, but I am sure it could be updated in the future if there was a strong enough argument to do different \ud83d\udc4d ","issue_id":1660428198552,"origin_id":1087495967,"user_origin_id":6184230,"create_time":1649075489,"update_time":1649075489,"id":1665497214151,"updated_at":"2022-10-11T14:06:54.151000Z","created_at":"2022-10-11T14:06:54.151000Z"},{"_id":"6345787e09a35269b7810196","body":"I would translate `arm64` to `aarch64`, it's the standard name for this architecture.\r\n\r\nLooks like Apple started they LLVM backend as `arm64` but it was later merged with the \"official\" `aarch64`.\r\nThis could explain their use of `arm64` in `uname`.\r\n\r\nSee:\r\n - https:\/\/stackoverflow.com\/questions\/31851611\/differences-between-arm64-and-aarch64\r\n - https:\/\/www.phoronix.com\/scan.php?page=news_item&px=MTY5ODk\r\n - https:\/\/github.com\/llvm-mirror\/llvm\/commit\/29f94c72014eaa5d0d3b920686e689e79759cacb\r\n","issue_id":1660428198552,"origin_id":1087522986,"user_origin_id":12136138,"create_time":1649077186,"update_time":1649077186,"id":1665497214154,"updated_at":"2022-10-11T14:06:54.153000Z","created_at":"2022-10-11T14:06:54.153000Z"},{"_id":"6345787e09a35269b7810197","body":"I see, thanks for the info Simon and Fabien. I'll fix our detection then, as I see no need to distinguish them.","issue_id":1660428198552,"origin_id":1087529908,"user_origin_id":264377,"create_time":1649077472,"update_time":1649077472,"id":1665497214156,"updated_at":"2022-10-11T14:06:54.155000Z","created_at":"2022-10-11T14:06:54.155000Z"}]

(This build is with aarch64-apple-darwin21 **!!!**, but I'm sure - without actually trying - that it'd be the same on x86_64. Found on alire tag 1.1.2, same on master) I...

Homebrew on macOS

[{"_id":"636ac619ea01ec786e8e0fb6","body":"Thanks a lot @simonjwright !\r\n\r\n I commented on PR for code details.\r\n\r\n> * Is `macos` OK for `Alire.Platforms.Distribution`? (actually `MacOS`). Obviously the test that failed above needs fixing!\r\n\r\nAs I said on the PR, the distribution should be `Homebrew`.\r\n\r\n> * Is there a way of running github actions for testing crates using this version of `alr` from my repo?\r\n\r\nI am not sure, we have the Crate CI stuff but I don't know if you can use it (@mosteo ).\r\n \r\n> * What would the process be for amending external manifests, e.g. `sdl2`, `sdl2_ttf`, `sdl2_image`? We could invite Mac users to make\/propose changes as needed?\r\n\r\nOnce we have this merged in Alire, we can have an extra CI platform that is macOS + Homebew and then you will be able to op PR on the community index to add Homebew packages to the externals.\r\n\r\n>> * What would the process be for amending crates that could use this ability, e.g. `sdlada` (which is maintained by @mosteo but authored by Luke Guest), and ought to use `$HOMEBREW_PREFIX` to find include & library files (Homebrew don't recommend moving it from its default location, but the default location is different between x86_64 and aarch64!)\r\n\r\nIf it's a change to the code then you have to see with the authors. If it's a change to the manifest then we can review it.\r\n","issue_id":1664550777134,"origin_id":1245474477,"user_origin_id":12136138,"create_time":1663078402,"update_time":1663078402,"id":1667941913963,"updated_at":"2022-11-08T21:11:53.962000Z","created_at":"2022-11-08T21:11:53.962000Z"}]

I've been working on integrating Homebrew into Alire. I've got it to a point where it works for me; I patched up the [ci-linux](https://github.com/simonjwright/alire/actions/runs/2988808227) and [ci-macos](https://github.com/simonjwright/alire/actions/runs/2988808226) workflows, the only reasons...

Error building libgomp.dylib

[{"_id":"66b92d4f8591337c3c05a59f","body":"hmm.. \r\n\r\n* I had a successful bootstrap using GCC-11.4 (including Ada, D, m2 and rust); using XC CLT-14.3 on aarch64-darwin21. I see you have a whole bunch of configure options, some of which are unnecessary and some of which I do not use\/test.\r\n\r\n* non-bootstrap builds from a different compiler version are not really supported - does a bootstrap work correctly?\r\n\r\n* I have XC CLT 15.1b for which the assembler does not run on darwin21, will have to update if it now works.\r\n","issue_id":1704166943888,"origin_id":1823184188,"user_origin_id":4039407,"create_time":1700673570,"update_time":1700673570,"id":1723411791588,"updated_at":"2024-08-11T21:29:51.588000Z","created_at":"2024-08-11T21:29:51.588000Z"},{"_id":"66b92d4f8591337c3c05a5a0","body":"> * I had a successful bootstrap using GCC-11.4 (including Ada, D, m2 and rust); using XC CLT-14.3 on aarch64-darwin21. I see you have a whole bunch of configure options, some of which are unnecessary and some of which I do not use\/test.\r\n\r\nNow that I have a working `gcc-13.1.0-aarch64` I've stopped building the cross-compiler first; is this wrong?\r\n\r\nI guess the `--with-as` etc. configure options aren't needed, would be interesting to have a recommended set! There's some cargo-culting going on here, admittedly.\r\n\r\n> * non-bootstrap builds from a different compiler version are not really supported - does a bootstrap work correctly?\r\n\r\nNo, fails exactly the same in stage 1.\r\n\r\n> * I have XC CLT 15.1b for which the assembler does not run on darwin21, will have to update if it now works.\r\n\r\nI've probably given the wrong impression here; both my aarch64 machines are running Sonoma (14.1.1), I set `MACOSX_DEPLOYMENT_TARGET=12` to support users who haven't yet upgraded, for whatever reason.\r\n\r\nI think we have an issue with XC CLT 15.1b3 (and possibly earlier), because the `libgomp.dylib` issue goes away if I build with CLT 14.2.\r\n","issue_id":1704166943888,"origin_id":1825871563,"user_origin_id":1824512,"create_time":1700842467,"update_time":1700842467,"id":1723411791592,"updated_at":"2024-08-11T21:29:51.591000Z","created_at":"2024-08-11T21:29:51.591000Z"},{"_id":"66b92d4f8591337c3c05a5a1","body":"> This is with commit [31499d1](https:\/\/github.com\/iains\/gcc-darwin-arm64\/commit\/31499d17fefbb7afd90e99b2354e0f1db9786a0f) of 2023-11-22.\r\n> \r\n> Build compiler: GCC 13.1.0, aarch64-apple-darwin21\r\n> \r\n> ```\r\n> ld: address=0x0 points to section(3) with no content in '\/Volumes\/Miscellaneous3\/aarch64\/14.0.0\/gcc\/aarch64-apple-darwin21\/libgomp\/.libs\/target-indirect.o'\r\n> ```\r\n\r\nIt turns out that this is yet another `ld-classic` problem. Successfully built using a shim:\r\n```\r\n#!\/bin\/sh\r\n\r\nclassic=$(xcrun --find ld-classic 2>\/dev\/null) || true\r\n\r\nif [ -n \"$classic\" ]; then\r\n exec $classic \"$@\"\r\nelse\r\n exec ld \"$@\"\r\nfi\r\n```\r\n\r\nMore to come on this over at https:\/\/github.com\/iains\/gcc-13-branch\/issues\/10\r\n","issue_id":1704166943888,"origin_id":1826386703,"user_origin_id":1824512,"create_time":1700934770,"update_time":1700934770,"id":1723411791595,"updated_at":"2024-08-11T21:29:51.595000Z","created_at":"2024-08-11T21:29:51.595000Z"},{"_id":"66b92d4f8591337c3c05a5a2","body":"Have you reported the issue to Apple?","issue_id":1704166943888,"origin_id":1826848070,"user_origin_id":1980544,"create_time":1701021542,"update_time":1701021542,"id":1723411791599,"updated_at":"2024-08-11T21:29:51.599000Z","created_at":"2024-08-11T21:29:51.599000Z"},{"_id":"66b92d4f8591337c3c05a5a3","body":"> Have you reported the issue to Apple?\r\n\r\nFB13416813\r\n\r\nMind, after having submitted the report I dug a bit further. Turns out that `target-indirect.c` is\r\n```\r\nvoid *\r\nGOMP_target_map_indirect_ptr (void *ptr)\r\n{\r\n \/* Calls to this function should not be generated for host code. *\/\r\n __builtin_unreachable ();\r\n}\r\n```\r\n\r\nCompiling this with gcc-13.1.0-x86_64 gives a sensible-looking EH_frame, but compiling with gcc-13.1.0-aarch64 gives this, which looks garbled to me:\r\n```\r\n$ objdump -h target-indirect.o\r\n\r\ntarget-indirect.o:\tfile format mach-o arm64\r\n\r\nSections:\r\nIdx Name Size VMA Type\r\n 0 __text 00000000 0000000000000000 TEXT\r\n 1 __text_cold 00000000 0000000000000000 TEXT\r\n 2 __eh_frame 00000038 0000000000000000 DATA\r\n\r\n$ objdump -D target-indirect.o\r\n\r\ntarget-indirect.o:\tfile format mach-o arm64\r\n\r\nDisassembly of section __TEXT,__eh_frame:\r\n\r\n0000000000000000 <ltmp2>:\r\n 0: 00000014 \tudf\t#20\r\n 4: 00000000 \tudf\t#0\r\n 8: 00527a01 \t<unknown>\r\n c: 011e7801 \t<unknown>\r\n 10: 001f0c10 \t<unknown>\r\n 14: 00000000 \tudf\t#0\r\n 18: 0000001c \tudf\t#28\r\n 1c: 0000001c \tudf\t#28\r\n 20: ffffffe0 \t<unknown>\r\n 24: ffffffff \t<unknown>\r\n\t\t...\r\n```","issue_id":1704166943888,"origin_id":1828306193,"user_origin_id":1824512,"create_time":1701106317,"update_time":1701106317,"id":1723411791603,"updated_at":"2024-08-11T21:29:51.602000Z","created_at":"2024-08-11T21:29:51.602000Z"},{"_id":"66b92d4f8591337c3c05a5a4","body":"`target-indirect.c` appears to have been added in a49c7d3; it\u2019s in `config\/accel\/` and `config\/linux\/` -- we\u2019ve picked up the linux version, the accel version is much more substantial.","issue_id":1704166943888,"origin_id":1828326162,"user_origin_id":1824512,"create_time":1701107111,"update_time":1701107111,"id":1723411791606,"updated_at":"2024-08-11T21:29:51.606000Z","created_at":"2024-08-11T21:29:51.606000Z"},{"_id":"66b92d4f8591337c3c05a5a5","body":"The feedback (FB13416813) has been updated:\r\n\r\n>The error is related to the _GOMP_target_map_indirect_ptr symbol, located in the __TEXT, __text_cold section. This entire section is empty, so the symbol has no content, but there\u2019s still a dwarf unwind entry referencing it. You might be able to workaround this error by either removing this symbol, or making sure it has some content.","issue_id":1704166943888,"origin_id":1841005875,"user_origin_id":1824512,"create_time":1701789610,"update_time":1701789610,"id":1723411791611,"updated_at":"2024-08-11T21:29:51.610000Z","created_at":"2024-08-11T21:29:51.610000Z"},{"_id":"66b92d4f8591337c3c05a5a6","body":"So that looks like an error on our [GCC's] part (or possibly an assumption that something that works with BFD-linkers is OK everywhere), that has not been detected by earlier linkers.\r\n\r\nsince this is x86_64 the problem happen with unpatched 13.2? If so, then we should have an upstream (GCC bugzilla) for it;\r\n\r\nI'm somewhat tied up with other stuff right now, so not really able to suggest a short-term hack.\r\n","issue_id":1704166943888,"origin_id":1841017886,"user_origin_id":4039407,"create_time":1701789966,"update_time":1701789966,"id":1723411791615,"updated_at":"2024-08-11T21:29:51.615000Z","created_at":"2024-08-11T21:29:51.615000Z"},{"_id":"66b92d4f8591337c3c05a5a7","body":"Using `ld-classic` is probably a good idea anyway for now. I'll try to debug the issue over the week-end and reduce it to a simple case.","issue_id":1704166943888,"origin_id":1847041352,"user_origin_id":1980544,"create_time":1702035976,"update_time":1702035976,"id":1723411791619,"updated_at":"2024-08-11T21:29:51.619000Z","created_at":"2024-08-11T21:29:51.619000Z"},{"_id":"66b92d4f8591337c3c05a5a8","body":"> Using `ld-classic` is probably a good idea anyway for now. I'll try to debug the issue over the week-end and reduce it to a simple case.\r\n\r\nI wonder if we have a case where there's an empty TU for some targets (but then I don't see why we'd end up with a symbol there). [I've not tried to debug, and will most likely not have a chance this week]\r\n","issue_id":1704166943888,"origin_id":1847122647,"user_origin_id":4039407,"create_time":1702040337,"update_time":1702040337,"id":1723411791623,"updated_at":"2024-08-11T21:29:51.623000Z","created_at":"2024-08-11T21:29:51.623000Z"},{"_id":"66b92d4f8591337c3c05a5a9","body":"- I confirm the bug\r\n- `ld -ld_classic` accepts the same object file without even a warning, so clearly it is a regression from Apple\r\n\r\nReduced testcase, with `ld` being the Xcode 15.1 Release Candidate linker:\r\n\r\n```\r\n$ cat a.c\r\nvoid * GOMP_target_map_indirect_ptr (void *ptr) {\r\n __builtin_unreachable ();\r\n}\r\n$ gcc-13 -c a.c -g -O2\r\n$ ld -dynamic -o libtest.dylib a.o -dylib\r\nld: address=0x0 points to section(3) with no content in '\/private\/tmp\/a.o'\r\n```\r\n\r\nclang output makes ld happy:\r\n\r\n```\r\n$ clang -c a.c -g -O2\r\n$ ld -dynamic -o libtest.dylib a.o -dylib\r\n[no error]\r\n```\r\n\r\nTrying to narrow the difference in what is output:\r\n\r\n```\r\n$ clang -c a.c -g -O2\r\n$ nm a.o\r\n0000000000000000 T _GOMP_target_map_indirect_ptr\r\n0000000000000000 t ltmp0\r\n0000000000000220 s ltmp1\r\n$ gcc-13 -c a.c -g -O2 \r\n$ nm a.o\r\n0000000000000028 s EH_frame1\r\n0000000000000000 S _GOMP_target_map_indirect_ptr\r\n0000000000000000 t ltmp0\r\n0000000000000000 s ltmp1\r\n0000000000000000 s ltmp2\r\n0000000000000028 s ltmp3\r\n0000000000000164 s ltmp4\r\n0000000000000197 s ltmp5\r\n00000000000001a9 s ltmp6\r\n```","issue_id":1704166943888,"origin_id":1847683137,"user_origin_id":1980544,"create_time":1702062465,"update_time":1702062465,"id":1723411791626,"updated_at":"2024-08-11T21:29:51.625000Z","created_at":"2024-08-11T21:29:51.625000Z"},{"_id":"66b92d4f8591337c3c05a5aa","body":"> * I confirm the bug\r\n> * `ld -ld_classic` accepts the same object file without even a warning, so clearly it is a regression from Apple\r\n\r\n> Trying to narrow the difference in what is output:\r\n> \r\n> ```\r\n\r\n> $ gcc-13 -c a.c -g -O2 \r\n> $ nm a.o\r\n> 0000000000000028 s EH_frame1\r\n> 0000000000000000 S _GOMP_target_map_indirect_ptr\r\n> 0000000000000000 t ltmp0\r\n> 0000000000000000 s ltmp1\r\n> 0000000000000000 s ltmp2\r\n> 0000000000000028 s ltmp3\r\n> 0000000000000164 s ltmp4\r\n> 0000000000000197 s ltmp5\r\n> 00000000000001a9 s ltmp6\r\n> ```\r\n\r\nplease could you show the output of `objdump -d -r a.o`\r\n\r\nOn my very quick test, I do not see the section being empty (but, instead, containing a single trap instruction)\r\n \r\nedit: FAOD, this is with x86_64, right?\r\n","issue_id":1704166943888,"origin_id":1847696594,"user_origin_id":4039407,"create_time":1702063186,"update_time":1702063272,"id":1723411791629,"updated_at":"2024-08-11T21:29:51.628000Z","created_at":"2024-08-11T21:29:51.628000Z"},{"_id":"66b92d4f8591337c3c05a5ab","body":"specifically, if I compile with `-save-temps` and look at the assembler:\r\n```\r\n .file 1 \"f.c\"\r\n .section __TEXT,__text_cold,regular,pure_instructions\r\n .globl _GOMP_target_map_indirect_ptr\r\n_GOMP_target_map_indirect_ptr:\r\nLFB0:\r\n .loc 1 1 49\r\n .loc 1 2 3\r\n ud2\r\nLFE0:\r\n```\r\n\r\nIf, hypothetically, that is also what you see - but the output of `objdump -d -r` does not look the same, then the issue is with the assembler (i.e. `clang -cc1as`) rather than `ld`.","issue_id":1704166943888,"origin_id":1847708927,"user_origin_id":4039407,"create_time":1702063861,"update_time":1702063861,"id":1723411791632,"updated_at":"2024-08-11T21:29:51.631000Z","created_at":"2024-08-11T21:29:51.631000Z"},{"_id":"66b92d4f8591337c3c05a5ac","body":"Since I am reporting here, I am testing the aarch64-darwin, with the current branch. I don't have a system with Xcode 15.1 on Intel :(\r\n\r\n```\r\nmeau \/tmp $ clang -O2 -g a.c -c\r\nmeau \/tmp $ objdump -d -r a.o\r\n\r\na.o:\tfile format mach-o arm64\r\n\r\nDisassembly of section __TEXT,__text:\r\n\r\n0000000000000000 <ltmp0>:\r\n 0: d4200020 \tbrk\t#0x1\r\nmeau \/tmp $ gcc-13 -O2 -g a.c -c\r\nmeau \/tmp $ objdump -d -r a.o \r\n\r\na.o:\tfile format mach-o arm64\r\nmeau \/tmp $ \r\n```\r\n\r\nThe assembly generated by GCC is:\r\n\r\n```\r\n .arch armv8-a\r\n .text\r\nLtext0:\r\n .file 1 \"a.c\"\r\n .section __TEXT,__text_cold,regular,pure_instructions\r\n .align 2\r\n .globl _GOMP_target_map_indirect_ptr\r\n_GOMP_target_map_indirect_ptr:\r\nLFB0:\r\n .loc 1 1 49\r\n .loc 1 2 3\r\nLFE0:\r\n```\r\n\r\nand by clang:\r\n\r\n```\r\n .section __TEXT,__text,regular,pure_instructions\r\n .build_version macos, 14, 0 sdk_version 14, 2\r\n .globl _GOMP_target_map_indirect_ptr ; -- Begin function GOMP_target_map_indirect_ptr\r\n .p2align 2\r\n_GOMP_target_map_indirect_ptr: ; @GOMP_target_map_indirect_ptr\r\nLfunc_begin0:\r\n .file 1 \"\/tmp\" \"a.c\"\r\n .loc 1 1 0 ; a.c:1:0\r\n .cfi_startproc\r\n; %bb.0:\r\n .loc 1 2 3 prologue_end ; a.c:2:3\r\n brk #0x1\r\nLtmp0:\r\nLfunc_end0:\r\n .cfi_endproc\r\n```\r\n\r\n","issue_id":1704166943888,"origin_id":1847801057,"user_origin_id":1980544,"create_time":1702067119,"update_time":1702067119,"id":1723411791634,"updated_at":"2024-08-11T21:29:51.634000Z","created_at":"2024-08-11T21:29:51.634000Z"},{"_id":"66b92d4f8591337c3c05a5ad","body":"> Since I am reporting here, I am testing the aarch64-darwin, with the current branch. I don't have a system with Xcode 15.1 on Intel :(\r\n> \r\n\r\n> The assembly generated by GCC is:\r\n> \r\n> ```\r\n> .arch armv8-a\r\n> .text\r\n> Ltext0:\r\n> .file 1 \"a.c\"\r\n> .section __TEXT,__text_cold,regular,pure_instructions\r\n> .align 2\r\n> .globl _GOMP_target_map_indirect_ptr\r\n> _GOMP_target_map_indirect_ptr:\r\n> LFB0:\r\n> .loc 1 1 49\r\n> .loc 1 2 3\r\n> LFE0:\r\n> ```\r\n\r\nThat is different from the x86_64 case (there is indeed no content here) ... whereas....\r\n\r\n> and by clang:\r\n> \r\n> ```\r\n> .section __TEXT,__text,regular,pure_instructions\r\n> .build_version macos, 14, 0 sdk_version 14, 2\r\n> .globl _GOMP_target_map_indirect_ptr ; -- Begin function GOMP_target_map_indirect_ptr\r\n> .p2align 2\r\n> _GOMP_target_map_indirect_ptr: ; @GOMP_target_map_indirect_ptr\r\n> Lfunc_begin0:\r\n> .file 1 \"\/tmp\" \"a.c\"\r\n> .loc 1 1 0 ; a.c:1:0\r\n> .cfi_startproc\r\n> ; %bb.0:\r\n> .loc 1 2 3 prologue_end ; a.c:2:3\r\n> brk #0x1\r\n> Ltmp0:\r\n> Lfunc_end0:\r\n> .cfi_endproc\r\n> ```\r\n\r\n.... clang is putting a trap instruction in.\r\n\r\nSo, on aarch64, we do have a discrepancy - I need to figure out where the aarch64 port decides to\/not to insert the trap.\r\n","issue_id":1704166943888,"origin_id":1847838048,"user_origin_id":4039407,"create_time":1702069263,"update_time":1702069263,"id":1723411791637,"updated_at":"2024-08-11T21:29:51.636000Z","created_at":"2024-08-11T21:29:51.636000Z"},{"_id":"66b92d4f8591337c3c05a5ae","body":"see https:\/\/gcc.gnu.org\/bugzilla\/show_bug.cgi?id=109267 and https:\/\/gcc.gnu.org\/bugzilla\/show_bug.cgi?id=57438 (I will have to see if a similar fix can apply to aarch64).\r\n","issue_id":1704166943888,"origin_id":1848340878,"user_origin_id":4039407,"create_time":1702113556,"update_time":1702113556,"id":1723411791640,"updated_at":"2024-08-11T21:29:51.639000Z","created_at":"2024-08-11T21:29:51.639000Z"},{"_id":"66b92d4f8591337c3c05a5af","body":"note that the workaround from PR57438 does also appear to work for aarch64.\r\n`-D__builtin_unreachable=__builtin_trap` \r\n(maybe add that to the recipe for the affected files, rather than globally - although TBH a trap is more user-friendly than UB .. )\r\n","issue_id":1704166943888,"origin_id":1848363376,"user_origin_id":4039407,"create_time":1702117351,"update_time":1702117351,"id":1723411791644,"updated_at":"2024-08-11T21:29:51.643000Z","created_at":"2024-08-11T21:29:51.643000Z"},{"_id":"66b92d4f8591337c3c05a5b0","body":"unfortunately, this remedy does not seem to work for modula-2 (which also has instances of this issue) - so a proper solution is called for - and it seems to be a bit more tricky for aarch64 than the solutions I did for x86 and powerpc.\r\n","issue_id":1704166943888,"origin_id":2038323773,"user_origin_id":4039407,"create_time":1712268192,"update_time":1712268192,"id":1723411791647,"updated_at":"2024-08-11T21:29:51.646000Z","created_at":"2024-08-11T21:29:51.646000Z"},{"_id":"66b92d4f8591337c3c05a5b1","body":"My testing with a cross to aarch64-darwin from x86_64-darwin on macOS 14 with Xcode 15.3b2, suggests that this is working - actually, there is some fallout from the change (but right now, I think that the change actually has identified a second problem - which is not limited to the arm64 port).\r\n\r\nPlease test the latest `master-wip-apple-si` branch; if all goes OK then I'll backport for 13.3, 12.4 and 11.5.\r\n","issue_id":1704166943888,"origin_id":2042743454,"user_origin_id":4039407,"create_time":1712582409,"update_time":1712582409,"id":1723411791649,"updated_at":"2024-08-11T21:29:51.649000Z","created_at":"2024-08-11T21:29:51.649000Z"},{"_id":"66b92d4f8591337c3c05a5b2","body":"> The feedback (FB13416813) has been updated:\r\n> \r\n> > The error is related to the _GOMP_target_map_indirect_ptr symbol, located in the __TEXT, __text_cold section. This entire section is empty, so the symbol has no content, but there\u2019s still a dwarf unwind entry referencing it. You might be able to workaround this error by either removing this symbol, or making sure it has some content.\r\n\r\nWhat is the situation with the FB now?\r\n\r\nWe have just had a long discussion on IRC and on the gcc-patches list about solutions to the underlying problem (empty functions because of any reason - e.g. macro-conditional content, optimised away etc).\r\n\r\nThe assertion of global maintainers is that, generally empty content is to be expected in real-life code.\r\n\r\n```\r\n e.g. asm (\"\"); __builtin_unreachable (); will result in that too (or asm which actually has some large template, but either expands just into a different section, or has macros that yield nothing)\r\n\r\nbut generally, DW_CFA_advance_loc* can always skip over something that is empty and not known at compile time (like inline asms that don't contribute anything to the current section), so generally having something to apply for an empty range is well defined DWARF construct\r\n```\r\n\r\nSo, I can fix the current case (i.e. a function optimised to __builtin_unreachable) to produce a trap there - but it seems that there's potentially a wider issue\/\r\n\r\nSince FBs are not public - please could you update ?\r\n\r\n@fxcoudert is this the only FB for the topic? (given that we read it as a regression from ld64)? I wonder if there's some way to either expedite - or if it won't be fixed then to find out soon so that we can try to react in the compiler.\r\n\r\n","issue_id":1704166943888,"origin_id":2044435932,"user_origin_id":4039407,"create_time":1712651299,"update_time":1712651299,"id":1723411791653,"updated_at":"2024-08-11T21:29:51.652000Z","created_at":"2024-08-11T21:29:51.652000Z"},{"_id":"66b92d4f8591337c3c05a5b3","body":"> Since FBs are not public - please could you update ?\r\n\r\nThere\u2019s been no update to the FB since my last report.\r\n\r\nMy report was\r\n\r\n----\r\n\r\nThe file target-indirect.o is generated as part of libgomp.dylib during GCC 14.0.0 build for arm64 (sources at https:\/\/github.com\/iains\/gcc-darwin-arm64).\r\n\r\nWhile doing the link to produce the dylib, ld reports\r\n ld: address=0x0 points to section(3) with no content in '\/Users\/simon\/Developer\/bugs\/gcc\/ld_classic\/.libs\/target-indirect.o'\r\n\r\nI've created an attachment (target-indirect.zip) containing the object file concerned.\r\n\r\nWith ld:\r\n $ ld -dylib -o libgomp.dylib objs\/*.o -no_compact_unwind -syslibroot $(xcrun --show-sdk-path) -lSystem\r\n ld: address=0x0 points to section(3) with no content in '\/Users\/simon\/Developer\/bugs\/gcc\/ld_classic\/objs\/target-indirect.o'\r\n\r\nUsing ld-classic\r\n $ $(xcrun --find ld-classic) -dylib -o libgomp.dylib objs\/*.o -no_compact_unwind -syslibroot $(xcrun --show-sdk-path) -lSystem\r\nruns successfully.\r\n\r\n----\r\n\r\nThe response was\r\n\r\n----\r\n\r\nThe error is related to the _GOMP_target_map_indirect_ptr symbol, located in the __TEXT, __text_cold section. This entire section is empty, so the symbol has no content, but there\u2019s still a dwarf unwind entry referencing it. You might be able to workaround this error by either removing this symbol, or making sure it has some content.\r\n\r\n----\r\n\r\nand the summary at the top is\r\n\r\n----\r\n\r\nRecent Similar Reports: None\r\nResolution: Investigation complete - Works as currently designed","issue_id":1704166943888,"origin_id":2045911515,"user_origin_id":1824512,"create_time":1712690681,"update_time":1712690681,"id":1723411791656,"updated_at":"2024-08-11T21:29:51.655000Z","created_at":"2024-08-11T21:29:51.655000Z"},{"_id":"66b92d4f8591337c3c05a5b4","body":"\r\n> and the summary at the top is\r\n> \r\n> Recent Similar Reports: None Resolution: Investigation complete - Works as currently designed\r\n\r\nWhich I translate as \"we are not going to fix this, it's your problem to generate code that does not cause this\".\r\n\r\n@fxcoudert do you know of any other FBs in the system?\r\n\r\n","issue_id":1704166943888,"origin_id":2045915650,"user_origin_id":4039407,"create_time":1712690871,"update_time":1712690871,"id":1723411791658,"updated_at":"2024-08-11T21:29:51.657000Z","created_at":"2024-08-11T21:29:51.657000Z"},{"_id":"66b92d4f8591337c3c05a5b5","body":"> @fxcoudert do you know of any other FBs in the system?\r\n\r\nNot aware of any, will ping that one.","issue_id":1704166943888,"origin_id":2046784091,"user_origin_id":1980544,"create_time":1712735401,"update_time":1712735401,"id":1723411791661,"updated_at":"2024-08-11T21:29:51.660000Z","created_at":"2024-08-11T21:29:51.660000Z"},{"_id":"66b92d4f8591337c3c05a5b6","body":"> Please test the latest `master-wip-apple-si` branch; if all goes OK then I'll backport for 13.3, 12.4 and 11.5.\r\n\r\nI just did a bootstrap (C, C++, Ada) on M1 macOs 14.4.1, CLT 15.3, base compiler 13.2.0-aarch64; built without issues.","issue_id":1704166943888,"origin_id":2048265927,"user_origin_id":1824512,"create_time":1712776368,"update_time":1712776368,"id":1723411791664,"updated_at":"2024-08-11T21:29:51.663000Z","created_at":"2024-08-11T21:29:51.663000Z"},{"_id":"66b92d4f8591337c3c05a5b7","body":"I believe that this is fixed on the development branch, and will be back ported to 13.3, 12.4 and 11.5.\r\n","issue_id":1704166943888,"origin_id":2053970543,"user_origin_id":4039407,"create_time":1713084572,"update_time":1713084572,"id":1723411791666,"updated_at":"2024-08-11T21:29:51.666000Z","created_at":"2024-08-11T21:29:51.666000Z"}]

This is with commit 31499d1 of 2023-11-22. Build compiler: GCC 13.1.0, aarch64-apple-darwin21 ``` ld: address=0x0 points to section(3) with no content in '/Volumes/Miscellaneous3/aarch64/14.0.0/gcc/aarch64-apple-darwin21/libgomp/.libs/target-indirect.o' ``` Configure script, with `$BUILD=aarch64-apple-darwin21` `$SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk` where...

File names case-sensitive (Ada-related)

[{"_id":"66b92d4579464377af099d30","body":"Typically, my **build** and **sources** disks **are** case-sensitive and I set GNAT_FILE_NAME_CASE_SENSITIVE in my .profile and I've not seen issues in building the compiler on either x86_64 or aarch64 macOS (once in a while I have built on a non CS disk again without issue).\r\n\r\nActually, since Catalina or so I do not see (the previously unwise) issue with making the OS disk CS either - since the OS is stored on a non-CS-read-only partition so that it is only the User's dynamic additions that are on a CS writable partition (although this is all 'under the hood' from the perspective of the end user).\r\n\r\nThere are defines that allow detection of macOS c.f. iOS \/ watchOS \/ tvOS .. `PLATFORM_xx` or something similar (from memory). grep should find them in the SDK.\r\n\r\n","issue_id":1704166943910,"origin_id":1341168432,"user_origin_id":4039407,"create_time":1670428299,"update_time":1670428299,"id":1723411781314,"updated_at":"2024-08-11T21:29:41.313000Z","created_at":"2024-08-11T21:29:41.313000Z"},{"_id":"66b92d4579464377af099d31","body":"I had no trouble building the compiler and tools on aarch64-apple-darwin, but then none of the sources use upper-case (or international characters) in filenames so I wouldn\u2019t expect any.\r\n\r\nI found this because one of my users, against advice, or perhaps in ignorance of it, used mixed case for file names, and the compiler (or possibly the build tool, `gprbuild`) couldn\u2019t find the file it needed.\r\n\r\nI thought the problem was that -- if say `\/Applications` is on a CS filesystem -- an applications\u2019 code may assume non-CS and fail when it encounters CS?\r\n\r\nI couldn\u2019t see the SDK defines you mention, so my thoughts on how to progress this are\r\n* issue warnings in release notes to my users,\r\n* (as a last resort) patch out the problematic code in `adaint.c`.","issue_id":1704166943910,"origin_id":1345278001,"user_origin_id":1824512,"create_time":1670682952,"update_time":1670682952,"id":1723411781317,"updated_at":"2024-08-11T21:29:41.317000Z","created_at":"2024-08-11T21:29:41.317000Z"},{"_id":"66b92d4579464377af099d32","body":"> I had no trouble building the compiler and tools on aarch64-apple-darwin, but then none of the sources use upper-case (or international characters) in filenames so I wouldn\u2019t expect any.\r\n\r\nFWIW ( not a justification more an observation ) I started to build all my OSS projects on CS systems because some did assume that they were on CS - not specifically GCC. I have around 120 OSS projects on my sources and build some\/all of them with GCC at times.\r\n\r\nedit : although the sources and builds are on CS - until Catalina, I did keep my OS disk as case-preserving \/ non-CS.\r\n\r\n> I found this because one of my users, against advice, or perhaps in ignorance of it, used mixed case for file names, and the compiler (or possibly the build tool, `gprbuild`) couldn\u2019t find the file it needed.\r\n\r\nAh.. of course, we cannot speak for tools outside of the builds that we do, but a failure to handle CS\/non-CS is a bug, I'd say (CS is usually handled as the default for OSS projects, at least).\r\n\r\n> I thought the problem was that -- if say `\/Applications` is on a CS filesystem -- an applications\u2019 code may assume non-CS and fail when it encounters CS?\r\n\r\nThere were notable huge vendors who released applications that were not safe on CS OS X systems, indeed - but that was 15 years ago .. I'd hope they have the idea by now.\r\n\r\nHowever, I think you are technically correct - post-delivery installations into \/ will be directed to the CS writeable partition.\r\n\r\nFWIW, at this time, I have not seen problems (I've been using CS system since hmm... Catalina, I think) but then I do not install many 3rd-party applications.\r\n\r\n> I couldn\u2019t see the SDK defines you mention, \r\nnevertheless, the information is present - see for example \r\nMacOSX12.sdk\/usr\/include\/\/AvailabilityInternal.h\r\n```\r\n#define __API_AVAILABLE_PLATFORM_macos(x) macos,introduced=x\r\n#define __API_AVAILABLE_PLATFORM_macosx(x) macosx,introduced=x\r\n#define __API_AVAILABLE_PLATFORM_ios(x) ios,introduced=x\r\n#define __API_AVAILABLE_PLATFORM_watchos(x) watchos,introduced=x\r\n```\r\n\r\nSo figuring out how these get their information _should_ work?\r\n\r\nNOTE : GCC at this stage does **NOT** support iOS\/tvOS (and has **not** got the 32b port to support watchOS) so that you could currently assume macOS.\r\n\r\n>so my thoughts on how to progress this \r\n> * issue warnings in release notes to my users,\r\n> * (as a last resort) patch out the problematic code in `adaint.c`.\r\n\r\nunless this appears as a prevalent issue, I'd suggest the former .. for most people thing \"just work\".\r\n","issue_id":1704166943910,"origin_id":1345280889,"user_origin_id":4039407,"create_time":1670683962,"update_time":1670684036,"id":1723411781320,"updated_at":"2024-08-11T21:29:41.319000Z","created_at":"2024-08-11T21:29:41.319000Z"},{"_id":"66b92d4579464377af099d33","body":"looking at clang's output, I'd say you can also use:\r\n```\r\n__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__\r\n__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__\r\n__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__\r\n```\r\netc.\r\n\r\n(edit : GCC will only emit __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ thus far)\r\n","issue_id":1704166943910,"origin_id":1345283428,"user_origin_id":4039407,"create_time":1670684759,"update_time":1670684836,"id":1723411781322,"updated_at":"2024-08-11T21:29:41.322000Z","created_at":"2024-08-11T21:29:41.322000Z"},{"_id":"66b92d4579464377af099d34","body":"I would report this to the Ada maintainers: whether the system is case-sensitive is not a property of the OS at all, it will depend on the filesystem. That code makes no sense.","issue_id":1704166943910,"origin_id":1348585245,"user_origin_id":1980544,"create_time":1670938812,"update_time":1670938820,"id":1723411781325,"updated_at":"2024-08-11T21:29:41.325000Z","created_at":"2024-08-11T21:29:41.325000Z"},{"_id":"66b92d4579464377af099d35","body":"I guess the only 'tactical' difference is, that with iOS, the end user has no influence over the FS type (so if you know the target is iOS you can decide), but with macOS this no longer holds.\r\n\r\nAs of now, GCC (as supported here, and upstream) does not support iOS - therefore we have to assume that the user could change the FS kind (I certainly do). The Ada components honour GNAT_FILE_NAME_CASE_SENSITIVE, so AFAICT that is usable. Can we close this issue, since it appears to be either something that should be raised upstream (it would manifest on x86_64 I presume)?","issue_id":1704166943910,"origin_id":1565303123,"user_origin_id":4039407,"create_time":1685179383,"update_time":1685179383,"id":1723411781328,"updated_at":"2024-08-11T21:29:41.327000Z","created_at":"2024-08-11T21:29:41.327000Z"},{"_id":"66b92d4579464377af099d36","body":"Related to upstream bug 81114 I think? https:\/\/gcc.gnu.org\/bugzilla\/show_bug.cgi?id=81114 ","issue_id":1704166943910,"origin_id":1763523315,"user_origin_id":1388660,"create_time":1697409240,"update_time":1697409240,"id":1723411781331,"updated_at":"2024-08-11T21:29:41.330000Z","created_at":"2024-08-11T21:29:41.330000Z"},{"_id":"66b92d4579464377af099d37","body":"perhaps, but the phenomenon we are discussing here is not with older OS revisions - but actually with the \"latest and greatest\" .. my speculation is that HFS+ does some translation between the call and the disk - but APFS does not (and so if the supplied string is incompatible, it just punts instead of converting).\r\n\r\nI'd say that this is a job for the runtime librar(ies) to sort out.\r\n","issue_id":1704166943910,"origin_id":1763524933,"user_origin_id":4039407,"create_time":1697409670,"update_time":1697409670,"id":1723411781333,"updated_at":"2024-08-11T21:29:41.332000Z","created_at":"2024-08-11T21:29:41.332000Z"},{"_id":"66b92d4579464377af099d38","body":"> I would report this to the Ada maintainers: whether the system is case-sensitive is not a property of the OS at all, it will depend on the filesystem. That code makes no sense.\r\n\r\nI think all the Ada maintainers are AdaCore people; AdaCore have said they don\u2019t support macOS.\r\n\r\nI\u2019ve written a small demonstrator (attached) that could be included in `adaint.c`, and invoked if `GNAT_FILE_NAME_CASE_SENSITIVE` isn\u2019t set. Tested on Catalina (the earliest version I have), Monterey (x86_64), Sonoma (aarch64), against ExFAT, HFS, HFS CS, APFS, APFS CS (the HFS and both CS tests were against disk images).\r\n\r\nIssues I see:\r\n\r\n* `getattrlist()` first appeared in Yosemite (10.10, darwin14). Could check for OS release and default to case-insensitive if < darwin14.\r\n* `adaint.c` has a **lot** of OS sensitivity, would make it tricky to review and very difficult to test\r\n\r\n[check_case_sensitivity.zip](https:\/\/github.com\/iains\/gcc-darwin-arm64\/files\/13056802\/check_case_sensitivity.zip)\r\n","issue_id":1704166943910,"origin_id":1773139664,"user_origin_id":1824512,"create_time":1697823549,"update_time":1697823549,"id":1723411781335,"updated_at":"2024-08-11T21:29:41.335000Z","created_at":"2024-08-11T21:29:41.335000Z"},{"_id":"66b92d4579464377af099d39","body":"> > I would report this to the Ada maintainers: whether the system is case-sensitive is not a property of the OS at all, it will depend on the filesystem. That code makes no sense.\r\n> \r\n> I think all the Ada maintainers are AdaCore people; AdaCore have said they don\u2019t support macOS.\r\n\r\nWell, they no longer actively develop for macOS, but I think that they will review macOS \/ Darwin patches for Ada (i.e. I do not think that I can approve them as Darwin maintainer - although perhaps I should clarify that with them).\r\n \r\n> I\u2019ve written a small demonstrator (attached) that could be included in `adaint.c`, and invoked if `GNAT_FILE_NAME_CASE_SENSITIVE` isn\u2019t set. Tested on Catalina (the earliest version I have), Monterey (x86_64), Sonoma (aarch64), against ExFAT, HFS, HFS CS, APFS, APFS CS (the HFS and both CS tests were against disk images).\r\n> \r\n> Issues I see:\r\n> \r\n> * `getattrlist()` first appeared in Yosemite (10.10, darwin14). Could check for OS release and default to case-insensitive if < darwin14.\r\n\r\nWe can use min version in adainit.c - it's already done.\r\n\r\n> * `adaint.c` has a **lot** of OS sensitivity, would make it tricky to review and very difficult to test\r\n\r\nIndeed it is the \"kitchen sink\" for interface stuff.\r\n\r\n> [check_case_sensitivity.zip](https:\/\/github.com\/iains\/gcc-darwin-arm64\/files\/13056802\/check_case_sensitivity.zip)\r\n\r\nI will try to take a look at this sometime after Stage1 is finished (19th Nov) - I think the bug is a regression and therefore can be fixed in Stage 3. Until then, I am snowed under with Stage1 stuff :)\r\n","issue_id":1704166943910,"origin_id":1773207939,"user_origin_id":4039407,"create_time":1697826649,"update_time":1697826649,"id":1723411781338,"updated_at":"2024-08-11T21:29:41.337000Z","created_at":"2024-08-11T21:29:41.337000Z"},{"_id":"66b92d4579464377af099d3a","body":"As an aside: \"\/\/ getattrlist() first appeared in Yosemite, 10.10 (darwin14). There\r\n\/\/ are notes in the man page under Compatbility:\"\r\n\r\nThis does not seem correct, I see getattlist() in \/usr\/include\/sys\/attr.h back to Darwin8 (MacOSX 10.4) [ not that this matters too much to the actual issue, since APFS is not available until 10.13 or so]\r\n","issue_id":1704166943910,"origin_id":1773267079,"user_origin_id":4039407,"create_time":1697828985,"update_time":1697828985,"id":1723411781340,"updated_at":"2024-08-11T21:29:41.339000Z","created_at":"2024-08-11T21:29:41.339000Z"},{"_id":"66b92d4579464377af099d3b","body":"> As an aside: \"\/\/ getattrlist() first appeared in Yosemite, 10.10 (darwin14). There \/\/ are notes in the man page under Compatbility:\"\r\n> \r\n> This does not seem correct, I see getattlist() in \/usr\/include\/sys\/attr.h back to Darwin8 (MacOSX 10.4) [ not that this matters too much to the actual issue, since APFS is not available until 10.13 or so]\r\n\r\nI saw it in a Compatibility man page section somewhere on the web, sorry. Looking at current `unistd.h`, it seems to be saying that 10.6 is the start point. There were some changes in `attr.h` between Catalina and Sonoma, the one that affected me was that `ATTRIBUTE_SET_INIT` wasn\u2019t in the earlier version.\r\n\r\nI don\u2019t believe that APFS affects the issue (\"File names case sensitive\"), this arises on HFS just as much as on APFS. The difference with APFS is that it will fail any attempt to create a file with an upper latin-1 character in its name, e.g. lower-case-a-acute, 0xe1; whereas HFS converts the character to the three-character string `%E1`.\r\n\r\nIf you try to run the 2.6 ACATS, as included in GCC (e.g. `make -C gcc check-acats` or `check-ada`) on an APFS volume, test C250002 will fail because it involves files with names containing latin-1 characters; whereas on an HFS volume, the test succeeds because the conversions noted above work for write and read.\r\n\r\nIf you run the [current (4.1) ACATS](https:\/\/github.com\/simonjwright\/ACATS) on a case-insensitive volume, C250002 will fail because it involves files with names containing UTF-8 characters that GCC tries to convert to lower-case by treating each octet as if it were latin-1 (if it looks like an upper-case latin-1 character, set bit 5!). On a CS volume, GCC leaves well alone and all works.\r\n\r\nWhy does GNAT do this? because `with Foo;` translates to a dependence on file `foo.ads` (as does `with foo;`). This is all quite deep in the compiler, and I\u2019m not at all sure it\u2019s a library issue. All the same, recognising case-sensitivity properly can only be a good thing.","issue_id":1704166943910,"origin_id":1773351785,"user_origin_id":1824512,"create_time":1697833594,"update_time":1697833594,"id":1723411781342,"updated_at":"2024-08-11T21:29:41.342000Z","created_at":"2024-08-11T21:29:41.342000Z"},{"_id":"66b92d4579464377af099d3c","body":"Making the process automatic (rather than relying on GNAT_FILE_NAME_CASE_SENSITIVE) seems like a good objective.\r\n\r\nHowever, it seems that GNAT_FILE_NAME_CASE_SENSITIVE is not sufficient on APFS (C250002 fails on a case-sensitive APFS volume even when that env is set), where it does work reliably on HFS+ (as you say some conversion is done).\r\n\r\nI'll try to give this some better attention after stage 1 is done.\r\n","issue_id":1704166943910,"origin_id":1773447429,"user_origin_id":4039407,"create_time":1697839288,"update_time":1697839288,"id":1723411781345,"updated_at":"2024-08-11T21:29:41.345000Z","created_at":"2024-08-11T21:29:41.345000Z"},{"_id":"66b92d4579464377af099d3d","body":"> However, it seems that GNAT_FILE_NAME_CASE_SENSITIVE is not sufficient on APFS (C250002 fails on a case-sensitive APFS volume even when that env is set), where it does work reliably on HFS+ (as you say some conversion is done).\r\n\r\nThe attached is a C program that demonstrates this behaviour. On an HFS disk,\r\n```\r\n$ latin\r\nattempting to open 'l?tin.txt':\r\nok\r\n$ ls\r\nl%E1tin.txt\r\n```\r\nOn an HFS CS disk,\r\n```\r\n$ latin\r\nattempting to open 'l?tin.txt':\r\nok\r\n$ ls\r\nl%E1tin.txt\r\n```\r\nOn an APFS disk,\r\n```\r\n$ latin\r\nattempting to open 'l?tin.txt':\r\ncall failed: Illegal byte sequence\r\n```\r\nOn an APFS CS disk,\r\n```\r\n$ latin\r\nattempting to open 'l?tin.txt':\r\ncall failed: Illegal byte sequence\r\n```\r\n\r\nI\u2019ll raise a Bugzilla PR on the ACATS testsuite, as I should have done already: likewise on this issue.\r\n\r\n[latin.zip](https:\/\/github.com\/iains\/gcc-darwin-arm64\/files\/13060515\/latin.zip)","issue_id":1704166943910,"origin_id":1773758030,"user_origin_id":1824512,"create_time":1697886570,"update_time":1697886754,"id":1723411781348,"updated_at":"2024-08-11T21:29:41.347000Z","created_at":"2024-08-11T21:29:41.347000Z"},{"_id":"66b92d4579464377af099d3e","body":"> I\u2019ll raise a Bugzilla PR on the ACATS testsuite, as I should have done already: likewise on this issue.\r\n\r\nI'm assuming that that's this? https:\/\/gcc.gnu.org\/bugzilla\/show_bug.cgi?id=111909 ","issue_id":1704166943910,"origin_id":1773962934,"user_origin_id":1388660,"create_time":1697937721,"update_time":1697937721,"id":1723411781350,"updated_at":"2024-08-11T21:29:41.350000Z","created_at":"2024-08-11T21:29:41.350000Z"},{"_id":"66b92d4579464377af099d3f","body":"> I'm assuming that that's this? https:\/\/gcc.gnu.org\/bugzilla\/show_bug.cgi?id=111909\r\n\r\nYes (this issue).","issue_id":1704166943910,"origin_id":1774061289,"user_origin_id":1824512,"create_time":1697972053,"update_time":1697972053,"id":1723411781352,"updated_at":"2024-08-11T21:29:41.352000Z","created_at":"2024-08-11T21:29:41.352000Z"},{"_id":"66b92d4579464377af099d40","body":"See [this patch](https:\/\/gcc.gnu.org\/pipermail\/gcc-patches\/2023-October\/634636.html). It\u2019ll take a while for AdaCore to comment one way or another; of course it\u2019s _very_ Darwin-specific. I don\u2019t have a Linux box to test it on.","issue_id":1704166943910,"origin_id":1785258669,"user_origin_id":1824512,"create_time":1698674217,"update_time":1698674217,"id":1723411781355,"updated_at":"2024-08-11T21:29:41.354000Z","created_at":"2024-08-11T21:29:41.354000Z"},{"_id":"66b92d4579464377af099d41","body":"> See [this patch](https:\/\/gcc.gnu.org\/pipermail\/gcc-patches\/2023-October\/634636.html). It\u2019ll take a while for AdaCore to comment one way or another; of course it\u2019s _very_ Darwin-specific. I don\u2019t have a Linux box to test it on.\r\n\r\nI also want to check it on earlier Darwin - just in case (and then will comment on list)... ","issue_id":1704166943910,"origin_id":1785263618,"user_origin_id":4039407,"create_time":1698674316,"update_time":1698674316,"id":1723411781357,"updated_at":"2024-08-11T21:29:41.357000Z","created_at":"2024-08-11T21:29:41.357000Z"},{"_id":"66b92d4579464377af099d42","body":"FAOD, with this patch, I should no longer need to set GNAT_FILE_NAME_CASE_SENSITIVE (when using a CS filesystem)? If all goes smoothly, can also test on Linux.","issue_id":1704166943910,"origin_id":1785305530,"user_origin_id":4039407,"create_time":1698675131,"update_time":1698675131,"id":1723411781360,"updated_at":"2024-08-11T21:29:41.360000Z","created_at":"2024-08-11T21:29:41.360000Z"},{"_id":"66b92d4579464377af099d43","body":"OK.. so initial testing on Darwin19 (OK) Darwin17 (not OK) and Darwin9 (not OK)\r\n\r\nAccording to the manual page for `getattrlist` and the test for a case-sensitive volume should exist on Darwin9 and 17, so there is some debugging needed.\r\n\r\nedit: this might relate to file systems mounted onto paths in the root dir (which seems to report correctly on later OS versions but with 'invalid parameter' on earlier). Not sure when I'll be able to debug further.\r\n","issue_id":1704166943910,"origin_id":1786679411,"user_origin_id":4039407,"create_time":1698738590,"update_time":1698741016,"id":1723411781364,"updated_at":"2024-08-11T21:29:41.364000Z","created_at":"2024-08-11T21:29:41.364000Z"},{"_id":"66b92d4579464377af099d44","body":"> See [this patch](https:\/\/gcc.gnu.org\/pipermail\/gcc-patches\/2023-October\/634636.html). It\u2019ll take a while for AdaCore to comment one way or another; of course it\u2019s _very_ Darwin-specific. I don\u2019t have a Linux box to test it on.\r\n\r\nFollowing the thread up across the month-boundary that exists in the mailing list archives: \r\nhttps:\/\/gcc.gnu.org\/pipermail\/gcc-patches\/2023-November\/635104.html\r\n","issue_id":1704166943910,"origin_id":1817967915,"user_origin_id":1388660,"create_time":1700425645,"update_time":1700425645,"id":1723411781367,"updated_at":"2024-08-11T21:29:41.367000Z","created_at":"2024-08-11T21:29:41.367000Z"},{"_id":"66b92d4579464377af099d45","body":"On 22 Oct 2023, at 02:22, Eric Gallager ***@***.***> wrote:\r\n> I\u2019ll raise a Bugzilla PR on the ACATS testsuite, as I should have done already: likewise on this issue.\r\n> \r\n> I'm assuming that that's this? https:\/\/gcc.gnu.org\/bugzilla\/show_bug.cgi?id=111909\r\n> \r\n\r\nYes, that\u2019s this issue.\r\n\r\nThe one on ACATS (in GCC) is https:\/\/gcc.gnu.org\/bugzilla\/show_bug.cgi?id=112529 - apparently it affects Windows as well.","issue_id":1704166943910,"origin_id":1817980864,"user_origin_id":1824512,"create_time":1700428807,"update_time":1700428807,"id":1723411781370,"updated_at":"2024-08-11T21:29:41.370000Z","created_at":"2024-08-11T21:29:41.370000Z"},{"_id":"66b92d4579464377af099d46","body":"By the time we\u2019d got to the last message in the patch thread, https:\/\/gcc.gnu.org\/pipermail\/gcc-patches\/2023-November\/637004.html, I\u2019d rather lost interest (in fact, I wrote a reply which I seem not to have posted saying that I thought it was really up to Darwin people as to whether Arno\u2019s proposal - disregarding the possibility of iWatch, for instance - was OK).\r\n\r\nIf we go ahead with this minimal patch, macOS computers will be consistent, which is a good thing. It might make it more difficult to get the original patch in (fixed up for the older OS issues that Iain found, of course) at a later date.\r\n\r\nOn further thought - Iain, have you actually encountered Ada case-related issues? I\u2019ve not had any reports of aarch64-apple-darwin users having trouble in this area, in spite of the compiler thinking the FS is case-sensitive. This means that ACATS 4.1\u2019s C250002 actually works on aarch64! (PR81114 refers).","issue_id":1704166943910,"origin_id":1817997762,"user_origin_id":1824512,"create_time":1700432877,"update_time":1700432877,"id":1723411781373,"updated_at":"2024-08-11T21:29:41.373000Z","created_at":"2024-08-11T21:29:41.373000Z"},{"_id":"66b92d4579464377af099d47","body":"\r\n> By the time we\u2019d got to the last message in the patch thread, https:\/\/gcc.gnu.org\/pipermail\/gcc-patches\/2023-November\/637004.html, I\u2019d rather lost interest (in fact, I wrote a reply which I seem not to have posted saying that I thought it was really up to Darwin people as to whether Arno\u2019s proposal - disregarding the possibility of iWatch, for instance - was OK).\r\n\r\nWe are a long long way from having time to extend the Arm64 port to cover 32b (not arguing against the idea, but being realistic in resourcing)\r\n\r\n> If we go ahead with this minimal patch, macOS computers will be consistent, which is a good thing. It might make it more difficult to get the original patch in (fixed up for the older OS issues that Iain found, of course) at a later date.\r\n\r\nI will reply to the list thread, IMO it's a step forward; I'd prefer an automatic solution, but there's more work to do to achieve that and I do not have cycles spare to explore what's going wrong (the calls are a thin wrapper on a syscall, so the underlying difference is how the kernel is responding to the input path). I am not concerned that a short-term improvement would alter the acceptability of a better patch when we have one.\r\n\r\n>On further thought - Iain, have you actually encountered Ada case-related issues? I\u2019ve not had any reports of aarch64-apple-darwin users having trouble in this area, in spite of the compiler thinking the FS is case-sensitive. \r\n\r\nI have not seen reports of problems, there are none (other than the current discussed cases) in BZ AFAIK. I use the `GNAT_FILE_NAME_CASE_SENSITIVE=1` for local testing (and, yes, it's irritating to repeat the testsuite run if I forget to do it - but not a show-stopper).\r\n\r\n>This means that ACATS 4.1\u2019s C250002 actually works on aarch64! (PR81114 refers).\r\n\r\nWhat has changed between the version that we have in GCC and 4.1?\r\n\r\n","issue_id":1704166943910,"origin_id":1820666818,"user_origin_id":4039407,"create_time":1700563413,"update_time":1700563413,"id":1723411781376,"updated_at":"2024-08-11T21:29:41.375000Z","created_at":"2024-08-11T21:29:41.375000Z"},{"_id":"66b92d4579464377af099d48","body":"> > This means that ACATS 4.1\u2019s C250002 actually works on aarch64! (PR81114 refers).\r\n> \r\n> What has changed between the version that we have in GCC and 4.1?\r\n\r\nThe test involves a file whose name (`c250002_\u00e1.ads`) includes an international character; the text of that file includes its own name (`C250002_\u00c1`), upper-cased as you see.\r\n\r\nThe in-tree test implements this using Latin-1 characters; ACATS 4.1 uses UTF-8.\r\n\r\nI\u2019ve only investigated the UTF-8 implementation. The compiler realises that it needs to lower-case the text name (because Ada), and manages this successfully.\r\n\r\nIf file names are case-insensitive, a later part of the compiler (for reasons) decides to lower-case this already-lower-case name by treating each byte as if it were Latin-1, which mangles the `\u00e1` (`0xc3a1`) into `0xe3a1`, which isn\u2019t a valid character. \r\n\r\nI don\u2019t know why APFS allows this, when it doesn\u2019t allow upper-half Latin-1 characters!","issue_id":1704166943910,"origin_id":1826351109,"user_origin_id":1824512,"create_time":1700924004,"update_time":1700924004,"id":1723411781379,"updated_at":"2024-08-11T21:29:41.378000Z","created_at":"2024-08-11T21:29:41.378000Z"},{"_id":"66b92d4579464377af099d49","body":"If I understand correctly, there's an upstream bug to track this (and the problem is not specific to this port) - if both those are tre please close the issue (the BZ PR is open).\r\n","issue_id":1704166943910,"origin_id":1937869117,"user_origin_id":4039407,"create_time":1707685482,"update_time":1707685482,"id":1723411781383,"updated_at":"2024-08-11T21:29:41.382000Z","created_at":"2024-08-11T21:29:41.382000Z"},{"_id":"66b92d4579464377af099d4a","body":"BZ? but, closing.","issue_id":1704166943910,"origin_id":1938315702,"user_origin_id":1824512,"create_time":1707730409,"update_time":1707730409,"id":1723411781386,"updated_at":"2024-08-11T21:29:41.386000Z","created_at":"2024-08-11T21:29:41.386000Z"},{"_id":"66b92d4579464377af099d4b","body":"> BZ? but, closing.\r\n\r\nBugzilla .. (PR now gets confused with \"pull request\" :roll_eyes:","issue_id":1704166943910,"origin_id":1938319760,"user_origin_id":4039407,"create_time":1707730568,"update_time":1707730568,"id":1723411781389,"updated_at":"2024-08-11T21:29:41.389000Z","created_at":"2024-08-11T21:29:41.389000Z"}]

At [gcc/ada/adaint.c:611](https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/adaint.c#L611) we have ``` /* By default, we suppose filesystems aren't case sensitive on Windows and Darwin (but they are on arm-darwin). */ #if defined (WINNT) || defined (__DJGPP__)...

Need to configure with --enable-host-pie

[{"_id":"66b92d2079464377af099d19","body":"right, I believe I commented on a gcc-patches thread related to that PR, that the current configuration for Ada seems to force PIE off (which is no longer needed) - but AFAIR there has been no response. So the issue here is that we are now using the upstream PIE build fixes - rather than our local Darwin ones (that also handled Ada).\r\n\r\nI need to check back over the threads to see if there's an incremental patch to propose - meanwhile you have a workaround, I see?\r\n","issue_id":1704166943970,"origin_id":1694339211,"user_origin_id":4039407,"create_time":1693055831,"update_time":1693055831,"id":1723411744886,"updated_at":"2024-08-11T21:29:04.886000Z","created_at":"2024-08-11T21:29:04.886000Z"},{"_id":"66b92d2079464377af099d1a","body":"Yes, the workround works: the acats tests look good,\r\n```\r\n\t\t=== acats Summary ===\r\n# of expected passes\t\t2325\r\n# of unexpected failures\t3\r\n*** FAILURES: cb1010a cb1010d c250002 \r\n```\r\nwhich is usual, I think? (the first 2 are stack overflow check failures, the last is to do with filenames containing Latin-1 international characters vs the Darwin filesystem).","issue_id":1704166943970,"origin_id":1694349564,"user_origin_id":1824512,"create_time":1693059024,"update_time":1693059024,"id":1723411744890,"updated_at":"2024-08-11T21:29:04.889000Z","created_at":"2024-08-11T21:29:04.889000Z"},{"_id":"66b92d2079464377af099d1b","body":"yes, that looks \"normal\"\r\n\r\n(I have not got as far as looking into those fails; there are others we need to tackle ahead of those). Probably, the stack-checking stuff would turn out to be common code, but not sure yet.\r\n\r\nAs for character set issues, that test is either skipped or passes on earlier\/x86_64 Darwin versions, so we might want to poke a bit at what is going wrong there.\r\n","issue_id":1704166943970,"origin_id":1694357348,"user_origin_id":4039407,"create_time":1693060597,"update_time":1693060597,"id":1723411744893,"updated_at":"2024-08-11T21:29:04.893000Z","created_at":"2024-08-11T21:29:04.893000Z"},{"_id":"66b92d2079464377af099d1c","body":"> As for character set issues, that test is either skipped or passes on earlier\/x86_64 Darwin versions, so we might want to poke a bit at what is going wrong there.\r\n\r\nThe source file in this old (ACATS 2.6) version is c250002.aw, converted to c250002.a; the conversion changes e.g. `package C250002_[\"C1\"] is` to `package C250002_\u00c1 is`, where the `\u00c1` is a single Latin-1 character; gnatchop tries to create a .ads file with (the lower-case version of) that name and fails. Maybe HFS+ would have worked?\r\n\r\nInterestingly, Terminal (running bash) can create a file with such a name (e.g. via Touch), but the name gets converted to UTF-8 somewhere.\r\n\r\nThe equivalent test in modern ACATS is in `c250002.au`, which is UTF-8, but you may remember that there are issues with gnatchop not converting to lower-case properly, and the Mac FS changing the input NFC encoding to NFD (see [PR 81114 c1](https:\/\/gcc.gnu.org\/bugzilla\/show_bug.cgi?id=81114#c1)).","issue_id":1704166943970,"origin_id":1708439441,"user_origin_id":1824512,"create_time":1694009040,"update_time":1694009040,"id":1723411744897,"updated_at":"2024-08-11T21:29:04.897000Z","created_at":"2024-08-11T21:29:04.897000Z"},{"_id":"66b92d2079464377af099d1d","body":"> > As for character set issues, that test is either skipped or passes on earlier\/x86_64 Darwin versions, so we might want to poke a bit at what is going wrong there.\r\n> \r\n> The source file in this old (ACATS 2.6) version is c250002.aw, converted to c250002.a; the conversion changes e.g. `package C250002_[\"C1\"] is` to `package C250002_\u00c1 is`, where the `\u00c1` is a single Latin-1 character; gnatchop tries to create a .ads file with (the lower-case version of) that name and fails. Maybe HFS+ would have worked?\r\n\r\nCan you comment on whether the test works properly on an x86_64 box with a) an HFSx filesystem b) an APFS one? Have you tried case sensitive \/ not CS?\r\n\r\n(so, we have all permutations of Arm64 and x86_64 + HFSx and APFS + case sensitive).\r\n\r\nI always build OSS on case sensitive partitions, since some make that assumption so my experimental data do not cover much of that space.\r\n","issue_id":1704166943970,"origin_id":1712159487,"user_origin_id":4039407,"create_time":1694203083,"update_time":1694203083,"id":1723411744900,"updated_at":"2024-08-11T21:29:04.900000Z","created_at":"2024-08-11T21:29:04.900000Z"},{"_id":"66b92d2079464377af099d1e","body":"On 8 Sep 2023, at 20:58, Iain Sandoe ***@***.***> wrote:\r\n> As for character set issues, that test is either skipped or passes on earlier\/x86_64 Darwin versions, so we might want to poke a bit at what is going wrong there.\r\n> \r\n> The source file in this old (ACATS 2.6) version is c250002.aw, converted to c250002.a; the conversion changes e.g. package C250002_[\"C1\"] is to package C250002_\u00c1 is, where the \u00c1 is a single Latin-1 character; gnatchop tries to create a .ads file with (the lower-case version of) that name and fails. Maybe HFS+ would have worked?\r\n> \r\n> Can you comment on whether the test works properly on an x86_64 box with a) an HFSx filesystem b) an APFS one? Have you tried case sensitive \/ not CS?\r\n> \r\nOn an Intel box (MacBook Pro 2012, Catalina) the test works OK on an (external) HFS disk; gnatchop fails on the internal APFS disk and on a ExFAT USB stick. (I didn\u2019t know that a complete reinstall would set up the system disk as APFS, even though it\u2019s an HDD).\r\n\r\nExactly the same on an M1 Air, with the same external HFS disk.\r\n> (so, we have all permutations of Arm64 and x86_64 + HFSx and APFS + case sensitive).\r\n> \r\n> I always build OSS on case sensitive partitions, since some make that assumption so my experimental data do not cover much of that space.\r\n> \r\n\r\nI don\u2019t use case-sensitive partitions (well, as previously discussed, GNAT regards filesystems on aarch64 as case-sensitive).","issue_id":1704166943970,"origin_id":1719760230,"user_origin_id":1824512,"create_time":1694708330,"update_time":1694708330,"id":1723411744904,"updated_at":"2024-08-11T21:29:04.903000Z","created_at":"2024-08-11T21:29:04.903000Z"},{"_id":"66b92d2079464377af099d1f","body":"> On 8 Sep 2023, at 20:58, Iain Sandoe ***@***.***> wrote: As for character set issues, that test is either skipped or passes on earlier\/x86_64 Darwin versions, so we might want to poke a bit at what is going wrong there. The source file in this old (ACATS 2.6) version is c250002.aw, converted to c250002.a; the conversion changes e.g. package C250002_[\"C1\"] is to package C250002_\u00c1 is, where the \u00c1 is a single Latin-1 character; gnatchop tries to create a .ads file with (the lower-case version of) that name and fails. Maybe HFS+ would have worked? Can you comment on whether the test works properly on an x86_64 box with a) an HFSx filesystem b) an APFS one? Have you tried case sensitive \/ not CS?\r\n> On an Intel box (MacBook Pro 2012, Catalina) the test works OK on an (external) HFS disk; gnatchop fails on the internal APFS disk and on a ExFAT USB stick. (I didn\u2019t know that a complete reinstall would set up the system disk as APFS, even though it\u2019s an HDD). Exactly the same on an M1 Air, with the same external HFS disk.\r\n> (so, we have all permutations of Arm64 and x86_64 + HFSx and APFS + case sensitive). I always build OSS on case sensitive partitions, since some make that assumption so my experimental data do not cover much of that space.\r\n\r\nHmm so it seems that APFS is doing something different - I guess this probably means that we need to update libada to reflect these changes; I do not think Adacore are supporting macOS any more so it will be down to us to make patch and post it.\r\n\r\n> I don\u2019t use case-sensitive partitions (well, as previously discussed, GNAT regards filesystems on aarch64 as case-sensitive).\r\n\r\nThere's an environment var that has to be set for CS partitions:\r\n`GNAT_FILE_NAME_CASE_SENSITIVE=1`\r\nOtherwise, AFAIK it will treat macOS \/ MacOSX FS as case-preserving-case-insensitive (i.e. the default for the install).\r\n\r\nBTW: Since the 'rootless' changes there is a subtlety - IFF you make the system partition case censitive, actually the read-only portion [with the immutable part of the macOS install] will remain case insensitive, it is only the partition that is mounted on \/System\/Data\/ that is actually case sensitive (that fooled me at first - since it looked as if the disk utility was ignoring my setting). When you examine the system disk it looks as if it's case insensitive.\r\n\r\nMy build partitions on macOS 12 are external case sensitive APFS and 25002 fails there too.\r\n","issue_id":1704166943970,"origin_id":1719782703,"user_origin_id":4039407,"create_time":1694709284,"update_time":1694709284,"id":1723411744906,"updated_at":"2024-08-11T21:29:04.906000Z","created_at":"2024-08-11T21:29:04.906000Z"},{"_id":"66b92d2079464377af099d20","body":"\r\n> > I don\u2019t use case-sensitive partitions (well, as previously discussed, GNAT regards filesystems on aarch64 as case-sensitive).\r\n\r\nHmm maybe I missed something of this point - are you saying that there's some arch-specific setting that's not accounting for macOS (it would be reasonable for the default to be case sensitive on other *nix). Maybe we are missing an aarch64-darwin OS file somewhere.\r\n\r\n\r\n","issue_id":1704166943970,"origin_id":1719790953,"user_origin_id":4039407,"create_time":1694709662,"update_time":1694709662,"id":1723411744908,"updated_at":"2024-08-11T21:29:04.908000Z","created_at":"2024-08-11T21:29:04.908000Z"},{"_id":"66b92d2079464377af099d21","body":"> > > I don\u2019t use case-sensitive partitions (well, as previously discussed, GNAT regards filesystems on aarch64 as case-sensitive).\r\n> \r\n> Hmm maybe I missed something of this point - are you saying that there's some arch-specific setting that's not accounting for macOS (it would be reasonable for the default to be case sensitive on other *nix). Maybe we are missing an aarch64-darwin OS file somewhere.\r\n\r\nNOTE: setting `GNAT_FILE_NAME_CASE_SENSITIVE` will override the default, and therefore should give correct behaviour if you set it right for your test disk (so that's not the origin of the fault, I suppose)\r\nbut the default is, indeed, to assume case sensitive - not sure if that's correct for macOS (it might well be for iOS)\r\n\r\n```\r\n\t \/* By default, we suppose filesystems aren't case sensitive on\r\n\t Windows and Darwin (but they are on arm-darwin). *\/\r\n#if defined (WINNT) || defined (__DJGPP__) \\\r\n || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))\r\n\t file_names_case_sensitive_cache = 0;\r\n#else\r\n\t file_names_case_sensitive_cache = 1;\r\n#endif\r\n```\r\n","issue_id":1704166943970,"origin_id":1719987386,"user_origin_id":4039407,"create_time":1694718151,"update_time":1694718151,"id":1723411744911,"updated_at":"2024-08-11T21:29:04.911000Z","created_at":"2024-08-11T21:29:04.911000Z"},{"_id":"66b92d2079464377af099d22","body":"I just dug out my K&R C. Running this code\r\n``` C\r\n#include <stdio.h>\r\n\r\nint main() {\r\n char name[] = \"c250002_x.ads\";\r\n name[8] = 0xe1; \/\/ Latin 1 lower-case a acute\r\n printf(\"name: '%s'\\n\", name);\r\n FILE *f = fopen(name, \"w\");\r\n if (f) {\r\n printf(\"file opened.\\n\");\r\n fclose(f);\r\n } else {\r\n perror(\"file not opened\");\r\n }\r\n return 0;\r\n}\r\n```\r\nhas the following results:\r\n\r\nOn the ExFat USB stick, `file not opened: Invalid argument`\r\nOn AFPS, `file not opened: Illegal byte sequence`\r\nOn HFS, success.\r\n\r\nSo, it looks as though HFS assumes we know what we\u2019re doing (rather like Linux), but APFS checks whether the proposed file name string is legal UTF-8.\r\n\r\nThis check (c250002) has been updated in ACATS 4 (possibly even in 3) to use utf-8 strings, which is what the ARM now requires ([ARM 2.1(16)](http:\/\/www.ada-auth.org\/standards\/rm12_w_tc1\/html\/RM-2-1.html#p16)): but note that GNAT doesn\u2019t properly handle filenames with international characters in case-insensitive filesystems (PR81114, see above), and this is made worse on macOS because of the way that characters\u2019 normalization forms are changed silently on file creation but not on file searching, so that I can create a file and then be unable to open it using the same name.\r\n\r\nI\u2019d be inclined to disregard c250002 failures; that would still leave the stack overflow check failures (cb1010a, cb1010d) to be looked at.","issue_id":1704166943970,"origin_id":1720042490,"user_origin_id":1824512,"create_time":1694720668,"update_time":1694720668,"id":1723411744913,"updated_at":"2024-08-11T21:29:04.913000Z","created_at":"2024-08-11T21:29:04.913000Z"},{"_id":"66b92d2079464377af099d23","body":"> I just dug out my K&R C.\r\n\r\nheh.. you mean you do not have a build of GCC ?\r\n\r\nthe fail is indeed, as `man 2 open` says:\r\n [EILSEQ] The filename does not match the encoding rules.\r\n errno == 92 == EILSEQ\r\n\r\n> I\u2019d be inclined to disregard c250002 failures;\r\n\r\nHmm have to take a look and see if there's an XFAIL mechanism for acats.\r\n\r\n> that would still leave the stack overflow check failures (cb1010a, cb1010d) to be looked at.\r\n\r\nThis is not going to be any time soon - there has just been a big change in the stack checking and AFAIR it's also different from the macOS system version - so not a 5mins fix, by any means.\r\n","issue_id":1704166943970,"origin_id":1720065175,"user_origin_id":4039407,"create_time":1694721749,"update_time":1694722446,"id":1723411744916,"updated_at":"2024-08-11T21:29:04.915000Z","created_at":"2024-08-11T21:29:04.915000Z"},{"_id":"66b92d2079464377af099d24","body":"> > I just dug out my K&R C.\r\n> \r\n> heh.. you mean you do not have a build of GCC ?\r\n\r\nDistracted by the 200-point C on the cover\r\n\r\n> > I\u2019d be inclined to disregard c250002 failures;\r\n> \r\n> Hmm have to take a look and see if there's an XFAIL mechanism for acats.\r\n\r\nI\u2019d be more inclined to look for a way of marking the test 'unsupported' - or perhaps just not running it on macOS? Is there a simple test for APFS? \r\n\r\n","issue_id":1704166943970,"origin_id":1720130025,"user_origin_id":1824512,"create_time":1694724371,"update_time":1694724371,"id":1723411744918,"updated_at":"2024-08-11T21:29:04.917000Z","created_at":"2024-08-11T21:29:04.917000Z"},{"_id":"66b92d2079464377af099d25","body":"> > Hmm have to take a look and see if there's an XFAIL mechanism for acats.\r\n> \r\n> I\u2019d be more inclined to look for a way of marking the test 'unsupported' - or perhaps just not running it on macOS? Is there a simple test for APFS?\r\n\r\n(either of these ^^ would do in the short term)\r\n\r\n--- in the longer term...\r\n\r\nI'm guessing that HFSx does the translation from what's supplied to the UTF-8 that's actually used.\r\n\r\nWhat I'm wondering about is whether the Ada library needs to provide appropriate conversions when the FS is APFS and if we can reasonably easily detect that situation (or perhaps have some default based on OS version, with an env override as is done for case sensitive).\r\n\r\n","issue_id":1704166943970,"origin_id":1721084077,"user_origin_id":4039407,"create_time":1694775703,"update_time":1694775703,"id":1723411744921,"updated_at":"2024-08-11T21:29:04.920000Z","created_at":"2024-08-11T21:29:04.920000Z"}]

This is related to [GCC PR 110467](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110467). That PR says that the problem only arises when Ada is enabled, which might explain why it's not been seen already. I found...

Microbit test behaves unexpectedly

[{"_id":"66bcf7a08d15a6f26f0aa4f8","body":"Actually, similar behaviour with the x86_64 hosted GCC 12.2.0 compiler. Might be a debouncing problem?","issue_id":1706768465300,"origin_id":1545968186,"user_origin_id":1824512,"create_time":1683907451,"update_time":1683907451,"id":1723660192782,"updated_at":"2024-08-14T18:29:52.782000Z","created_at":"2024-08-14T18:29:52.782000Z"}]

In `test-microbit/circle.hex`, each button is intended to act only on a push, not on a release. A toggles the speed, B toggles the direction. Building with the aarch64-hosted GCC 13.1.0...

Block a PO’s interrupt(s?) while in protected action

[]

AdaCore’s "Intro to Embedded Systems" says, in the [section on Handling Interrupts](https://learn.adacore.com/courses/intro-to-embedded-sys-prog/chapters/handling_interrupts.html), > The standard mutually exclusive access provided to the execution of protected procedures and entries is enforced whether...

pyqgit won’t open (TypeError)

[]

MacOS Monterey (12.6.3), Python 3.9 from python.org. `pip install --user codereview` goes OK, then (after faffing about trying to start :-) I get ``` $ pyqgit Traceback (most recent call...

Gprbuild confusion between normal & external versions

[{"_id":"66cdbde13be607015e091f0c","body":"The different selected version likely comes from `--select` attempting to find a `gprbuild` compatible with the `gnat` already selected. Was there one in your second run? `--install` won't attempt to do that, so it will select the newest version, provided by the external one in that case.\r\n\r\nAs for the error, it should have been fixed after #1533. It is possible you have to invalidate the action caches in your org.","issue_id":1709777025521,"origin_id":1934598072,"user_origin_id":264377,"create_time":1707412844,"update_time":1707412844,"id":1724759521534,"updated_at":"2024-08-27T11:52:01.534000Z","created_at":"2024-08-27T11:52:01.534000Z"}]

In the [ubuntu-latest workflow](https://github.com/simonjwright/sdl2-examples/blob/058310eaa45f99e8150563884a6daf0fe765a524/.github/workflows/main.yml#L58) of [the Ada example in my fork of sdl2-examples](https://github.com/simonjwright/sdl2-examples/tree/ada), we’re seeing that * `alr --non-interactive toolchain --install gprbuild` [installs the external gprbuild gprbuild=2021.0.0+0778](https://github.com/simonjwright/sdl2-examples/actions/runs/7667642636/job/20897900285#step:4:10) * `alr --non-interactive...