autogen @5.17.4_0: autoopts-config produces a stray -R flag, breaks gnutls @3.1.22_0 build

[jwhowse4]

I am using an Intel Mac Pro running Mac OS 10.8.5 (Mountain Lion) with XCode 5.0.2. When I try to upgrade to version 3.1.22 the build fails with the attached error log. Glancing through the log file I am not even sure why the build is failing. Any suggestions?

[jwhowse4]

gnutls build log

[neverpanic (Clemens Lang)]

:info:build /bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang  -pipe -Os -arch x86_64  -L/Volumes/User_Disk/opt/macports/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-certtool.la  libcmd_certtool_la-certtool-args.lo libcmd_certtool_la-certtool-cfg.lo ../gl/libgnu.la ../lib/libgnutls.la -R -L/Volumes/User_Disk/opt/macports/lib -lopts -L/Volumes/User_Disk/opt/macports/lib -lintl -R/Volumes/User_Disk/opt/macports/lib -Wl,-framework -Wl,CoreFoundation   -lintl 
:info:build mv -f .deps/serv.Tpo .deps/serv.Po
:info:build /bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang  -pipe -Os -arch x86_64  -L/Volumes/User_Disk/opt/macports/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-danetool.la  libcmd_danetool_la-danetool-args.lo libcmd_danetool_la-certtool-cfg.lo ../gl/libgnu.la ../lib/libgnutls.la -R -L/Volumes/User_Disk/opt/macports/lib -lopts -L/Volumes/User_Disk/opt/macports/lib -lintl -R/Volumes/User_Disk/opt/macports/lib -Wl,-framework -Wl,CoreFoundation   -lintl 
:info:build libtool: link: only absolute run-paths are allowed
:info:build make[4]: *** [libcmd-certtool.la] Error 1
:info:build make[4]: *** Waiting for unfinished jobs....
:info:build libtool: link: only absolute run-paths are allowed
:info:build make[4]: *** [libcmd-danetool.la] Error 1

Seems like there's a stray -R without an argument there that breaks the build.

[larryv (Lawrence Velázquez)]

I don’t currently have a Mountain Lion system to debug this on; if anyone submits a patch, I’ll be glad to apply it.

[wiml@…]

I just hit this as well, on SnowLeopard. I think the underlying problem may be with autogen rather than gnutls:

• The stray '-R' in gnutls' link command comes from LIBOPTS_LDADD
• According to config.log, that variable was derived from autooopts-config:

configure:55587: checking whether autoopts-config can be found
configure:55594: checking whether autoopts-config is specified
configure:55605: result: autoopts-config
configure:55631: result:  -R -L/opt/local/lib -lopts

And in fact /opt/local/bin/autoopts-config ldopts or ldflags produces flags with the bogus '-R'. autoopts-config is part of the autogen package.

It looks like the gnutls port does not list autogen as a dependency; instead it contains its own copy which it uses iff there isn't an installed copy. So probably what's going on is that the macports autoopts-config is buggy, but the copy bundled with gnutls is not buggy. (Macports says my copy of autogen is autogen @5.17.4_0+universal.)

[jwhowse4]

The autogen port is installed on my Mountain Lion system. When I deactivated autogen, the new gnutls builds and installs just fine. So on my system, wiml seems to have correctly diagnosed the problem.

[whcordis@…]

Works for me as well.

[ryandesign (Ryan Carsten Schmidt)]

I had the same problem on Mavericks; resolved by deactivating the autogen port.

[larryv (Lawrence Velázquez)]

Has duplicate #42769.

[cooljeanius (Eric Gallager)]

Cc Me!

[cooljeanius (Eric Gallager)]

diff between OP's main.log and my main.log for this build failure

[cooljeanius (Eric Gallager)]

This one is actually the diff I thought I was uploading last time, the previous one was just my log

[cooljeanius (Eric Gallager)]

