Bug 1958191

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.