Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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
Contributor

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
Contributor

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