Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements to the pkg-config file #26

Merged
merged 2 commits into from
Jan 22, 2025

Conversation

orlitzky
Copy link
Contributor

Two small improvements to m4ri.pc:

  1. libpng becomes an internal (Requires.private) dependency. I've looked at the code, and I don't think any symbols from libpng are leaked to consumers. In other words, someone linking their program to m4ri does not need to supply -lpng. This change prevents the -lpng from being output by pkg-config --libs m4ri.

  2. The OpenMP flags are applied to static linking only. This was my original motivation for digging into this file. My copy of sage was being compiled (but not linked!) with -fopenmp because that flag appears in the pkg-config output for m4ri. The result of course crashes due to missing libgomp symbols. The OPENMP_FLAGS are applied to linking to (only) to avoid this issue, and made private for the same reason we made libpng private.

Resolves:

CC: @kiwifb, @dimpase, @tornaria, @arojas, @isuruf

When m4ri is compiled with PNG support, it exposes the two new symbols
mzd_from_png and mzd_to_png via m4ri/io.h. But neither of those
functions takes any libpng types as an argument, and so a program
being linking against m4ri should not need to include -lpng in its
link flags.
The -fopenmp (or equivalent) flag should not be present in Cflags,
because it causes programs being linked against m4ri to be compiled
with OpenMP support, and that may not be intended. For example, this
causes runtime crashes in SageMath built with meson: while -fopenmp
from m4ri is used at compile time, libgomp is ultimately not linked in
because the build system doesn't think we're using OpenMP.

As a result, $OPENMP_FLAGS flags are more appropriate to include when
linking than compiling. Moreover, the OpenMP library dependency (on
libgomp or equivalent) should be private for the same reason libpng
is: none of its symbols are directly exposed to users of m4ri.
@dimpase
Copy link

dimpase commented Jan 22, 2025

Why do you still keep libpng's cflags in?

@orlitzky
Copy link
Contributor Author

Why do you still keep libpng's cflags in?

If the Requires.private line were always used, I know we could get rid of them, but I left it alone in case there is some obscure corner case where libpng is detected without pkgconfig and somehow the cflags are useful.

@dimpase
Copy link

dimpase commented Jan 22, 2025

OK

@malb malb merged commit e75cd79 into malb:master Jan 22, 2025
1 check passed
@malb
Copy link
Owner

malb commented Jan 22, 2025

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants