curl: destroot merge failure of curl-config with +universal and +ssl variants when cross-compiling

[ju.freaks@…]

hey, after a "sudo port install libusb-devel +universal" I got errors at the end of the installation like:

Error: Target org.macports.destroot returned: /opt/local/bin/curl-config differs in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_curl/curl/work/destroot-i386 and /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_curl/curl/work/destroot-x86_64 and cannot be merged
Error: Failed to install curl
Log for curl is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_curl/curl/main.log
Error: The following dependencies were not installed: git-core curl p5.12-error perl5.12 gdbm pcre bzip2 libedit python27 db46 python_select sqlite3 rsync popt
Error: Status 1 encountered during processing.

what can I do?

[ryandesign (Ryan Carsten Schmidt)]

The Milestone field is not used for Port tickets. Please remember to use WikiFormating and preview before submitting. Remember to indicate the affected port in the Summary and in the Port field, and to Cc the maintainer of that port. Provide the main.log file when filing tickets. This might be a duplicate of #24059. Provide the two unmergeable curl-config files in the two indicated directories so I can determine how they differ.

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

I'll assume the difference is the one I observe myself while trying to build a 3-way universal on a 32-bit Intel iMac running 10.6: the MacPorts library path and SSL flags are repeated in the copy of curl-config built for the native architecture but not in the copies built for cross-compiled architectures. This was also mentioned as a secondary issue in comment:ticket:24001:14 and comment:ticket:24059:11 but I'll handle it in this ticket so that the issue has a ticket all its own.

The curl configure script is a bit peculiar, and actually contains code that deliberately only runs pkg-config when --with-ssl is used without a path (which is what we were doing in MacPorts):

  case "$OPT_SSL" in
  yes)
    dnl --with-ssl (without path) used
    if test x$cross_compiling != xyes; then
      dnl only do pkg-config magic when not cross-compiling
      PKGTEST="yes"
    fi
    PREFIX_OPENSSL=/usr/local/ssl
    LIB_OPENSSL="$PREFIX_OPENSSL/lib$libsuff"
    ;;
  off)
    dnl no --with-ssl option given, just check default places
    if test x$cross_compiling != xyes; then
      dnl only do pkg-config magic when not cross-compiling
      PKGTEST="yes"
    fi
    PREFIX_OPENSSL=
    ;;
  *)
    dnl check the given --with-ssl spot
    PKGTEST="no"
    PREFIX_OPENSSL=$OPT_SSL

    dnl Try pkg-config even when cross-compiling.  Since we
    dnl specify PKG_CONFIG_LIBDIR we're only looking where
    dnl the user told us to look
    OPENSSL_PCDIR="$OPT_SSL/lib/pkgconfig"
    AC_MSG_NOTICE([PKG_CONFIG_LIBDIR will be set to "$OPENSSL_PCDIR"])
    if test -f "$OPENSSL_PCDIR/openssl.pc"; then
      PKGTEST="yes"
    fi

    dnl in case pkg-config comes up empty, use what we got
    dnl via --with-ssl
    LIB_OPENSSL="$PREFIX_OPENSSL/lib$libsuff"
    if test "$PREFIX_OPENSSL" != "/usr" ; then
      SSL_LDFLAGS="-L$LIB_OPENSSL"
      SSL_CPPFLAGS="-I$PREFIX_OPENSSL/include"
    fi
    SSL_CPPFLAGS="$SSL_CPPFLAGS -I$PREFIX_OPENSSL/include/openssl"
    ;;
  esac

The simple fix is to supply the path, by specifying --with-ssl=${prefix}. Done in r136999.

It is possible that the code for other variants also needs similar changes, though a quick search through configure.ac didn't reveal any others with this particular code.