Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#22529 - Pacman configure assumes libfetch is built with -lcrypto (i.e. openssl)
Attached to Project:
Pacman
Opened by shinythings (shinythings) - Thursday, 20 January 2011, 20:26 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 23 March 2011, 15:38 GMT
Opened by shinythings (shinythings) - Thursday, 20 January 2011, 20:26 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 23 March 2011, 15:38 GMT
|
DetailsSummary and Info:
Pacman ./configure fails to detect libfetch if it is not built with openssl (libcrypto). Workaround: --- configure 2010-12-15 05:59:19.000000000 +0700 +++ configure-fixed 2011-01-21 03:23:44.196671136 +0700 @@ -12350,7 +12350,7 @@ $as_echo_n "(cached) " >&6 else ac_check_lib_save_LIBS=$LIBS -LIBS="-lfetch -lcrypto -ldl $LIBS" +LIBS="-lfetch -ldl $LIBS" cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ Steps to Reproduce: Build libfetch without openssl. Try to configure pacman. #: ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var [...] checking for archive_read_data in -larchive... yes checking whether to link with libfetch... yes checking for fetchParseURL in -lfetch... no configure: error: libfetch is needed to compile with internal download support #: pacman -Ql libfetch libfetch /usr/ libfetch /usr/include/ libfetch /usr/include/fetch.h libfetch /usr/lib/ libfetch /usr/lib/libfetch.a libfetch /usr/lib/libfetch.so libfetch /usr/share/ libfetch /usr/share/man/ libfetch /usr/share/man/man3/ libfetch /usr/share/man/man3/fetch.3.gz #: ls -lh /usr/include/fetch.h /usr/lib/libfetch* -rw-r--r-- 1 root root 5.9K Jan 21 02:10 /usr/include/fetch.h -rw-r--r-- 1 root root 71K Jan 21 02:10 /usr/lib/libfetch.a -rwxr-xr-x 1 root root 52K Jan 21 02:10 /usr/lib/libfetch.so #: ldd /usr/lib/libfetch.so linux-gate.so.1 => (0xb7896000) libc.so.6 => /lib/libc.so.6 (0xb7729000) /lib/ld-linux.so.2 (0xb7897000) |
This task depends upon
Closed by Dan McGee (toofishes)
Wednesday, 23 March 2011, 15:38 GMT
Reason for closing: Won't fix
Additional comments about closing: We are now using cURL exclusively, no more libfetch.
Wednesday, 23 March 2011, 15:38 GMT
Reason for closing: Won't fix
Additional comments about closing: We are now using cURL exclusively, no more libfetch.
--- configure.ac 2010-12-15 05:58:49.000000000 +0700
+++ configure.ac-fixed 2011-01-21 04:01:18.536671136 +0700
@@ -143,7 +143,7 @@
AC_DEFINE([INTERNAL_DOWNLOAD], , [Use internal download library])
# Check for a download library if it was actually requested
AC_CHECK_LIB([fetch], [fetchParseURL], ,
- AC_MSG_ERROR([libfetch is needed to compile with internal download support]), [-lcrypto -ldl] )
+ AC_MSG_ERROR([libfetch is needed to compile with internal download support]), [-ldl] )
# Check if libfetch supports conditional GET
# (version >=2.21, struct url has member last_modified)
AC_CHECK_MEMBER(struct url.last_modified, ,
I am currently building on a system that has no openssl at all. With the configure workaround, pacman builds and works just fine.
By the way, this may be relevant: http://archlinux.2023198.n4.nabble.com/PATCH-Fix-cross-compilation-issues-with-git-and-libfetch-td2061788.html
Re: Relevant, note that there were two patches in a row in the git repo, the one you point out (bf7c3eb17f4de35f6639b2f3f0c1c06a27b5242b) followed by 6b6eb6345bb3d9f59d967144968328c9a4b7873c which backed out most of those changes because it must have caused breakage because it wasn't doing things right.
Rebuilding pacman with the configure.ac change on a standard archlinux system in which both libarchive and libfetch are built with openssl support and where openssl is (of course) installed, results in a working pacman. Building pacman with the configure.ac change on a system in which both libarchive and libfetch are built without openssl support and where openssl is NOT installed, also results in a working pacman. That's pretty much the only testing I can do at the moment, unless you have any particular suggestions. As I have no clue why the libcrypto reference is there in the first place, I can't say simply removing it would be fine, that's just a hackish workaround for my system. It seems to have been present since before the change I references, as you say.
This is a rather special corner case anyway (makepkg requires openssl, so why build libfetch without it), so I'm not sure you even want to fix it, but I thought you should be aware of it at least. Short of fixing it, you could simply explicitly require libfetch with openssl support, to make the message clearer.
--without-openssl and with libarchive built without openssl (but libfetch with openssl) also seems to work.
--without-openssl and no openssl at all also seems to work.
Not sure what that means.