On Fri, 25 Sep 2020 at 01:10:47 AM +0200, Albert Astals Cid wrote:
El dijous, 24 de setembre de 2020, a les 3:21:00 CEST, Kyle Auble va
escriure:
....
However, if I configure to build with clang, I don't even reach that
point. My logs show g-ir-scanner trying to link with gcc anyways,
then
failing to find the sanitizer libraries.
* I'm leaning towards g-ir-scanner being the cause, but could it be
a
Poppler issue?
I know nothing of glib stuff, you'll have to hope someone else
answers.
It took a little sleuthing, but it's definitely g-ir-scanner.
Apparently, it will recognize an env-var, but otherwise will default to
the system's Python settings.
So the workaround is a snap (just export CC=clang), but even if the GLib
team doesn't want to implement a flag, it really could be documented
better.
2. The GLib tests also fail at linking if ubsan is enabled....
* At that point, I'm thinking it's more of an issue with
extra-cmake-
modules for not checking & handling this behavior.
Yes, probably a ECM issue, when we did code that we didn't think of
C-only code, KDE doesn't have much of those, patches to
https://invent.kde.org/frameworks/extra-cmake-modules/ welcome. Add
me @aacid as reviewer if you do :)
OK, I've made notes so I might send in a patch once I reach my next
waypoint here.
3. For the project generally, how much appetite is there for minor
code
refactoring? Do you all prefer "if it ain't broke, don't fix it",
or do
you typically accept minor changes to streamline the code?
Patches that defenitely make the code better are accepted. But of
course you have to accept we may disagree on what "makes the code
better" mean.
Sounds good. It's just a couple of spots in the CMake scripts for now. I
think they can be deduplicated, but I'll keep the commits granular, and
put them in a separate merge-request to review.
Kyle
_______________________________________________
poppler mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/poppler
