Description of problem: The proj.pc file installed with proj-devel 7.2.1 seems to be malformed. It does not include the -L component, and includes direct addresses to shared objects rather than -lproj -lsqlite3 -ltiff -lcurl -lstdc++ expected. The consequence is that software being built against proj-devel, instead of running ./configure & make, fails, requiring the use of configure arguments. Also see https://github.com/r-spatial/sf/issues/1670 for this case. As reported, I must say that I only ever install proj from source, so have no problem, but users of R-spatial software encounter unexpected problems, and so increase the burden on software maintainers.
This doesn't have anything to do with epel-release that I can see... moving to 'proj' for comment.
Roger, would you mind to attach the file for easier inspection?
I do not use any proj-devel rpms. The problem arose in https://github.com/r-spatial/sf/issues/1670, and may not appply to the EPEL 8 proj-devel, but rather https://src.fedoraproject.org/rpms/proj/ - bugzilla was most unhelpful wrt. finding who packages what. The user does not have the skills to work out what isgoing on afteer upgrading to F34 (I think). The proj-devel build is for version 7.2.1. In the rpm linked to by the user, and as reported iin the thread, proj.pc is: prefix=/usr exec_prefix=/usr libdir=/usr/lib64 includedir=/usr/include datarootdir=/usr/share/proj datadir=/proj Name: PROJ Description: Coordinate transformation software library Requires: Version: 7.2.0 Libs: -L${libdir} -lproj Libs.private: /usr/lib64/libsqlite3.so /usr/lib64/libtiff.so /usr/lib64/libcurl.so -lstdc++ Cflags: -I${includedir} The user reported seeing -L vanishing (I've seen this recently for GEOS, may be a pkgconfig bug (?) https://lists.osgeo.org/pipermail/geos-devel/2021-May/010212.html), and the static dependencies on -lcurl -ltiff -lsqlite3 are given to the so's, which seems odd. My built-from-source proj (8.0.1) on F33 is: prefix=/usr/local exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include datarootdir=${prefix}/share datadir=${datarootdir}/proj Name: PROJ Description: Coordinate transformation software library Requires: Version: 8.0.1 Libs: -L${libdir} -lproj Libs.private: -lsqlite3 -ltiff -lcurl -lstdc++ Cflags: -I${includedir} so giving the so's seems to be a packaging choice. Any ideas? Edzer and I would **much** prefer not having to tell F34 users with EPEL/other (?) proj-devel.*.rpm that they have to use a configure argument to get around the disappearing -L string. I cannot reproduce their problem because I need to track what PROJ/GDAL/GEOS are up to before it his us on release.
I have taken a look at https://src.fedoraproject.org/rpms/proj/blob/rawhide/f/proj.spec and actually do not see where to add the requested changes. As far as I see the proj.pc is generated from proj.pc.in which is part of the upstream package: https://github.com/OSGeo/PROJ/blob/master/proj.pc.in There are no patches either in https://src.fedoraproject.org/rpms/proj/tree/rawhide . Is it really a Fedora packaging issue?
I just tested it [1] successfully on F33: R install.packages("sf") ... * DONE (sf) but I got to know that there seem to be issues on F34 which I don't have yet... [1] https://github.com/r-spatial/sf/issues/1670
This is how it looks on F34/RPM (I received it from someone): cat /usr/lib64/pkgconfig/proj.pc prefix=/usr exec_prefix=/usr libdir=/usr/lib64 includedir=/usr/include datarootdir=/usr/share/proj datadir=/proj Name: PROJ Description: Coordinate transformation software library Requires: Version: 7.2.0 Libs: -L${libdir} -lproj Libs.private: /usr/lib64/libsqlite3.so /usr/lib64/libtiff.so /usr/lib64/libcurl.so -lstdc++ Cflags: -I${includedir} @roger.bivand: is this file ok?
I never use these rpms, so cannot tell; I only install from source - it isn't my problem but that of users of R packages installed from source and using pkgconfig called from ./configure. I think that the problem was the one I described first, that -lcurl -lsqlite3 -ltiff are missing in either Libs: or Libs.private:, replaced by the actual shared objects. In my proj.pc installed from source I see: $ cat /usr/local/lib/pkgconfig/proj.pc prefix=/usr/local exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include datarootdir=${prefix}/share datadir=${datarootdir}/proj Name: PROJ Description: Coordinate transformation software library Requires: Version: 8.0.1 Libs: -L${libdir} -lproj Libs.private: -lsqlite3 -ltiff -lcurl -lstdc++ Cflags: -I${includedir}
This has nothing to do with Fedora/EPEL packaging, because it's not modifying what upstream provides. This should be reported upstream.
BTW, EPEL 7 has proj-4.8.0, EPEL 8 has proj-6.3.2 and ELN has proj-8.0.0. This issue is in proj-7.2.x, which is only in Fedora 34, so moving the issue there. However, the issues reported with R-spatial packages come from the fact that since v7.2.0, we do not package a static version of libproj (I opened another issue to ask about that https://bugzilla.redhat.com/show_bug.cgi?id=1975265), and R's sf package is testing the --static flag in its configure script (which I think it shouldn't do, as I'm trying to argue here https://github.com/r-spatial/sf/issues/1696).
> I never use these rpms, so cannot tell; I only install from source Please report this upstream, it is not a packaging issue.
Well, indeed it's *not* a packaging issue, but it *could* be patched for F34, as it seems kind of improbable we see a new upstream release for the 7.x.x series.