On Fri, 11 Apr 2025 10:16:22 -0700 (PDT) Jeremy Drake <cyg...@jdrake.com> wrote:
> On Fri, 11 Apr 2025, Takashi Yano via Cygwin-apps wrote: > > > On Thu, 10 Apr 2025 12:45:06 -0700 (PDT) > > Jeremy Drake wrote: > > > We (@mati865 and I) just managed to get llvm/clang 20.1.2 building and > > > targeting Cygwin over at MSYS2, and I was wondering if you had anyone > > > interested in these patches to update the package(s) in Cygwin? I'm not > > > particularly interested in taking on more responsibilities, but I guess I > > > could take a look at this if nobody else wants to. > > > > > > MSYS2 package: > > > https://github.com/msys2/MSYS2-packages/tree/master/llvm > > > > > > Note that we wound up punting on LLD support for Cygwin targets: there's > > > currently no way to tell the difference in the LLD driver between Cygwin > > > and MinGW targets, and trying to adapt to Cygwin broke the ability to use > > > that LLD for MinGW cross-compiling. Given that it was all pretty hacky > > > anyway, it seemed better to keep the working MinGW cross-compiling support > > > than trade it in for still-somewhat-broken Cygwin support when we can just > > > keep using GNU ld for the Cygwin target. > > > > Amazing! > > > > Now I am trying to build llvm for cygwin. For now, it fails with > > ld: error: export ordinal too large: xxxxx > > in dll linkage. > > > > If you could give me a suggestion, I would greatly appreciate it. > > Are you using the patches and cmake options from > https://github.com/msys2/MSYS2-packages/tree/master/llvm ? > > I noticed one (0101-hack-dynamically-resolve-G-include-dir.patch) has an > "msys" that will need to be changed to "cygwin". > > The export ordinal too large error is because there are too many symbols > for export-all-symbols to export from the DLLs (the DLL export table uses > an unsigned short, so you only get 65535 exports). With GCC, it can only > build static libraries, see > https://github.com/msys2/MSYS2-packages/blob/4813abedafbbe1343ca287fded18b14f1f792198/llvm/PKGBUILD#L175-L189 > > Once you have clang built, you can use it to rebuild llvm with dynamic > libs. Clang has a workaround that hooks up ELF-style visibility "hidden" > to exclude symbols from auto-export, so there are not too many symbols for > a DLL. Thanks for the advice. I was trying to build DLL with gcc. Now I can successfully build llvm without DLL using gcc. Next step I am trying is building clang using gcc. It seems that clang is the same, I mean, DLL should be disabled in the first step using gcc. Then build clang again using clang built in the first step, right? -- Takashi Yano <takashi.y...@nifty.ne.jp>
