[makeotfexe] 4.0.2 fails on Linux #1761
Comments
takaakifuji
changed the title
|
I can reproduce the error when installing our "manylinux" wheel on Arch Linux. When I build and install from source Did you first try building from source without any changes? And can you verify whether when you installed the first time and hit the problem that our manylinux wheel was what was used? |
|
I suspect we may be having these problems: https://stackoverflow.com/questions/65335620/terminate-called-after-throwing-an-instance-of-stdsystem-error , with the issue being that the manylinux wheel is statically linking and the "normal" build is dynamically linking. |
|
Thank you for your response!
Yes. Running I'm not familiar with the C++ portion of the AFDKO codebase but I've read that libstdc++ includes weak symbols for pthread functions and |
OK, but did you build using the copy of the repository you downloaded on arm64 but without the change you made? We build, use, and test AFDKO routinely on Linux so I'm skeptical that we have a "generic" build problem there. It's much more plausible that there's a problem with the particular way we build the manylinux wheel.
From the link above:
And I'm reluctant to add What's probably going on here is that the ANTLR4 runtime is trying to check if it can use threads and finding the interfaces because it's statically linked and the pthread symbols are only used as a side-effect, so they aren't included in the linking. |
|
https://github.com/takaakifuji/test-blank/actions/runs/11859864502/job/33053812247 For reference, here's the log that illustrates how it fails on the x86_64 runner.
Yep, on the arm64 environment at first I just run I assumed too it's somehow related to the recent ANTLR change because 4.0.1 seemed to work just fine, but again I'm not familiar with how the native binaries in AFDKO are configured and compiled, so I just wanted to let you know it didn't work for me on the GitHub Actions runner. |
And it didn't work with the exact same error messages? |
|
I'm just trying to piece this together. You're saying you built the repo for Linux on ARM and it didn't work, and then you added some pthread-related stuff to the cmake config and it worked. We build for Linux on x86 without the pthread stuff and test routinely. This is the ci build for the current repo + some test code for buildwheels that isn't activated: https://github.com/adobe-type-tools/afdko/actions/runs/11859993613 Before I pushed those changes I built the current repo on Arch Linux this morning and confirmed that I could build adobe-clean with the result. I use Linux more than any other system for my own work. There's definitely a problem with the wheel -- I confirmed it -- but you're basically saying |
True. The following is the raw log I got when I tried to build the font on the arm64/aarch64 Ubuntu: Here's what I experienced so far: a. The manylinux x86_64 wheel doesn't build the font on the GitHub Actions runner I mainly use GitHub Actions for building fonts so |
I made sure to install 4.0.2 from the source on the x86_64 runner but it didn't work somehow while 4.0.1 worked. Am I doing it wrong? It's getting very puzzling. |
|
Ah, OK, that's helpful! When I pip-install on Arch x86 it looks like this: Notice no "manylinux" stuff. In effect it looks like (for whatever reason) your environment is trying to build a "generic" wheel with the manylinux infrastructure when using pip. If you get a chance, I'd like to confirm by seeing the |
|
Thank you for your assistance. I realized I set up and build Python with pyenv. Maybe that's the difference? |
|
For reference, this is what And this is what it looks like when I pip-install from the sources: Basically, a lot more is dynamically linked in the second case, which probably explains the difference we're seeing. I'll work on how to address this problem with static linking in a way that doesn't negatively affect our other builds. |
|
I'm not 100% sure but I think the issue comes from the different libstdc++ versions we're using. I've found makeotfexe compiles the font without errors if I switch to 22.04 LTS (jammy) from 20.04 LTS (focal). 20.04 LTS (focal) comes with GCC 10 and 22.04 LTS (jammy) comes with GCC 12. The former has been released around 2020-04-11. ANTLR 4.13.1 calls std::call_once but according to the commit in a fork the older version of libstdc++ depends on pthread_once for its std::call_once implementation. The pthread dependency has been eliminated with the patch around 2020-11-03. So the pthread linkage matters depending on the libstdc++ version installed on the system, and I assume that's why it doesn't work on the |
|
Are you in a position to try version 4.0.3a1 in your github ci? I just released that alpha as a test for this problem. |
|
Thank you for the fix! 4.0.3a1 worked both on the runner and my arm64/aarch64 environment.
The following is the log from my local arm64/aarch64 Ubuntu 20.04: |
MakeOTF causes the following error on the GitHub Actions runner, which runs Ubuntu 20.04.6 LTS and CPython 3.12.7:
After a bit of googling, I put the following line in the middle of
CMakeLists.txtto link libpthread to each C/C++ executable:Then I built and installed AFDKO from the source and tried building Adobe Blank again:
This time it worked. Downgrading AFDKO to 4.0.1 did work for me as well.
Looks to me 4.0.2 needs some fix for Linux but I would be happy if you could reproduce this.
The text was updated successfully, but these errors were encountered: