Giters

ClangBuiltLinux / llvm-distributors-conf-2021

A day of lightning talks for folks who distribute and release builds of LLVM, with a focus on configuration, testing, and unique constraints.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[CFP] LLVM in OpenMandriva: packages still needing gcc, -fgnuc-version=11.2 and other"fun"

berolinux opened this issue · comments

commented

Title

LLVM in OpenMandriva: packages that still need GCC, -fgnuc-version=11.2 and other "fun"

Author

Bernhard Rosenkraenzer, bero@lindev.ch, OpenMandriva

Distribution

OpenMandriva is the first Linux distribution that made LLVM/Clang its main compiler. It is used to build almost all of our packages (both main and unsupported) - but we don't consider export CC=gcc; export CXX=g++ a complete taboo.

Abstract (optional)

OpenMandriva is the first Linux distribution that made LLVM/Clang its main compiler. It is used to build almost all of our packages (both main and unsupported) - but we don't consider export CC=gcc; export CXX=g++ a complete taboo. This talk gives a quick overview of where we still have to resort to this, why we still use libstdc++ rather than libc++ and other blockers for a 100% LLVM toolchain.
It also explains why we change the default -fgnuc-version value to 11.2 and what we need to change there.

What's unique about the environment you package LLVM for? (optional)

First Linux distribution that uses LLVM/Clang as its main compiler, use of -fgnuc-version=11.2

What makes your distribution of LLVM unique? (optional)

Crosscompiling support built in for everything, -fgnuc-version=11.2

What might others learn from your experience? (optional)

What still needs to be done to get to a 100% LLVM distro and more

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

More help for not so experienced packagers who report "MyFavoriteApp 1.1 works great with gcc but crashes with clang. Obviously clang is to blame and needs to be fixed, let's switch back to gcc!" type "bugs" -- There's currently no really good place for newbie packagers to turn to for help. Also, a patch exchange for the couple of packages where upstream maintainers insist on not supporting clang could result in less duplicated work.

commented

Thanks for taking the time to write up a CFP; we'd be overjoyed to have you present at LLVM Distributors Conf 2021! If you still plan on presenting, this is a reminder to get started on your slides for next week. Once they're done, we will contact you about submitting a PDF of your slides as either a pull request to this repository or via email to the organizer. We hope to have a schedule finalized by EOW; we may iterate on the schedule based on whether presenters have conflicts. Please keep this issue open for attendees to ask questions, or close this issue if you no longer plan on attending. Reminder to keep your talk concise (15 minutes); we wont be doing time for questions in order to fit as much content as possible. Attendees should ask questions here in this github issue.

commented

FWIW, the issue with Wine on x86_64 failing if built with Clang, it's probably this bug: https://bugs.winehq.org/show_bug.cgi?id=48297

I made an attempt at fixing it in LLVM in https://reviews.llvm.org/D86025, but it turned out to not be acceptable the first way I tried, so I haven't had time to pick it up further.