So it looks like the short-term solution would be to use the conflicts_build 1.0 PortGroup to add "conflicts_build autogen" to the gnutls Portfile, while the long-term solution would be getting autogen upstream to fix their autoopts-config script. It may actually be fixed in a newer version if we update it:

Local-Admins-MacBook-Pro:dlcompat-20030629 ericgallager$ port -v livecheck autogen
autogen seems to have been updated (port version: 5.17.4, new version: 5.18.2)

but idk for sure about that... Edit: just tried updating the port myself; it fails to build, but the autoopts-config script still gets generated, and it still contains the stray -R flag. This can also be seen while running the configure script:

checking whether runtime library dirs can be specified... -R

which, more verbosely, looks like this in config.log:

configure:15979: checking whether runtime library dirs can be specified
configure:16001: result: -R

and ends up getting put in the following variables:

ag_cv_test_ldflags=-R

AG_LDFLAGS='-R'

The second one is subst'd into autoopts/autoopts-config.in here:

      ldopts="@AG_LDFLAGS@"

The conftest that substs it from the configure script comes from the AG_TEST_LDFLAGS macro in config/ag_macros.m4:

AC_DEFUN([AG_TEST_LDFLAGS],[
  AC_MSG_CHECKING([whether runtime library dirs can be specified])
  AC_CACHE_VAL([ag_cv_test_ldflags],[
    ag_cv_test_ldflags=`exec 2> /dev/null
echo 'int main() { return 0; }' > conftest.$ac_ext
libs="${LIBS}"
LIBS="${LIBS} -Wl,-R/tmp"
if (eval $ac_link) > /dev/null 2>&1
then echo '-Wl,-R${libdir}' ; rm -f conftest* ; exit 0 ; fi
LIBS="${libs} -R/tmp"
if (eval $ac_link) > /dev/null 2>&1
then echo '-R' ; rm -f conftest* ; exit 0 ; fi
rm -f conftest* ; exit 1`
    if test $? -ne 0 || test -z "$ag_cv_test_ldflags"
    then ag_cv_test_ldflags=no
    fi
  ]) # end of CACHE_VAL of ag_cv_test_ldflags
  AC_MSG_RESULT([${ag_cv_test_ldflags}])
  if test "X${ag_cv_test_ldflags}" != Xno
  then
    AG_LDFLAGS="@S|@{ag_cv_test_ldflags}"
  else
    AG_LDFLAGS=''
  fi
  AC_SUBST([AG_LDFLAGS])

]) # end of AC_DEFUN of AG_TEST_LDFLAGS

So the thing following the -R is supposed to be either ${libdir} or /tmp... I wonder why ${libdir} does not get used properly? Anyways I guess I will have to ask upstream...

[cooljeanius (Eric Gallager)]

Reported upstream: ​https://sourceforge.net/p/autogen/bugs/157/

Interestingly, while I was submitting the upstream bug report, I found that I had a manually-built copy of autogen installed in /usr/local, and it does not experience this problem:

Local-Admins-MacBook-Pro:autogen-5.18.2 ericgallager$ which -a autoopts-config
/opt/local/bin/autoopts-config
/usr/local/bin/autoopts-config
/opt/local/bin/autoopts-config
Local-Admins-MacBook-Pro:autogen-5.18.2 ericgallager$ autoopts-config --libs
 -R -L/opt/local/lib -lopts
Local-Admins-MacBook-Pro:autogen-5.18.2 ericgallager$ /usr/local/bin/autoopts-config --libs
 -R/usr/local/lib -L/usr/local/lib -lopts

So I am guessing that I must have specified libdir manually when I built my other copy...

[bkorb@…]

if (eval $ac_link) > /dev/null 2>&1
then echo '-R' ; rm -f conftest* ; exit 0 ; fi

That's what looks dodgy to me. I think that should be:

if (eval $ac_link) > /dev/null 2>&1
then echo '-R${libdir}' ; rm -f conftest* ; exit 0 ; fi

