[Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

Hello.

Recently, for my personal needs, I have been trying to tweak and upgrade the following packages: llvm, compiler-rt, libunwind, libcxxabi, libcxx, clang (upgrading version by version from the original 9.0.1, and currently upgraded to version 12.0.1).

I imported some useful patches from Fedora RPMs, MinGW packages from MSYS2, and okuoku's llvm fork[1].

For patches and modified cygport files, the repos are here: https://github.com/orgs/ookiineko-cygpkg/repositories (commit histories are preserved).

However, I haven't tried to run the test suite because my laptop is not very good, I just know that helloworld compiles and runs fine (regarding c++, I tested linking against libstdc++ and libc++).

I have uploaded the precompiled binary & source packages to here: https://cygwin-llvm-revived-mirror.d0ve.workers.dev/0:/experimental/.

For Rust, it needs a lot of patches. I have tried to add the target/libc/STD support to version 1.67.0, and cross-compile from a Fedora host. For now, helloworld works, even some simple programs like ripgrep. But stack unwinding (panicking) is buggy, and no host compiler tools for now (because that requires native LLVM 15+).

The Rust port is a bit outdated now, since the latest Rust version is 1.71.0 (7 releases behind I guess), but I believe it should not be too hard to get the patches rebased. I plan to do this after I can get LLVM 15 working.

For more info about the Rust port: https://gist.github.com/ookiineko/057eb3a91825313caeaf6d793a33b0b2

[1]: https://github.com/okuoku/llvm-project/tree/cygwin64

Thank you,
Ookiineko.

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[Jon Turney]

On 27/07/2023 07:46, 小さい猫 via Cygwin-apps wrote:
> Hello.
> 
> Recently, for my personal needs, I have been trying to tweak and upgrade the following packages: llvm, compiler-rt, libunwind, libcxxabi, libcxx, clang (upgrading version by version from the original 9.0.1, and currently upgraded to version 12.0.1).
> 
> I imported some useful patches from Fedora RPMs, MinGW packages from MSYS2, and okuoku's llvm fork[1].
> 
> For patches and modified cygport files, the repos are here: https://github.com/orgs/ookiineko-cygpkg/repositories (commit histories are preserved).

Thanks.  This is awesome (and long needed!) work.

I'd suggest, if possible, you try to upstream your patches, as you are 
likely to get more knowledgable review there, but we'll try to take a 
look at them...

I would like to ask why you've dropped debuginfo package generation, and 
why LLVM_CONFIG_PATH needs explicitly setting, in most packages?

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

On Monday, July 31st, 2023 at 5:37 AM, Jon Turney <jon.turney@dronecode.org.uk> wrote:
> I would like to ask why you've dropped debuginfo package generation, and
> why LLVM_CONFIG_PATH needs explicitly setting, in most packages?

just because my laptop doesn't have much storage left for Windows...

LLVM_CONFIG_PATH is there as a template, when building the next version, i will manually set them to something like $HOME/llvm/llvm-x.y.z-a.arch/inst/usr/bin/llvm-config.

But maybe that is not the correct way to build it.

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

On Wednesday, 2 August 2023 at 12:32 PM, 小さい猫 <chiisaineko@protonmail.com> wrote:

> On Monday, July 31st, 2023 at 5:37 AM, Jon Turney jon.turney@dronecode.org.uk wrote:
> 
> > why LLVM_CONFIG_PATH needs explicitly setting, in most packages?
> 
> LLVM_CONFIG_PATH is there as a template, when building the next version, i will manually set them to something like $HOME/llvm/llvm-x.y.z-a.arch/inst/usr/bin/llvm-config.
> 
> But maybe that is not the correct way to build it.

it turned out it's not necessary, the correct build order is (i think): llvm -> clang -> compiler-rt -> libunwind -> libcxx (with the previous version of libcxxabi) -> libcxxabi -> libcxx

By the way, just now I have updated these cygports to 13.0.1 LLVM release in my GitHub repo.

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

On Thursday, 14 December 2023 at 2:42 PM, 小さい猫 via Cygwin-apps <cygwin-apps@cygwin.com> wrote:

> By the way, just now I have updated these cygports to 13.0.1 LLVM release in my GitHub repo.

now updated to 14.0.5

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[Takashi Yano]

On Mon, 15 Jan 2024 10:37:23 +0000
小さい猫 wrote:
> On Thursday, 14 December 2023 at 2:42 PM, 小さい猫 via Cygwin-apps <cygwin-apps@cygwin.com> wrote:
> 
> > By the way, just now I have updated these cygports to 13.0.1 LLVM release in my GitHub repo.
> 
> now updated to 14.0.5

I'm really looking forward to Rust running on cygwin.

BTW, are you aware of this ITA?
https://cygwin.com/pipermail/cygwin-apps/2024-January/043374.html

Or would you also like to take over llvm/clang package?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

On Monday, 15 January 2024 at 7:47 PM, Takashi Yano <takashi.yano@nifty.ne.jp> wrote:

> I'm really looking forward to Rust running on cygwin.

me too, i have already compiled llvm15, so the next is clang and libc++ blabla...

> BTW, are you aware of this ITA?
> https://cygwin.com/pipermail/cygwin-apps/2024-January/043374.html

yes, im glad to see someone decide to adopt Cygwin LLVM packages.

> Or would you also like to take over llvm/clang package?

i guess no bcs of my skill issues, i am just doing it for myself (including rust), but i would like to share my progress here xd

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

On Monday, 15 January 2024 at 9:47 PM, 小さい猫 <chiisaineko@protonmail.com> wrote:

> me too, i have already compiled llvm15, so the next is clang and libc++ blabla...

On Tuesday, 16 January 2024 at 7:14 PM, 小さい猫 via Cygwin-apps <cygwin-apps@cygwin.com> wrote:

> now updated to 15.0.7

so i have moved back to linux and started to continue trying to cross-compile a host rustc for cygwin

and after importing the patches from my 15.0.7 cygport branch, now the cross llvm build is passed and i can finally move on to fixing the rest of the rust part

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

小さい猫 via Cygwin-apps writes:
> On Thursday, 14 December 2023 at 2:42 PM, 小さい猫 via Cygwin-apps <cygwin-apps-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org> wrote:
>
>> By the way, just now I have updated these cygports to 13.0.1 LLVM release in my GitHub repo.
>
> now updated to 14.0.5

THanks for letting us know.  I can't promise, but I'll try to have a look over the weekend.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

On Tuesday, 16 January 2024 at 1:41 AM, ASSI via Cygwin-apps <cygwin-apps@cygwin.com> wrote:
> THanks for letting us know. I can't promise, but I'll try to have a look over the weekend.

<3

On Monday, 15 January 2024 at 6:37 PM, 小さい猫 <chiisaineko@protonmail.com> wrote:

> now updated to 14.0.5

now updated to 15.0.7

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

小さい猫 via Cygwin-apps writes:
> now updated to 15.0.7

I've built it and activated the tests, which seem to have roughly the
same results as 9.0.1, so that looks good.

For 9.0.1 I think I've finally got it to build almost cleanly.  I still
need to ignore some fallout from documentation bitrot, but nothing
worrisome.  Also OCaml bindings need to be disabled for now until the
version requirements can be provided.  I've not yet tried to get the
other LLVM related packages built.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

I've started a local llvm-revival branch…  I got sidetracked with OCaml,
but that will need some more time and currently I have just disabled the
OCaml bindings in LLVM instead (not removed: this is controlled by a
variable in the script and another variable to control the LLVM target
list).

--8<---------------cut here---------------start------------->8---
* LLVM Updates
  - LLVM 9.0.1 revived
    + update fedora to f31
    + update patches
    + disable OCAML via OCAML_SUPPORT
    + control build targets via LLVM_TARGETS
* OCaml Updates
  - flexdll 0.39 ==> 0.43
  - ocaml 4.14.0 ==> 4.14.1
  - ocaml-labltk 8.06.8 ==> 8.06.12 (for 4.14!)
    + CI build runs into trouble, local build is OK
  - ocaml-findlib 1.2.1 ==> 1.9.6
    + CI build would require newer labltk
  - ocaml-ocamlbuild 0.14.0 ==> 0.14.2
    + test complains about missing ocamlbuild.cmo, looks in the wrong place
    + test requires findlib
  - ocaml-dune
    + no longer builds with the original recipe, missing external libraries that in turn require dune to build
    + bootstrapped dune should still be viable
  - ocaml-ctype
    + would be needed for llvm
    + available version is for ocaml-4.10, which is no longer installable
    + need to figure out dune build and bootsrap a number of further packages before getting this updated to 4.14
--8<---------------cut here---------------end--------------->8---

The changes (only for packages that actually build) currently live in
the playground branches of the respective Cygwin Package Git
repositories.  PUlling up the LLVM version to at least 12 and then
getting all the other dependent packages built is next on my list, but
don't hold your breath


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

ASSI via Cygwin-apps writes:
> I've started a local llvm-revival branch…  I got sidetracked with OCaml,
> but that will need some more time and currently I have just disabled the
> OCaml bindings in LLVM instead (not removed: this is controlled by a
> variable in the script and another variable to control the LLVM target
> list).
>
> * LLVM Updates
>   - LLVM 9.0.1 revived
>     + update fedora to f31
>     + update patches
>     + disable OCAML via OCAML_SUPPORT
>     + control build targets via LLVM_TARGETS
      + enable testing

Many of the (few) failing tests run into trouble with fork errors and
sometimes succeed when run again, so from that angle I think the build
is good.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

On Monday, August 14th, 2023 at 12:50 AM, ASSI via Cygwin-apps <cygwin-apps@cygwin.com> wrote:

> I've started a local llvm-revival branch… I got sidetracked with OCaml,
> but that will need some more time and currently I have just disabled the
> OCaml bindings in LLVM instead (not removed: this is controlled by a
> variable in the script and another variable to control the LLVM target
> list).

I am not sure but there is probably some upstream changes are needed in cygport source[1] to get latest ocaml-findlib & ocaml-dune to work properly.

the dependency infos in META files seems start to have some pretty printing and the old regex and patterns for finding the depended pkg names are no longer working correctly.

also starting from llvm 11, libunwind seemed to use some asm and the build bugged due a cmake bug(?), possible fix is here[2].

[1]: https://gist.github.com/ookiineko/8fc62f16e2cdff587d42d6d8d6cc7067/raw/7e02d879d47f8f074b1cc26ff41a94f7b54fa650/ocamlfind-dune-pretty-print.patch
[2]: https://github.com/ookiineko-cygpkg/cmake/commit/c198158965fe3714bf101dda5dedc9fb5778e4d4

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

On Friday, August 18th, 2023 at 8:59 AM, 小さい猫 via Cygwin-apps <cygwin-apps@cygwin.com> wrote:

> also starting from llvm 11, libunwind seemed to use some asm and the build bugged due a cmake bug(?)

the cmake issue is about to remove -fPIC from the asmflags.

starting from llvm12, msys2/mingw introduced a patch to suppress the error/warning about this flag and it only appear when using MSVC target, so i imported that patch: https://github.com/ookiineko-cygpkg/clang/blob/main/12.0.1-cygming-disable-fpic-errs.patch

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

小さい猫 via Cygwin-apps writes:
> On Monday, August 14th, 2023 at 12:50 AM, ASSI via Cygwin-apps <cygwin-apps@cygwin.com> wrote:
>
>> I've started a local llvm-revival branch… I got sidetracked with OCaml,
>> but that will need some more time and currently I have just disabled the
>> OCaml bindings in LLVM instead (not removed: this is controlled by a
>> variable in the script and another variable to control the LLVM target
>> list).
>
> I am not sure but there is probably some upstream changes are needed
> in cygport source[1] to get latest ocaml-findlib & ocaml-dune to work
> properly.  the dependency infos in META files seems start to have some
> pretty printing and the old regex and patterns for finding the
> depended pkg names are no longer working correctly.

That's a separate issue, thanks for the patch.

What I was talking about is that while I can use an opam "switch" to
update ocaml and its dependencies in a private installation, I can not
build the Cygwin packages that would need to be distributed or update
the system installation of OCaml.  If it exists, any option to update
the system files has eluded me.  In particular, I have not yet figured
out how to break the circular dependencies for a bootstrap build.  Opam
must know how to do this or it wouldn't suceeed, but doesn't show what
exactly it's doing by default.  THere's probably a way to look at that
too…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

On Monday, August 14th, 2023 at 12:50 AM, ASSI via Cygwin-apps <cygwin-apps@cygwin.com> wrote:

> - ocaml-dune
> + no longer builds with the original recipe, missing external libraries that in turn require dune to build
> + bootstrapped dune should still be viable
> - ocaml-ctype
> + would be needed for llvm
> + available version is for ocaml-4.10, which is no longer installable
> + need to figure out dune build and bootsrap a number of further packages before getting this updated to 4.14

On Friday, August 18th, 2023 at 12:30 PM, ASSI via Cygwin-apps <cygwin-apps@cygwin.com> wrote:

> What I was talking about is that while I can use an opam "switch" to
> update ocaml and its dependencies in a private installation, I can not
> build the Cygwin packages that would need to be distributed or update
> the system installation of OCaml. If it exists, any option to update
> the system files has eluded me. In particular, I have not yet figured
> out how to break the circular dependencies for a bootstrap build. Opam
> must know how to do this or it wouldn't suceeed, but doesn't show what
> exactly it's doing by default. THere's probably a way to look at that
> too…

i am not familiar with the ocaml stuffs, and i dont quite understand what is the problem ur currently getting.

since i dont want to revive ocaml stuffs, at least for now bcs it looks like a lot of work and i dont really need them.

however, i did tried to compile ocaml-dune version 2.9.3 and 3.7.1 
 (for ocaml 4.14) previously for some other personal reason (not for llvm), and here are the prebuilt binaries of dune 3.7.1 if you need[1], i kinda forgot how i bootstrapped it.

i didn't upload the cygport files for this dune and other related/depended pkgs, but i made a dirty tarball at here just now: [2], some of them are still wip.

[1]: https://cygwin-llvm-revived-mirror.d0ve.workers.dev/0:/_ocaml/cygwin-ocaml.7z
[2]: https://cygwin-llvm-revived-mirror.d0ve.workers.dev/0:/_ocaml/cygports_with_git_history.tgz

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

小さい猫 via Cygwin-apps writes:
> i am not familiar with the ocaml stuffs, and i dont quite understand
> what is the problem ur currently getting.

Dune cannot be fully built because lwt.unix or one of it's dependencies
is missing.  I could built a bootstrapped package, but that later runs
into trouble when I need to build packages that require the things not
in the bootstrap build.  Just about every Linux distribution seems to
have a different way of working around these dependency problems and
none look anything like what Cygwin had.  Anyway, I've found a Fedora
patch that just removes the lwt dependency and sdurprise, dune still
builds and actually packages.

> however, i did tried to compile ocaml-dune version 2.9.3 and 3.7.1
> (for ocaml 4.14) previously for some other personal reason (not for
> llvm), and here are the prebuilt binaries of dune 3.7.1 if you
> need[1], i kinda forgot how i bootstrapped it.

I can get to that point with a bootstrap build or even a fully
configured one with opam.  If I could figure out how to get opam to
actually install into the system and not this bloody unexplained thing
that it calls "switches" (which are maybe a totally cool thing, but I
neither need nor want them) I could likely bootstrap the whole thing and
get the packages rebuilt that the OCaml LLVM bindings need.

Anyway, now that I have dune (I think), I could build integers as a
prerequisite of ctypes, which apparently now also needs bigarry-compat
and who knows what else (even though Cygwin didn't have these before).
Then maybe that's enough to get the OCaml bindings back in LLVM.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

ASSI via Cygwin-apps writes:
> I've started a local llvm-revival branch…

Progress, OCaml bindings are back again (I've not run the tests yet):

--8<---------------cut here---------------start------------->8---
* OCaml Updates
  - [X] flexdll 0.39 ==> 0.43
    + does not recognize -pthread, but will get it from ocamlc under certain conditions
  - [X] ocaml 4.14.0 ==> 4.14.1
    + ocaml_config imports stupid flags from the cygport build
    + probably from /usr/lib/ocaml/Makefile.config
  - [X] ocaml-labltk 8.06.8 ==> 8.06.12 (for 4.14!)
    + CI build runs into trouble, local build is OK
  - [X] ocaml-findlib 1.2.1 ==> 1.9.6
    + CI build would require newer labltk
  - [X] ocaml-ocamlbuild 0.14.0 ==> 0.14.2
    + test complains about missing ocamlbuild.cmo, looks in the wrong place
    + test requires findlib
  - [X] opam 2.0.7 ==> 2.1.5
  - [X] ocaml-dune 2.5.1 ==> 3.10.0
    + no longer builds with the original recipe, missing external libraries that in turn require dune to build
    + set up build w/ make according to the instructions from upstream
    + import Fedora patch to kill lwt
    + doc generation needs sphinx-copybutton, stopgap: pip3 install (needs Cygwin package)
    + does not test due to missing packages yet
    + ocaml-dune.cygclass needs to specify --prefix and --libdir
    + csexp in private libs
    + ocamlfind shows version as n/a
  - [X] ocaml-stdlib-shims 0.3.0
  - [X] ocaml-integers 0.3.0 ==> 0.7.0
    + shown as f77a25b-dirty by ocamlfind
  - [X] ocaml-bigarray-compat 1.1.0
  - [X] ocaml-ctypes 0.17.1 ==> 0.21.1
    + tests don't build: flexdll gets a '-pthread' from tests/clib/dune that it can't handle
    + tests depend on non-existing libraries

* LLVM Updates
  - [X] LLVM 9.0.1 rebuild
    + update fedora to f31
    + update patches
    + enable/disable OCAML via OCAML_SUPPORT
    + control build targets via LLVM_TARGETS
    + enable testing
  - [ ] clang
  - [ ] libcxxabi
  - [ ] libcxx
  - [ ] libunwind
  - [ ] compiler-rt
  - [ ] dtc (?)

* Dependencies
  
  - [ ] python-sphinx-copybutton
--8<---------------cut here---------------end--------------->8---

Cygport package changes are in the Cygwin Packages Git repository in the
respective playground branch as before.

Staging package repository with the builds is currently available at:

root=http://cygwin.stromeko.net/

Point setup at $root/stage as an additional (!) repository and use my
signing key via "-K $root/stromeko.gpg" if you want to play with the
packages.  The fingerprint of my key is:

      B22B 4890 B89E 5E5A 795C  E305 B40B EC75 3152 B1C3

If you have the keyart script (Python, you can just download from
https://raw.githubusercontent.com/atoponce/keyart/master/keyart), this
is what you should see after importing the key into your public keyring:

> keyart stromeko
+-----[DSA 2048]----+
|         ^.        |
|        ^ .        |
|       ^ E         |
|    . . ^ :        |
|. .  ^ : .         |
|.^  . ^.:S         |
| ..  . :^.         |
|.  .^ ^.^          |
|. ^:.^ ..          |
| ^:... .           |
|.^    .            |
+-----[3152B1C3]----+
+-------------------+
|                 :X|
|             .  ^^^|
|            :   ..^|
|         . : .   E |
|          i . . .  |
|       ^ S l : .   |
|        i l ^ ^    |
|       ^ . .       |
|      .   .        |
|       . .         |
|      ...          |
+-------------------+


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[小さい猫]

Thank you for your hard work <3

On Monday, August 28th, 2023 at 12:28 AM, ASSI via Cygwin-apps <cygwin-apps@cygwin.com> wrote:

> ASSI via Cygwin-apps writes:
> 
> - [ ] dtc (?)

Ah sorry... that device tree compiler cygport repo in the github org is not related to LLVM stuffs. just i happened to need it for building something else and it's adapted from the old cygwinports-extras[1].

[1]: https://github.com/cygwinports-extras/dtc

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

小さい猫 via Cygwin-apps writes:
>> - [ ] dtc (?)
>
> Ah sorry... that device tree compiler cygport repo in the github org
> is not related to LLVM stuffs. just i happened to need it for building
> something else and it's adapted from the old cygwinports-extras[1].

OK, I thought so already, but I wasn't sure.  Thanks for the
confirmation.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[William Hu]

Hi All,

Re OCaml compilers: I should be able to package OCaml 4.14.1 (and hopefully an 
alpha version of 5.1.0 as well) for Cygwin in the coming weeks. OCaml 5.0.0 
temporarily dropped Cygwin support so the Cygwin versions will of course skip 
that release.

On Saturday, August 26th, 2023 at 3:40 PM, ASSI wrote:
> + ocaml_config imports stupid flags from the cygport build
> + probably from /usr/lib/ocaml/Makefile.config

Just checked the file and I agree that CFLAGS looks a little funny - are there any 
other stupid flags/variables that you had in mind?

> I can get to that point with a bootstrap build or even a fully
> configured one with opam. If I could figure out how to get opam to
> actually install into the system and not this bloody unexplained thing
> that it calls "switches" (which are maybe a totally cool thing, but I
> neither need nor want them) I could likely bootstrap the whole thing and
> get the packages rebuilt that the OCaml LLVM bindings need.

Re Opam switches: As far as I understand, switches are like "git branch" but for 
different compiler installations instead of different code branches; for example 
you can install ocaml 4.14.0 and 4.12.0 side by side and switch between them 
easily. In addition to some other things, it effectively edits your PATH 
environment variable so when you type "ocamlc" it'll execute the appropriate version.

General comment: I don't know much about LLVM, but is there a reason why the 
other software (dune, ocamlbuild, etc.) must be installed with the system and 
not with opam?

> Cygport package changes are in the Cygwin Packages Git repository in the
> respective playground branch as before.

Re OCaml cygport playground: Thanks for the cygport cleanup and changes.
A couple questions:

src_compile:
1. Adding flambda to a default system installation of OCaml can slow down 
compile times and produce linking incompatibilities with non-flambda code [1]. 
Additionally, there may be value in a vanilla out-of-the-box OCaml distribution.
Let me know if there is some general Cygwin guidance on what features packaged 
language compilers should support. Otherwise, if flambda is necessary for LLVM, 
I could package an flambda and a non-flambda release for each version, and the 
user can pick which one they prefer.

2. What benefit does splitting "cygmake" into the 3-step "cygmake world, opt, 
opt.opt" have? Plain old "make/cygmake" with no target appears to be the 
recommended compilation step.

src_test:
1. I believe "make ocamltest" does not run the testsuite; AFAIU, it builds the 
auxiliary testing software instead. So far the only ways I know of to run the 
testsuite are either "make tests" or cd'ing into the testsuite directory and 
running "make all" (the old method).

Thanks,
William

[1] https://v2.ocaml.org/manual/flambda.html

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[William Hu]

On Tuesday, August 29th, 2023 at 10:18 PM, William Hu wrote:
> src_test:
> 1. I believe "make ocamltest" does not run the testsuite; AFAIU, it builds the
> auxiliary testing software instead. So far the only ways I know of to run the
> testsuite are either "make tests" or cd'ing into the testsuite directory and
> running "make all" (the old method).

Apologies, ignore my previous comment about src_test - I missed the final 
"cygmake tests" line! Now I'm simply curious what splitting the testsuite
build step into three make calls does.

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

William Hu via Cygwin-apps writes:
> Just checked the file and I agree that CFLAGS looks a little funny - are there any 
> other stupid flags/variables that you had in mind?

NOt immediately, but it makes me wonder if there's other such leakage.
I have not found a (text) file that stores this information in the
installed package, so it seems that the information is compiled in
someplace.

> Re Opam switches: As far as I understand, switches are like "git branch" but for 
> different compiler installations instead of different code branches; for example 
> you can install ocaml 4.14.0 and 4.12.0 side by side and switch between them 
> easily. In addition to some other things, it effectively edits your PATH 
> environment variable so when you type "ocamlc" it'll execute the appropriate version.

Yes, I know that.  The complete mystery is why you can't use opam to
provide results that can be packaged.

> General comment: I don't know much about LLVM, but is there a reason why the 
> other software (dune, ocamlbuild, etc.) must be installed with the system and 
> not with opam?

Because the expecation is that you can get everything in to a working
state just by installing the packages.

>> Cygport package changes are in the Cygwin Packages Git repository in the
>> respective playground branch as before.
>
> Re OCaml cygport playground: Thanks for the cygport cleanup and changes.
> A couple questions:
>
> src_compile:
> 1. Adding flambda to a default system installation of OCaml can slow down 
> compile times and produce linking incompatibilities with non-flambda code [1]. 
> Additionally, there may be value in a vanilla out-of-the-box OCaml
> distribution.

I've mainly includeed it because LLVM complained it wasn't enabled
(obviously it can build the OCaml bindings with and without flambda)
since it seems to work and test OK I just flipped that switch.

> Let me know if there is some general Cygwin guidance on what features packaged 
> language compilers should support. Otherwise, if flambda is necessary for LLVM, 
> I could package an flambda and a non-flambda release for each version, and the 
> user can pick which one they prefer.

I don't think that makes any sense given the way the packaging is done
at the moment.  In fact, ever since you updated to 4.14.0 all other
OCaml packages in Cygwin were dead since you didn't update these at the
same time and there is no mechanism in place yet to ensure that ocaml-*
packages and the ocaml package target the same version of the compiler.

> 2. What benefit does splitting "cygmake" into the 3-step "cygmake world, opt, 
> opt.opt" have? Plain old "make/cygmake" with no target appears to be the 
> recommended compilation step.

Hysterical raisins… before I got things to actually build it would stop
in various places and I was tring to find out where that happened.  I've
not gone back to reduce it again since it doewsn't incur any (or at
least not noticeable) overhead at the moment.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[William Hu]

On Wednesday, August 30th, 2023, ASSI wrote:
> NOt immediately, but it makes me wonder if there's other such leakage.
> I have not found a (text) file that stores this information in the
> installed package, so it seems that the information is compiled in
> someplace.

After some digging I believe I've found where the information is compiled in
(a daisy chain of variables starting with Makefile.config in the toplevel directory...)

To confirm I'm fixing the right thing, could you elaborate what specifically
is the error with "ocaml_config imports stupid flags from the cygport build"?
Is there a specific option within CFLAGS (fdebug-prefix-map perhaps?)
or ocamlc invocation that's causing an error message? 

Regarding other leakage, it looks like almost every file (exe, cma, etc.) 
contains provenance compiled into the file due to the fact that they are 
compiled with -g to include debugging information. I can obfuscate the provenance 
by building in /mnt/share/cygpkgs (the same approach Cygwin tar, gcc appear to do).

> I don't think that makes any sense given the way the packaging is done
> at the moment. In fact, ever since you updated to 4.14.0 all other
> OCaml packages in Cygwin were dead since you didn't update these at the
> same time and there is no mechanism in place yet to ensure that ocaml-*
> packages and the ocaml package target the same version of the compiler.

Unless you were already planning to, I'd be happy to adopt some of these OCaml packages 
and package some new releases so they can also work on Cygwin. 

Thanks,
William

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

William Hu via Cygwin-apps writes:
> On Wednesday, August 30th, 2023, ASSI wrote:
>> NOt immediately, but it makes me wonder if there's other such leakage.
>> I have not found a (text) file that stores this information in the
>> installed package, so it seems that the information is compiled in
>> someplace.
>
> After some digging I believe I've found where the information is
> compiled in (a daisy chain of variables starting with Makefile.config
> in the toplevel directory...)

I suspected something like that, but as I said I didn't find a definite
answer and the text files in the system installation didn't have this
information, so I concluded it must come from some binary.

> To confirm I'm fixing the right thing, could you elaborate what specifically
> is the error with "ocaml_config imports stupid flags from the cygport build"?
> Is there a specific option within CFLAGS (fdebug-prefix-map perhaps?)
> or ocamlc invocation that's causing an error message? 

Anything specific to the cygport build environment, but specifically the
prefix maps.

> Regarding other leakage, it looks like almost every file (exe, cma, etc.) 
> contains provenance compiled into the file due to the fact that they are 
> compiled with -g to include debugging information. I can obfuscate the provenance 
> by building in /mnt/share/cygpkgs (the same approach Cygwin tar, gcc appear to do).

That's just because these are my packages too and that's the location
where I built them.

>> I don't think that makes any sense given the way the packaging is done
>> at the moment. In fact, ever since you updated to 4.14.0 all other
>> OCaml packages in Cygwin were dead since you didn't update these at the
>> same time and there is no mechanism in place yet to ensure that ocaml-*
>> packages and the ocaml package target the same version of the compiler.
>
> Unless you were already planning to, I'd be happy to adopt some of these OCaml packages 
> and package some new releases so they can also work on Cygwin. 

I wasn't planning to adopt the packages (I really don't know enough
about OCaml), but doing a non-maintainer update would have been an
option.  Having an active maintainer for these again would be a much
better solution of course.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust

[ASSI]

William Hu via Cygwin-apps writes:
> Hi All,
>
> Re OCaml compilers: I should be able to package OCaml 4.14.1 (and hopefully an 
> alpha version of 5.1.0 as well) for Cygwin in the coming weeks. OCaml 5.0.0 
> temporarily dropped Cygwin support so the Cygwin versions will of course skip 
> that release.

Given the general state of things, I'd not bother with anything that
isn't officially supported upstream and only provide the LTS version
(which at the moment seems to be 4.14.x) as non-test.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada