Open dimpase opened 4 years ago
Description changed:
---
+++
@@ -1,5 +1,11 @@
-some perfectly fine implementations of zlib don't install zlib.pc (e.g. MacOS does not).
+`libpng.pc, gdlib.pc, zlib.pc`
+are needed in the calls of `pkgconfig.parse` in `src/module_list.py`
+
+
+some perfectly fine implementations of `zlib` etc. don't install `zlib.pc` etc. (e.g. MacOS does not).
Since #26286 this problem was sleeping, until we updated `pkgconfig` on #28883, which made it throw an error on absense of `zlib.pc`.
+
+
Description changed:
---
+++
@@ -1,4 +1,4 @@
-`libpng.pc, gdlib.pc, zlib.pc`
+`libpng.pc, gdlib.pc, zlib.pc`etc
are needed in the calls of `pkgconfig.parse` in `src/module_list.py`
@@ -6,6 +6,7 @@
Since #26286 this problem was sleeping, until we updated `pkgconfig` on #28883, which made it throw an error on absense of `zlib.pc`.
+This ticket provides generation of `zlib.pc` and `libpng.pc`, among with some fly-by refactoring.
The biggest question I here is how to find the full path to libz
located by AC_CHECK_LIB
or other similar macro.
This path has to be written into zlib.pc
.
I don't quite know: I can link an executable with libz and analyse it with
readelf
or otool
or a similar thing, but it's not platform independent,
and I could not find a ready-made macro (I could change AC_CHECK_LIB
, sure...)
Author: Dima Pasechnik
Branch: u/dimpase/packages/missingpcs
You can use a minimal pkgconfig file like below which doesn't require the full path to the library.
Name: Foo
Description: description for foo
Version: 1.0.0
Libs: -lfoo
well, a minimal pkgconfig like this would be just a bug in waiting to bite.
I can think of one platform-independent way (well, it needs dladdr, which is non-POSIX, but BSD, something that is available on most Unices, certainly on Linux and MacOS)
Write a C function that calls dlopen()
on the library in question, and then
calls dladdr()
on a symbol from the library; one of parts of the returned data is the full path to the shared object where the symbol is located.
That's a hell of a macro call to AC_RUN_IFELSE
though :-)
Could someone please try if the following works on MacOS, and if yes, what's the output
/* save into zt.c and run as follows:
$ cc -o zt zt.c -ldl && ./zt
On my Debian Linux box it outputs
/usr/lib/x86_64-linux-gnu/libz.so
*/
#include <stdio.h>
#define __USE_GNU
#include <dlfcn.h>
#ifdef __APPLE__
#define EXT "dylib"
#else
#define EXT "so"
#endif
int main() {
void *z;
Dl_info info;
int res;
void *ha;
z = dlopen("libz."EXT, RTLD_LAZY); /* load zlib */
ha = dlsym(z, "inflateEnd"); /* get address of inflateEnd in libz */
res = dladdr(ha, &info); /* get info for the function */
printf("%s\n", info.dli_fname);
return res;
}
Replying to @dimpase:
Could someone please try if the following works on MacOS, and if yes, what's the output
fbissey@itsv-frb15 GitHub % uname -a
Darwin itsv-frb15.lan 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64
fbissey@itsv-frb15 GitHub % cc -o zt zt.c -ldl && ./zt
/usr/lib/libz.1.dylib
I suggest linking the executable zt
to libz
so that the correct shared library is loaded.
Branch pushed to git repo; I updated commit sha1. New commits:
6bb85c4 | implemented generating input data for zlib.pc |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
80a23ac | implemented generating zlib.pc |
This branch is so far only for zlib.pc
Any obvious things I missed?
Naturally, I'd appreciate it tested on MacOS.
For libpng.pc I'll probably refactor that, to make computing abstolute path to libpng/libz/libWhatever a macro.
this is a result - ugly as hell. I am not sure whether this should get in.
Replying to @dimpase:
well, a minimal pkgconfig like this would be just a bug in waiting to bite.
Would it though? Why exactly do we require pkgconfig here at all? It's a convenience sure, but on systems that don't install .pc files for some libraries we can still get the required information another way...
I mean, if autoconf could detect a system zlib in the first place, then I don't see why would need the absolute path to the SO file itself. All that should be needed to link against that library are whatever compiler/linker flags (e.g. -lz
) that autoconf used to detect usability of the library in the first place.
Replying to @embray:
Replying to @dimpase:
well, a minimal pkgconfig like this would be just a bug in waiting to bite.
Would it though? Why exactly do we require pkgconfig here at all? It's a convenience sure, but on systems that don't install .pc files for some libraries we can still get the required information another way...
I am thinking of a library trying to detect zlib by calling pkg-config rather than using autoconf.
IMHO it's better not to install a pc file at all rather than install a rather bogus one. That's why I prefer how it's done on #28883.
I mean, if autoconf could detect a system zlib in the first place, then I don't see why would need the absolute path to the SO file itself. All that should be needed to link against that library are whatever compiler/linker flags (e.g.
-lz
) that autoconf used to detect usability of the library in the first place.
It's not necessarily "bogus". But I agree--I think what you did in #28883 is more in line with what I was trying to say here.
I don't see the difference in #28883 and a minimal .pc file as in #28906 comment:5 . They do the same thing.
Replying to @isuruf:
I don't see the difference in #28883 and a minimal .pc file as in #28906 comment:5 . They do the same thing.
yes, but they do so by different means, and a pc file is much more likely to trip up someone.
I don't know if this ticket is still needed; but if it is, then it should be revised along the lines of #29082 -- do not write into SAGE_LOCAL at configure time; instead generate a rule in build/make/Makefile that generates the pc file there.
I don't recall right now all the details, why I thought it's needed. Anyhow, perhaps as a concept of how to generate *.pc files, e.g. for openblas.
libpng.pc, gdlib.pc, zlib.pc
etc are needed in the calls ofpkgconfig.parse
insrc/module_list.py
some perfectly fine implementations of
zlib
etc. don't installzlib.pc
etc. (e.g. MacOS does not).Since #26286 this problem was sleeping, until we updated
pkgconfig
on #28883, which made it throw an error on absense ofzlib.pc
.This ticket provides generation of
zlib.pc
andlibpng.pc
, among with some fly-by refactoring.CC: @kiwifb @embray @isuruf @mkoeppe
Component: build: configure
Author: Dima Pasechnik
Branch/Commit: u/dimpase/packages/missingpcs @
ba7d963
Issue created by migration from https://trac.sagemath.org/ticket/28906