I guess I don't use linkers that use that syntax. If that fix works, it will be in the next release. Thanks!

[basmac]

Having same or similar problem with 10.8.5 build ?

  593  port clean gnutls

  594  port -d upgrade gnutls


info:build libtool: link: ( cd ".libs" && rm -f "libcmd-ocsp.la" && ln -s "../libcmd-ocsp.la" "libcmd-ocsp.la" )
:info:build libtool: link: ar cru .libs/libcmd-cli-debug.a .libs/libcmd_cli_debug_la-cli-debug-args.o
:info:build libtool: link: ( cd ".libs" && rm -f "libcmd-serv.la" && ln -s "../libcmd-serv.la" "libcmd-serv.la" )
:info:build libtool: link: ( cd ".libs" && rm -f "libcmd-psk.la" && ln -s "../libcmd-psk.la" "libcmd-psk.la" )
:info:build libtool: link: ranlib .libs/libcmd-cli.a
:info:build libtool: link: ranlib .libs/libcmd-cli-debug.a
:info:build libtool: link: ( cd ".libs" && rm -f "libcmd-cli-debug.la" && ln -s "../libcmd-cli-debug.la" "libcmd-cli-debug.la" )
:info:build libtool: link: ( cd ".libs" && rm -f "libcmd-cli.la" && ln -s "../libcmd-cli.la" "libcmd-cli.la" )
:info:build make[4]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64/src'
:info:build make[3]: *** [all-recursive] Error 1
:info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64/src'
:info:build make[2]: *** [all] Error 2
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64/src'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64" && /usr/bin/make -j8 -w all
:info:build Exit code: 2
:error:build org.macports.build for port gnutls returned: command execution failed
:debug:build Error code: NONE
:debug:build Backtrace: command execution failed
    while executing
"$procedure $targetname"
:info:build Warning: targets not executed for gnutls: org.macports.install org.macports.build org.macports.destroot
:notice:build Please see the log file for port gnutls for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/main.log
bash-3.2#

[cooljeanius (Eric Gallager)]

Replying to bkorb@…:

if (eval $ac_link) > /dev/null 2>&1
then echo '-R' ; rm -f conftest* ; exit 0 ; fi

That's what looks dodgy to me. I think that should be:

if (eval $ac_link) > /dev/null 2>&1
then echo '-R${libdir}' ; rm -f conftest* ; exit 0 ; fi

I guess I don't use linkers that use that syntax. If that fix works, it will be in the next release. Thanks!

Yup, it worked for me. Thanks!

(I would attach a patch, but I made some other changes to the file that might be irrelevant...)

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #43212.

[neverpanic (Clemens Lang)]

I assume this still happens with gnutls 3.3.3 as well?

[dbevans (David B. Evans)]

Yes, build fails as follows with OS X 10.8.5, Xcode 5.1.1:

libtool: link: ( cd ".libs" && rm -f "libcmd-ocsp.la" && ln -s "../libcmd-ocsp.la" "libcmd-ocsp.la" )
/bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang   -pipe -Os -arch x86_64  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-certtool.la  certtool-args.lo certtool-cfg.lo ../lib/libgnutls.la gl/libgnu_gpl.la ../gl/libgnu.la -R -L/opt/local/lib -lopts -L/opt/local/lib -lintl -R/opt/local/lib -Wl,-framework -Wl,CoreFoundation  gl/libgnu_gpl.la   -lintl 
/bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang   -pipe -Os -arch x86_64  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-danetool.la  danetool-args.lo certtool-cfg.lo ../lib/libgnutls.la gl/libgnu_gpl.la ../gl/libgnu.la -R -L/opt/local/lib -lopts -L/opt/local/lib -lintl -R/opt/local/lib -Wl,-framework -Wl,CoreFoundation    -lintl 
libtool: link: only absolute run-paths are allowed
make[4]: *** [libcmd-certtool.la] Error 1
make[4]: *** Waiting for unfinished jobs....
libtool: link: only absolute run-paths are allowed
make[4]: *** [libcmd-danetool.la] Error 1

