Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust
小さい猫 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
On Monday, 15 January 2024 at 9:47 PM, 小さい猫 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 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
On Tuesday, 16 January 2024 at 1:41 AM, ASSI via Cygwin-apps 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, 小さい猫 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
小さい猫 via Cygwin-apps writes: > On Thursday, 14 December 2023 at 2:42 PM, 小さい猫 via Cygwin-apps > 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 Monday, 15 January 2024 at 7:47 PM, Takashi Yano 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 Mon, 15 Jan 2024 10:37:23 + 小さい猫 wrote: > On Thursday, 14 December 2023 at 2:42 PM, 小さい猫 via Cygwin-apps > 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
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 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
On Wednesday, 2 August 2023 at 12:32 PM, 小さい猫 wrote: > On Monday, July 31st, 2023 at 5:37 AM, Jon Turney jon.tur...@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
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
Re: [Sharing progress] Tried to revive LLVM/Clang/Libc++ pkgs and port Rust
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
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
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
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
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
小さい猫 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
Thank you for your hard work <3 On Monday, August 28th, 2023 at 12:28 AM, ASSI via Cygwin-apps 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: > 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
小さい猫 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
On Monday, August 14th, 2023 at 12:50 AM, ASSI via Cygwin-apps 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 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
小さい猫 via Cygwin-apps writes: > On Monday, August 14th, 2023 at 12:50 AM, ASSI via Cygwin-apps > 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 Friday, August 18th, 2023 at 8:59 AM, 小さい猫 via Cygwin-apps 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
On Monday, August 14th, 2023 at 12:50 AM, ASSI via Cygwin-apps 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
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
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
On Monday, July 31st, 2023 at 5:37 AM, Jon Turney 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 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?
