miniupnp
miniupnp copied to clipboard
2.2.3: `install` target fails and missing .pc file
Looks like cmake fails in install
target
+ cd miniupnpc-2.2.3
+ DESTDIR=/home/tkloczko/rpmbuild/BUILDROOT/miniupnpc-2.2.3-2.fc35.x86_64
+ /usr/bin/cmake --install x86_64-redhat-linux-gnu
-- Install configuration: "RelWithDebInfo"
-- Installing: /home/tkloczko/rpmbuild/BUILDROOT/miniupnpc-2.2.3-2.fc35.x86_64/usr/lib64/libminiupnpc.so.2.2.3
-- Installing: /home/tkloczko/rpmbuild/BUILDROOT/miniupnpc-2.2.3-2.fc35.x86_64/usr/lib64/libminiupnpc.so.17
-- Installing: /home/tkloczko/rpmbuild/BUILDROOT/miniupnpc-2.2.3-2.fc35.x86_64/usr/lib64/libminiupnpc.so
-- Installing: /home/tkloczko/rpmbuild/BUILDROOT/miniupnpc-2.2.3-2.fc35.x86_64/usr/lib64/cmake/miniupnpc/libminiupnpc-shared.cmake
-- Installing: /home/tkloczko/rpmbuild/BUILDROOT/miniupnpc-2.2.3-2.fc35.x86_64/usr/lib64/cmake/miniupnpc/libminiupnpc-shared-relwithdebinfo.cmake
CMake Error at x86_64-redhat-linux-gnu/cmake_install.cmake:110 (file):
file INSTALL cannot find
"/home/tkloczko/rpmbuild/BUILD/miniupnpc-2.2.3/miniupnpc.h": No such file
or directory.
cmake as weel do not generate and install miniupnpc.pc file (main Makegule is no longer able to generate that file)
[tkloczko@ss-desktop miniupnpc-2.2.3]$ make miniupnpc.pc
make: *** No rule to make target 'miniupnpc.pc'. Stop.
BTW is it possible to change on next release tagging convention from current miniupnpc_<version_with_underscores>
to <version.with.dots>
?
It would make easier packaging miniupnp using github autogenerated tar ball from git tag.
BTW is it possible to change on next release tagging convention from current
miniupnpc_<version_with_underscores>
to<version.with.dots>
? It would make easier packaging miniupnp using github autogenerated tar ball from git tag.
get versions from http://miniupnp.free.fr/files/rest.php/tags/miniupnpd
Issue is that those versions cannot be used to download tar ball from git tag. Change tagging convention would nmake that easier.
Issue is that those versions cannot be used to download tar ball from git tag. Change tagging convention would nmake that easier.
download gpg signed .tar.gz from http://miniupnp.free.fr/files/
Takking convention has noting to do with provide gpg igned tar ball. BTW github offers figning git tags https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-tags
it happens that github is not the where officials .tar.gz of miniupnpc/miniupnpd are available.
it happens that github is not the where officials .tar.gz of miniupnpc/miniupnpd are available.
Again: my question was about tagging convention and not where are official tar ball. Using autogenerated by github from git tag tar ball produces correct products and there is no any problems with that).
@miniupnp It still complains about a missing header:
CMake Error at cmake_install.cmake:131 (file):
file INSTALL cannot find
"/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_net_miniupnpc/miniupnpc/work/miniupnpc-2.2.3/miniupnpc.h":
No such file or directory.
make: *** [install/fast] Error 1
It still complains about a missing header:
It was fixed in this commit https://github.com/miniupnp/miniupnp/commit/f82b0563a72e33800f5918ead68c41bcda1fd4c1.
@Biswa96 Thank you, it worked!
Just tested 2.3.0 + all mater patche. All builds howeer after installation looks like some binaries have hardcoded rpath to build env
+ /usr/lib/rpm/check-rpaths
*******************************************************************************
*
* WARNING: 'check-rpaths' detected a broken RPATH OR RUNPATH and will cause
* 'rpmbuild' to fail. To ignore these errors, you can set the
* '$QA_RPATHS' environment variable which is a bitmask allowing the
* values below. The current value of QA_RPATHS is 0x0000.
*
* 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
* issue but are introducing redundant searchpaths without
* providing a benefit. They can also cause errors in multilib
* environments.
* 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute
* nor relative filenames and can therefore be a SECURITY risk
* 0x0004 ... insecure RPATHs; these are relative RPATHs which are a
* SECURITY risk
* 0x0008 ... the special '$ORIGIN' RPATHs are appearing after other
* RPATHs; this is just a minor issue but usually unwanted
* 0x0010 ... the RPATH is empty; there is no reason for such RPATHs
* and they cause unneeded work while loading libraries
* 0x0020 ... an RPATH references '..' of an absolute path; this will break
* the functionality when the path before '..' is a symlink
*
*
* Examples:
* - to ignore standard and empty RPATHs, execute 'rpmbuild' like
* $ QA_RPATHS=$(( 0x0001|0x0010 )) rpmbuild my-package.src.rpm
* - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like
* $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths
*
*******************************************************************************
ERROR 0002: file '/usr/bin/upnpc' contains an invalid '/home/tkloczko/rpmbuild/BUILD/miniupnp-miniupnpd_2_3_0/miniupnpc/x86_64-redhat-linux-gnu' in [/home/tkloczko/rpmbuild/BUILD/miniupnp-miniupnpd_2_3_0/miniupnpc/x86_64-redhat-linux-gnu]
ERROR 0002: file '/usr/bin/upnpc-listdevices' contains an invalid '/home/tkloczko/rpmbuild/BUILD/miniupnp-miniupnpd_2_3_0/miniupnpc/x86_64-redhat-linux-gnu' in [/home/tkloczko/rpmbuild/BUILD/miniupnp-miniupnpd_2_3_0/miniupnpc/x86_64-redhat-linux-gnu]
And indeed looks like it is used rpath
[tkloczko@devel-g2v miniupnp-miniupnpd_2_3_0]$ grep -r rpath
miniupnp.podspec: install_name_tool -id "@rpath/libminiupnpc.dylib" libminiupnpc.dylib
BTW: is it possible on next release change tagging convention from cyrrent miniupnpd_<version_with_inderscores>
to just <version.with.dots>
?
It would simplify downlaod procedure from git tag on automated packaging.
(Please .. 😄 )
And indeed looks like it is used rpath
[tkloczko@devel-g2v miniupnp-miniupnpd_2_3_0]$ grep -r rpath miniupnp.podspec: install_name_tool -id "@rpath/libminiupnpc.dylib" libminiupnpc.dylib
No .. loooks like something else is causing that rpath is used or that on install target those binaries are not relinked without rpath.
Still cmake is not generating and installing .pc file 😃
I found it is possible to disable rpath by pass -D CMAKE_SKIP_RPATH=ON
. It looks like it is part of the standard cmake modules however I think that it would be good to disable that by default.
I've tested as well https://github.com/miniupnp/miniupnp/pull/591 and it looks good.
It is yet another small issue 😃
Despite use -D UPNPC_BUILD_TESTS=ON
ctest is not able to find any units.
[tkloczko@devel-g2v x86_64-redhat-linux-gnu]$ cmake -L |grep TEST
CMake Warning:
No source or binary directory provided. Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.
CMake Error: The source directory "/home/tkloczko/rpmbuild/BUILD/miniupnp-miniupnpd_2_3_0/miniupnpc/x86_64-redhat-linux-gnu" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
UPNPC_BUILD_TESTS:BOOL=ON
[tkloczko@devel-g2v x86_64-redhat-linux-gnu]$ ctest -vv
Test project /home/tkloczko/rpmbuild/BUILD/miniupnp-miniupnpd_2_3_0/miniupnpc/x86_64-redhat-linux-gnu
No tests were found!!!
@kloczek shouldn't you use CMAKE_SKIP_INSTALL_RPATH instead of CMAKE_SKIP_RPATH ?
@kloczek http://miniupnp.free.fr/files/rest.php/tags/miniupnpd
https://miniupnp.tuxfamily.org/files/rest.php/tags/miniupnpd?count=1
Why you are wasting time on organise sometbing which github provides OOTB? 🤔
no time is wasted, and I don't depend on github. Never has.