Full log attached.

[dbevans (David B. Evans)]

Log showing build failure of gnutls 3.3.3 on 10.8.5.

[dbevans (David B. Evans)]

CCing myself and new gnutls maintainer

[dbevans (David B. Evans)]

See also #43866.

[jwhowse4]

I get essentially the same error log with a different installation directory. Deactivating autogen allows me to install gnutls 3.3.3 successfully.

[Schamschula (Marius Schamschula)]

Replying to jwhowse4@…:

I get essentially the same error log with a different installation directory. Deactivating autogen allows me to install gnutls 3.3.3 successfully.

I think this may be the problem.

I have built gnutls 3.3.3 on my my non-MacPorts build systems under 10.7.5 and 10.8.5. I don't recall ever using autoconf. I will have to research where and why autoconf was inserted into the Portfile.

[Schamschula (Marius Schamschula)]

I just built gnutls 3.3.3 without the autogen under Mavericks 10.9.3. I also noticed a missing dependency from my non-MacPorts systems: unbound. Please test the attached Portfile patch on Lion and Mountain Lion (I don't have access to MacPorts systems with these OSs).

[dbevans (David B. Evans)]

Note that although gnutls builds using autotools (autoconf, automake, etc), it does not depend on the package autogen but apparently tries to use it if it is installed and it is when it just happens to be installed (say as a dependency of some other port) that the build fails. For instance, anjuta requires autogen.

So the question seems to be how to disable the use of (external) autogen in gnutls or failing that how to fix autogen so it doesn't break the build.

[dbevans (David B. Evans)]

By the way, the reason the port uses autoreconf (to rebuild the configuration files) is contained in this commit

r110322 | jeremyhu@macports.org | 2013-08-29 15:32:59 -0700 (Thu, 29 Aug 2013) | 2 lines

gnutls: autoreconf to get glibtool to know how to handle -stdlib

Copying jeremyhu for any further comments.

[dbevans (David B. Evans)]

Attached is an alternate patch that fixes the build with port autogen installed and active (or at least works for me on 10.8.5).

It uses --enable-local-libopts to ask gnutls to use it's private (local) version of libopts rather than looking for the version supplied by autogen. This is the default behavior when autogen is not active so it provides uniform behavior in both cases.

Have also added the dependency on unbound which enables DNSSEC, DANE support.

[dbevans (David B. Evans)]

Patch to build correctly even if autogen is installed

[neverpanic (Clemens Lang)]

While that looks good to me, shouldn't we still fix the stray -R in the output of autoopts-config?

I'm also wondering whether adding the unbound dependency by default is a good idea, since it increases the dependency footprint of gnutls (and a lot of ports that use it).

[dbevans (David B. Evans)]

Replying to cal@…:

While that looks good to me, shouldn't we still fix the stray -R in the output of autoopts-config?

Indeed (oops, that's this ticket). However, if this course is relied upon then perhaps a dependency on autogen should be added so that the same library is used in all installations. The libopts library is static only and not installed by gnutls by default so there is no activation conflict between the two. Note that the -R problem is not limited to autoopts-config but also occurs in autoopts.pc. My suggested approach decouples gnutls from the autogen problem.

I'm also wondering whether adding the unbound dependency by default is a good idea, since it increases the dependency footprint of gnutls (and a lot of ports that use it).

If it isn't added then a means to disable DNSSEC support needs to be added so that opportunistic configuration doesn't occur. A +dnssec variant could then be added to enable DNSSEC support for those that want it (e.g. me).

[dbevans (David B. Evans)]

Revised Portfile based on comments plus a few more fixes

[dbevans (David B. Evans)]

Attached is a revised version of my patch file that addresses some of cal's comments as well as a few more fixes.

I've left the port configured to use the local instance of libopts rather than port autogen for the following reasons:

• in most instances (since the only dependent of autogen is anjuta) this is the default configuration
• therefore, the configuration uses the same instance of libopts for all installations
• makes the solution of gnutls problem independent of the autogen one (which still needs to be fixed)
• fewer dependencies

I've disabled the building of libdane by default in favor of a +dane variant which enables this support using unbound.

While testing, I saw that the output of configure concludes as follows:

configure: System files:

  Trust store pkcs11:
  Trust store file:
  Blacklist file:
  CRL file:
  Priority file:        /etc/gnutls/default-priorities
  DNSSEC root key file: /etc/unbound/root.key

configure: WARNING:
***
*** The DNSSEC root key file in /etc/unbound/root.key was not found.
*** This file is needed for the verification of DNSSEC responses.
*** Use the command: unbound-anchor -a "/etc/unbound/root.key"
*** to generate or update it.
***

The revised port includes configuration items that properly set the defaults for the priority file and the DNSSEC root key file to use the MacPorts prefix. In addition, notes are added if the +dane variant is selected and the default DNSSEC root key file does not exist, explaining how to create it using the command 'unbound-anchor'. This is just the text from the end of configure which is generally invisible to the end user.

Port unbound currently does not create this key file during installation or when running the unbound daemon (#43881).

Finally, I note that there is no default path for the following files:

 Trust store pkcs11
 Trust store file
 Blacklist file
 CRL file

This doesn't necessarily break gnutls, it just means that the dependent package needs to specify these file paths programmatically when needed. There are corresponding configuration items for these defaults which might be set to something reasonable for a default configuration but I'm not sure at the moment what these might be and whether that is really necessary or not.

[neverpanic (Clemens Lang)]

Double checking I think it is a good idea to provide a +dane variant, since (a) DANE is (unfortunately) still not very widely used and (b) unbound depends on openssl, which would lead to the ironic situation of gnutls depending on openssl. Of course, this is the new maintainer's call in the end.

I agree with your handling of the autogen dependency (i.e., using the local libopts).

As for the trust store file, should we set that to the path of curl-ca-bundle or the file generated by certsync, i.e. $prefix/etc/openssl/cert.pem? Is the trust store format expected by GnuTLS compatible with the one used by OpenSSL? Pending further work on the followup to certsync we don't have a PKCS11 module, so that should stay empty for now.

[Schamschula (Marius Schamschula)]

Replying to cal@…:

Double checking I think it is a good idea to provide a +dane variant, since (a) DANE is (unfortunately) still not very widely used and (b) unbound depends on openssl, which would lead to the ironic situation of gnutls depending on openssl. Of course, this is the new maintainer's call in the end.

I just checked the dependencies for unbound, and indeed unbound depends on openssl (and expat). I think we may want to move unbound into a variant, making it an optional install.

I agree with your handling of the autogen dependency (i.e., using the local lib opts).

Same here.

As for the trust store file, should we set that to the path of curl-ca-bundle or the file generated by certsync, i.e. $prefix/etc/openssl/cert.pem? Is the trust store format expected by GnuTLS compatible with the one used by OpenSSL? Pending further work on the followup to certsync we don't have a PKCS11 module, so that should stay empty for now.

I think using the curl-ca-bundle is a good idea, however, this makes for another dependency.

[dbevans (David B. Evans)]

Replying to mschamschula@…:

Replying to cal@…:

Double checking I think it is a good idea to provide a +dane variant, since (a) DANE is (unfortunately) still not very widely used and (b) unbound depends on openssl, which would lead to the ironic situation of gnutls depending on openssl. Of course, this is the new maintainer's call in the end.

I just checked the dependencies for unbound, and indeed unbound depends on openssl (and expat). I think we may want to move unbound into a variant, making it an optional install.

Done in my most recent patch, +dane variant, since it is only necessary for DANE functionality. Default build does not depend on unbound.

I agree with your handling of the autogen dependency (i.e., using the local lib opts).

Same here.

As for the trust store file, should we set that to the path of curl-ca-bundle or the file generated by certsync, i.e. $prefix/etc/openssl/cert.pem? Is the trust store format expected by GnuTLS compatible with the one used by OpenSSL? Pending further work on the followup to certsync we don't have a PKCS11 module, so that should stay empty for now.

I think using the curl-ca-bundle is a good idea, however, this makes for another dependency.

I wouldn't worry about dependencies too much. I think the primary goal is full functionality without the user having to make too many technical decisions. Will leave this part to you as maintainer, see

./configure --help 

in ${worksrcpath} for the appropriate configuration options. Again this is only a default and will be over-ridden if the calling application desires to do so. So may not be terribly important. A review of how the various dependents handle this might be useful down the road. Let me or cal know when you think things are ready to commit.

[dbevans (David B. Evans)]

Now about autogen ...

[ballapete (Peter "Pete" Dyballa)]

Replying to cal@…:

:info:build /bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang  -pipe -Os -arch x86_64  -L/Volumes/User_Disk/opt/macports/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-certtool.la  libcmd_certtool_la-certtool-args.lo libcmd_certtool_la-certtool-cfg.lo ../gl/libgnu.la ../lib/libgnutls.la -R -L/Volumes/User_Disk/opt/macports/lib -lopts -L/Volumes/User_Disk/opt/macports/lib -lintl -R/Volumes/User_Disk/opt/macports/lib -Wl,-framework -Wl,CoreFoundation   -lintl 
:info:build mv -f .deps/serv.Tpo .deps/serv.Po
:info:build /bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang  -pipe -Os -arch x86_64  -L/Volumes/User_Disk/opt/macports/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-danetool.la  libcmd_danetool_la-danetool-args.lo libcmd_danetool_la-certtool-cfg.lo ../gl/libgnu.la ../lib/libgnutls.la -R -L/Volumes/User_Disk/opt/macports/lib -lopts -L/Volumes/User_Disk/opt/macports/lib -lintl -R/Volumes/User_Disk/opt/macports/lib -Wl,-framework -Wl,CoreFoundation   -lintl 
:info:build libtool: link: only absolute run-paths are allowed
:info:build make[4]: *** [libcmd-certtool.la] Error 1
:info:build make[4]: *** Waiting for unfinished jobs....
:info:build libtool: link: only absolute run-paths are allowed
:info:build make[4]: *** [libcmd-danetool.la] Error 1

I see a similar failure on PPC Tiger, Mac OS X 10.4.11:

libtool: compile:  /opt/local/bin/gcc-apple-4.2 -DHAVE_CONFIG_H -I. -I.. -I./gl -I./../gl -I./gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libdane/includes -I./../extra/includes -I/opt/local/include -I/opt/local/include -pipe -Os -arch ppc -MT certtool-cfg.lo -MD -MP -MF .deps/certtool-cfg.Tpo -c certtool-cfg.c  -fno-common -DPIC -o .libs/certtool-cfg.o
certtool-cfg.c: In function 'get_rand_int_value':
certtool-cfg.c:1104: warning: right shift count >= width of type
/bin/sh ../libtool  --tag=CC   --mode=link /opt/local/bin/gcc-apple-4.2   -pipe -Os -arch ppc  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -o libcmd-certtool.la  certtool-args.lo certtool-cfg.lo ../lib/libgnutls.la gl/libgnu_gpl.la ../gl/libgnu.la -R -L/opt/local/lib -lopts -L/opt/local/lib -lintl -R/opt/local/lib -Wl,-framework -Wl,CoreFoundation  gl/libgnu_gpl.la   -lintl 
libtool: link: only absolute run-paths are allowed
make[4]: *** [libcmd-certtool.la] Error 1

[ballapete (Peter "Pete" Dyballa)]

Cc Me!

[dbevans (David B. Evans)]

Replying to Peter_Dyballa@…:

Replying to cal@…: I see a similar failure on PPC Tiger, Mac OS X 10.4.11:

libtool: compile:  /opt/local/bin/gcc-apple-4.2 -DHAVE_CONFIG_H -I. -I.. -I./gl -I./../gl -I./gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libdane/includes -I./../extra/includes -I/opt/local/include -I/opt/local/include -pipe -Os -arch ppc -MT certtool-cfg.lo -MD -MP -MF .deps/certtool-cfg.Tpo -c certtool-cfg.c  -fno-common -DPIC -o .libs/certtool-cfg.o
certtool-cfg.c: In function 'get_rand_int_value':
certtool-cfg.c:1104: warning: right shift count >= width of type
/bin/sh ../libtool  --tag=CC   --mode=link /opt/local/bin/gcc-apple-4.2   -pipe -Os -arch ppc  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -o libcmd-certtool.la  certtool-args.lo certtool-cfg.lo ../lib/libgnutls.la gl/libgnu_gpl.la ../gl/libgnu.la -R -L/opt/local/lib -lopts -L/opt/local/lib -lintl -R/opt/local/lib -Wl,-framework -Wl,CoreFoundation  gl/libgnu_gpl.la   -lintl 
libtool: link: only absolute run-paths are allowed
make[4]: *** [libcmd-certtool.la] Error 1

Can you try the latest proposed patch for gnutls from this ticket and let us know if that fixes the problem?

Thanks

[dbevans (David B. Evans)]

I see this morning that the latest version of gnutls is now 3.3.4.

[Schamschula (Marius Schamschula)]

Replying to devans@…:

I see this morning that the latest version of gnutls is now 3.3.4.

I've merged patch-gnutls-3.3.3-rev1.diff​ with the version bump to 3.3.4, with some minor edits. I have only built the +unbound variant under Mavericks. Please test!

[dbevans (David B. Evans)]

Replying to mschamschula@…:

Replying to devans@…:

I see this morning that the latest version of gnutls is now 3.3.4.

I've merged patch-gnutls-3.3.3-rev1.diff​ with the version bump to 3.3.4, with some minor edits. I have only built the +unbound variant under Mavericks. Please test!

gnutls, gnutls +dane both build successfully on 10.8, 10.9. 10.7 should build as well since it uses a similar version of clang. I was also able to build successfully using the apple-gcc-4.2 compiler to simulate compilation on 10.6.

A trivial confidence test using danetool from the +dane build also works successfully.

danetool --check www.freebsd.org --proto tcp --port 443
Querying www.freebsd.org (tcp:443)...
_443._tcp.www.freebsd.org. IN TLSA ( 03 00 01 3f86a1fa85f6e5169cb27bf25c863805ebfd3225a16aadb75587804680992096 )
Certificate usage: Local end-entity (03)
Certificate type:  X.509 (00)
Contents:          SHA2-256 hash (01)
Data:              3f86a1fa85f6e5169cb27bf25c863805ebfd3225a16aadb75587804680992096

$ danetool --check www.fedoraproject.org --proto tcp --port 443
Querying www.fedoraproject.org (tcp:443)...
_443._tcp.www.fedoraproject.org. IN TLSA ( 00 00 01 19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0 )
Certificate usage: CA (00)
Certificate type:  X.509 (00)
Contents:          SHA2-256 hash (01)
Data:              19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0

Based on this, I think the updated port could be committed as is unless you want to add a default trust store file to configure.args as suggested by cal.

--with-default-trust-store-file="${prefix}/etc/openssl/cert.pem"

in which case you would also need a dependency something like this

depends_run  path:etc/openssl/cert.pem:certsync

[Schamschula (Marius Schamschula)]

Replying to devans@…:

Replying to mschamschula@…:

Replying to devans@…:

I see this morning that the latest version of gnutls is now 3.3.4.

I've merged patch-gnutls-3.3.3-rev1.diff​ with the version bump to 3.3.4, with some minor edits. I have only built the +unbound variant under Mavericks. Please test!

gnutls, gnutls +dane both build successfully on 10.8, 10.9. 10.7 should build as well since it uses a similar version of clang. I was also able to build successfully using the apple-gcc-4.2 compiler to simulate compilation on 10.6.

A trivial confidence test using danetool from the +dane build also works successfully.

danetool --check www.freebsd.org --proto tcp --port 443
Querying www.freebsd.org (tcp:443)...
_443._tcp.www.freebsd.org. IN TLSA ( 03 00 01 3f86a1fa85f6e5169cb27bf25c863805ebfd3225a16aadb75587804680992096 )
Certificate usage: Local end-entity (03)
Certificate type:  X.509 (00)
Contents:          SHA2-256 hash (01)
Data:              3f86a1fa85f6e5169cb27bf25c863805ebfd3225a16aadb75587804680992096

$ danetool --check www.fedoraproject.org --proto tcp --port 443
Querying www.fedoraproject.org (tcp:443)...
_443._tcp.www.fedoraproject.org. IN TLSA ( 00 00 01 19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0 )
Certificate usage: CA (00)
Certificate type:  X.509 (00)
Contents:          SHA2-256 hash (01)
Data:              19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0

Based on this, I think the updated port could be committed as is unless you want to add a default trust store file to configure.args as suggested by cal.

--with-default-trust-store-file="${prefix}/etc/openssl/cert.pem"

in which case you would also need a dependency something like this

depends_run  path:etc/openssl/cert.pem:certsync

It turns out that the trust store file is in the .crt format provided by the curl-ca-bundle. I've added this to the .3.diff file.

[dbevans (David B. Evans)]

OK but the /opt/local part of the file name needs to be replaced with ${prefix} as not all installations use /opt/local for the prefix. Shall I commit it with that modification? The gnutls part of the issue of this ticket has been fixed.

[Schamschula (Marius Schamschula)]

Replying to devans@…:

OK but the /opt/local part of the file name needs to be replaced with ${prefix} as not all installations use /opt/local for the prefix. Shall I commit it with that modification? The gnutls part of the issue of this ticket has been fixed.

Yup! It occurred to me after I got to bed last night...

Revised version, .4.diff uploaded.

[dbevans (David B. Evans)]

gnutls 3.3.4 update committed in r120701 with a few modifications:

• reset revision to 0 since this is the first commit of 3.3.4
• change default path to unbound root key file to conform to recent changes in unbound (r120660 #43881)
• update related comments, notes

Any further gnutls issues should be handled in a separate ticket.

The remaining issue of this ticket is that autogen @5.17.4_0 autoopts-config, autoopts.pc add a -R flag to ldflags that may break other ports.

[neverpanic (Clemens Lang)]

We should probably update autogen to get rid of this: ​http://sourceforge.net/p/autogen/bugs/157/.

[ryandesign (Ryan Carsten Schmidt)]

Here is a patch to update the autogen port to 5.18.3. It does not build for me:

In file included from ag.c:7:
In file included from ./autogen.h:60:
In file included from /opt/local/include/libguile.h:33:
In file included from /opt/local/include/libguile/async.h:26:
In file included from /opt/local/include/libguile/root.h:27:
/opt/local/include/libguile/throw.h:94:47: error: '_Noreturn' can only appear on functions
extern SCM scm_ithrow (SCM key, SCM args, int _Noreturn);
                                              ^

The problem seems to be that guile's headers use noreturn as an argument name in a function, but autogen #defines noreturn to something else. Perhaps autogen 5.18.3 is designed for a newer version of guile. Our ticket to update the guile port is #29307.

[mf2k (Frank Schima)]

See #53012.

[ryandesign (Ryan Carsten Schmidt)]

autogen was updated to 5.18.4 in r129638. See #42749.